You know, I remember (now) that you are running vmailmgr. I had
thought it was vpopmail. Sorry for the irrelevant questions in my
previous message.
"Chris Berry" <[EMAIL PROTECTED]> writes:
> >From: Tim Legant <[EMAIL PROTECTED]>
> >"Chris Berry" <[EMAIL PROTECTED]> writes:
> >
> > > 1) What is the correct octal permissions for the .tmda directory and
> > > files? Mine is owned by user vmail, and group virtual. Mail accounts
> > > on this server do not have system accounts.
> >
> >0700 will work fine.
>
> I tried that previously and got all kinds of error messages about not
> being able to switch to the appropriate directory. My system is set
> up under vmailmgr so /home/virtual/users/chris_berry/.tmda is owned by
> user vmail and group virtual not chris_berry chris_berry.
When qmail-local begins delivery of a message, it sets the UID to the
UID of the user to whom the message is being delivered. In the case
of a virtual domain, this is the system user that controls the domain.
Because of the virtual domain mechanism, the mail is addressed to
'vmail-<user>@jm-associates.com' and therefore qmail-local sets the
UID to vmail's UID.
qmail-local also sets the GID to the GID given in /etc/passwd for that
same user. It does *not* set supplemental groups, though, so if
'virtual' is not the primary group of the 'vmail' user, you might run
into problems.
Anyhow, since all programs in your dot-qmail files will run as vmail,
just ensure that they are owned by vmail and then setting the
permissions to 700 for .tmda and 600 for files in .tmda will, in fact,
work.
In the log you posted, the error message is this:
/usr/bin/du: cannot_change_to_directory `/home/virtual/.tmda': Permission_denied
This is not from TMDA. I suspect it's from the mailquotacheck.sh
script that you call first. I have no idea what that script does, or
why it wants to chdir to /home/virtual/.tmda. Perhaps it's looking at
the $HOME variable? At the time the script executes, $HOME is
/home/virtual.
You might not have a /home/virtual/.tmda directory and that might be
the cause of the above problem.
> > > 2) How can I get TMDA to enter tagged addresses created for
> > > confirmation messages into a file or variable? (so that I can enter
> > > them into moregoodrcpto.cdb)
> >
> >Off the top of my head, there's no way to do that in TMDA itself.
>
> Hmm, ok is there a way to have the confirmation messages go out
> without a dated address or something like
> [EMAIL PROTECTED] (If I can't add the
> dynamic variable, I need to have a static confirm address, or am I
> barking up the wrong tree here?)
The -confirm- address isn't dated. It *is* cryptographically
protected, however. If you use a "static" address, you've completely
lost any protection TMDA can give you. There is, therefore, no way to
remove the cryptography without rewriting some portions of TMDA.
The solution is to fix the goodrcptto patch so it will deliver to any
extension address, as long as the user that controls the address is
valid. I'm actually looking at this, since a version of the patch
that works with extension addresses would be valuable to me, as well.
I got joe-jobbed a couple of weeks ago. :(
> >1) The contents of /var/qmail/users/assign. If it's big, just post
> > the lines relating to jm-associates.
>
> Ok, I don't have such a file and as far as I can tell it's not
> necessary if you're using a virtual domain manager.
The vpopmail virtual domain manager uses it; vmailmgr does not.
Again, sorry for my confusion.
> >2) The contents of your .qmail-default file and also the exact path
> > where it's located.
>
> /home/virtual/.qmail-default is a symlink to /home/virtual/.qmail
> which is as follows:
>
> | /usr/local/src/mailquotacheck.sh
> | preline spamc -f | preline /usr/local/src/tmda-0.81/bin/tmda-filter
> --vhome-script /usr/local/src/vmailmgr-vdir.sh
Ok. I think something is screwy here. Here is a "sanitized" portion
of the output from TMDA that shows up in your log. I'll indent my
comments so you have some chance of distinguishing them from the log
output.
listvdomain:_unknown_user_'sayu'
When tmda-filter first starts and sees the --vhome-script flag, it
runs that script, passing it what it thinks is the recipient's user
name and domain. It gets these values from $EXT and $HOST. It
correctly figured out that 'sayu' was the recipient's username. It
called vmailmgr-vdir.sh like this:
vmailmgr-vdir.sh "sayu" "jm-associates.com"
The vmailmgr-vdir.sh script calls the vmailmgr program 'listvdomain'
to do its work. In this case, since 'sayu' is an invalid user,
listvdomain printed an error message to standard error and should
have returned an error code (on my box, it returns 1). So far, so
good.
See_BASH=/bin/sh
This line is the beginning of a mess. When TMDA runs into a problem
(which we'll get to in a moment), it first tries to write the error
report to LOGFILE_DEBUG and, if LOGFILE_DEBUG is not defined in your
configuration, it write the report to ~/TMDA_DELIVERY_FAILURE. It
uses a Python function to expand the tilde (~) into the user's home
directory. That Python function replaces the '~' with the $HOME
environment variable.
TMDA prints the following message to the mail log:
See /home/virtual/TMDA_DELIVERY_FAILURE for traceback
The word 'See' and the following space, above, are the beginning of
this line. Then your entire environment is printed! Finally, the
text '/home/virtual/TMDA_DELIVERY_FAILURE for traceback' is
printed. You can see that at the bottom of this listing.
BASH_VERSINFO=([0]="2"_[1]="05b"_[2]="0"_[3]="1"_[4]="release"_[5]="i586-mandrake-linux-gnu")
BASH_VERSION='2.05b.0(1)-release'
DEFAULT=sayu
DIRSTACK=()
DTLINE='Delivered-To:[EMAIL PROTECTED]
'
EUID=509
EXT=sayu
EXT2=
EXT3=
EXT4=
GROUPS=()
HOME=/home/virtual
HOST=jm-associates.com
HOST2=jm-associates
HOST3=jm-associates
HOST4=jm-associates
HOSTNAME=mercury.jmcollections.net
HOSTTYPE=i586
IFS='__
'
LISTVDOMAIN=/usr/bin/listvdomain
LOCAL=vmail-sayu
MACHTYPE=i586-mandrake-linux-gnu
[EMAIL PROTECTED]
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/var/qmail/bin:/usr/local/bin:/usr/sbin:/usr/bin:/bin
PIPESTATUS=([0]="0")
POSIXLY_CORRECT=y
PPID=9401
PS4='+_'
PWD=/home/virtual
[EMAIL PROTECTED]
RPLINE='Return-Path:_<[EMAIL PROTECTED]>
'
SED=/bin/sed
[EMAIL PROTECTED]
SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
SHLVL=3
TERM=dumb
UFLINE='[EMAIL PROTECTED]:48:14_2003
'
UID=509
USER=vmail
_=
/home/virtual/TMDA_DELIVERY_FAILURE_for_traceback
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...the rest of the message TMDA printed.
That's the background. Here's my best guess as to what's going on.
When the vmailmgr-vdir.sh script uses listvdomain to find a user's
home directory (maildir), it looks at listvdomain's exit code to
decide if the user was valid. If the exit code is not 0, the script
exits. If it is 0, the script uses a couple of shell tricks to parse
the output of listvdomain.
What seems to be happening is that, although listvdomain produces no
usable output, it is returning 0. When the script feeds the
non-existent output to the 'set' command, the environment gets printed
('set' does too many different things, depending on its paramters).
This output is returned to TMDA and TMDA tries to change directories
to that string, which is usually the user's home directory but in this
case is your full environment listing!
Again, I have no idea why this is happening. I have no access to a
Mandrake Linux system to test this any further. One idea I had about
a possible problem is a difference in the shell used to run the
script. The vmailmgr-vdir.sh script specifies that it wants to be run
by /bin/sh. On the BSDs (where I develop), it's the "real" /bin/sh.
In many Linux distributions, it's a link to bash. I renamed my copy
of bash 2.05 to sh to simulate this and tried running the
vmailmgr-vdir.sh script using that specific executable. It works
fine, so I don't think that's the problem.
So... I am going to add an additional test to the vmailmgr-vdir.sh
script and check that into CVS. I will first mail a private copy to
you so you can see if the fix actually works for you.
In the meantime, could you try something just to verify that my
hypothesis is correct? Could you su to the vmail user and run
vmailmgr-vdir.sh from the command line, like this:
$ /usr/local/src/vmailmgr-vdir.sh "sayu"
and tell me if you get the whole environment listed, like above? Once
I've got the script fixed, I'll get that to you to test, also.
Thanks much for your patience,
Tim
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
