JLM <[EMAIL PROTECTED]> writes:
> Thanks for the hints. Sorry it's taken me nearly a month to get back
> to you.
I understand. I've been busy too, lately.
> > Second, it's possible, with a bit of finagling, to configure TMDA
> > as a "null" filter. In other words, you can set it not to
> > confirm; to accept all mail and simply deliver it.
>
> This may be the best way, in the interim, to turn TMDA off for certain
> users. I searched the list archives, but I couldn't find any info on how
> this might be accomplished. Any suggestions?
By default, ACTION_INCOMING is "confirm". If you have no incoming
filter at all and you set ACTION_INCOMING = "accept" in
~/.tmda/config, all messages will be passed through.
> >> command = /usr/bin/tmda-filter -c /var/mail/$SITENAME/$USERNAME/tmda/config
>
> It turns out that the correct command in our case is:
>
> command = /usr/local/tmda/bin/tmda-filter -c \
> /var/mail/tmda/${extract{sitename}{$address_data}}/$local_part/config
This is Exim-specific manipulation of Exim-specific variables, which I
know nothing about. However, it looks like you're getting the data
you need to correctly compose the path.
> >> Assuming we get the mail to TMDA somehow, how can we get the mail
> >> delivered? For example, one of the options is listed as:
> >>
> >>
> >> DELIVERY = "/var/mail/$local_part"
> >
> > I'm not sure where you found this example of DELIVERY. The above
> > syntax won't work, as given. Perhaps whoever suggested this is using
> > '$local_part' as a placeholder.
>
> $local_part, it turns out, is an Exim variable. It would be great if we
> could somehow pass this information to TMDA, but it hasn't worked so
> far.
Try this (I'll explain below how to get $EXT set properly):
DELIVERY = os.path.expandvars("/var/mail/${EXT}")
> For example:
>
> command = /usr/bin/python2.2 /usr/local/tmda/bin/tmda-filter \
> -S /usr/local/tmda/bin/getpath.pl \
> ${extract{sitename}{$address_data}} $local_part
>
> ...doesn't set the HOME environment variable to the MailDir as the -S flag
> is supposed to do. I'm not sure why this doesn't work, particularly since it
> works with the -c option.
This is a little complex. The -S parameter is designed for qmail
virtual domains. I don't know how Exim treats virtual users (maybe it
doesn't have the idea at all). In any case, you might be able to make
it work....
First, you don't need to pass the parameters to getpath.pl on the
tmda-filter command-line. When tmda-filter calls getpath.pl it passes
the username, which it derives from an environment variable named
$EXT, and the domain name of the recipient's address, which it expects
to find in an environment variable named $HOST.
$EXT is just the left-hand side ($local_part, probably) of the email
address. For qmail virtual domains, the system user that controls the
virtual domain is prepended to the local part and $EXT is the original
envelope recipient with that prepend stripped off.
If you followed the TRANSPORTS CONFIGURATION instructions for Exim at
http://tmda.net/config-pre.html, $HOST and $EXT could also be added to
the environment like this:
environment = EXTENSTION=${substr_1:$local_part_suffix}:\
EXT=$local_part:\
HOST=$domain:\
[EMAIL PROTECTED]
You script, getpath.pl, needs to take the parameters in the opposite
order as you have above. tmda-filter will call it like this:
/usr/local/tmda/bin/getpath.pl "$EXT" "$HOST"
If something this simple won't work, we can always try to make the -S
script processing more flexible. Right now, it's really targeted at
qmail.
> But moving from a global to a local TMDA set-up at least gets around
> this problem for the moment. Each user now just has the requisite
> values hard-coded into their individual config files:
>
> DELIVERY = "/var/mail/MySiteName/MyUserName/"
>
> > Assume for the moment that _SITENAME_
> > and _USERNAME_ are in the environment set up by Exim when tmda-filter
> > executes. Here's how you could set TMDA's DELIVERY variable.
> >
> > import os # this line should be a standard part of the config file
> > site = os.environ['_SITENAME_']
> > user = os.environ['_USERNAME_']
> > DELIVERY = os.path.join('/var/mail', site, user)
> >
> > This sets DELIVERY's value to '/var/mail/${_SITENAME_}/${_USERNAME_},
> > in shell syntax; /var/mail/catseye.net/tim, to use me as an example.
>
> This would work well if we didn't have virtual users, but that's what XAMS
> is for. All of the user data is stored in a MySQL database, so I don't
> believe the os.environ[] calls will work in an XAMS environment.
Exim has the recipient's email address when it delivers the mail. Are
you saying that SITENAME and USERNAME are completely unrelated to the
domain part and the local part of the virtual user's email addess;
that you have to look up the email address in MySQL to find out the
SITENAME and USERNAME? If so, I'll need to think about this a bit,
but it still might be doable.
> I had hoped that the -S option to tmda-filter would pass on these
> variables, but it doesn't seem to be working. If I call it with the
> -S command above and then set DELIVERY = "~/" then it just responds
> with "DeliveryError: not a Maildir! (/)"
The -S switch does nothing but call the script to get a user's home
directory and sets the $HOME variable to that directory, which causes
later user of the '~' character (in the config file, for instance) to
be expanded to that directory. You still have to specify a mailbox or
maildir (maildirs end with '/') in any DELIVERY statement.
Tim
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
