Tim Legant <[EMAIL PROTECTED]> writes:
>>> 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.
That certainly seems easy enough. I will give that a try.
>> 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).
XAMS is what provides the virtual user management. As far as Exim is
concerned, it thinks it's just delivering mail to regular ol' MailDirs. XAMS
handles the process of looking up the user data in MySQL and then passing
the needed user name, site name, and domain info to Exim.
> 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"
Ugh. Thank you for pointing out how badly I botched this. The getpath.pl
script already takes the parameters in the order you mentioned above -- I
just goofed when I was testing it from Exim, and I reversed the order. Not
to mention, as you point out, the parameters don't need to be explicitly
stated. I will try it again as you suggested above.
> 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.
That sounds great. I'll give the above a shot and let you know how it goes.
>> 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'm sorry -- as usual, I didn't explain this very well. The USERNAME is the
same as the local part of the virtual user's email address. As I understand
it, XAMS allows multiple domains to be grouped as one "site." So, for
example, a site called "Widgets" could conceivably contain widgets.com,
widgets.org, and widgets.net, and mail sent to [EMAIL PROTECTED] could all
be routed to a single real MailDir. So in order to determine the correct
MailDir path, two pieces of information are needed: the user name and the
domain. A simple DB lookup with the user name and domain produces the site
name, which is used to assemble the MailDir path. Does this make any things
any clearer? Please let me know if I'm not making sense. ;)
>> 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.
I guess I also neglected to mention that in this virtual user environment,
the only "home" is the virtual users's MailDir. The way things are currently
set up, the MailDir is at:
/var/mail/SITENAME/USERNAME/
...and individual TMDA config data is at...
/var/tmda/SITENAME/USERNAME/{config, crypt_key, filters, pending, etc.)
So if we call tmda-filter from the Exim transport via:
command = /usr/bin/python2.2 /usr/local/tmda/bin/tmda-filter \
-S /usr/local/tmda/bin/getpath.pl
...then shouldn't the $HOME variable then contain the full MailDir path?
/var/mail/SITENAME/USERNAME/
That's why I set DELIVERY = "~/" -- $HOME should now specify the full
MailDir path, shouldn't it?. Perhaps that "not a Maildir! (/)" error was
simply caused by my transport goof mentioned above.
Any additional thoughts before I begin hacking away again? ;)
Justin
PS:
I suppose there's no reason we couldn't store individual users' TMDA data in
the MailDir itself:
/var/mail/SITENAME/USERNAME/.tmda/{config, crypt_key, filters, etc.)
...instead of the current...
/var/tmda/SITENAME/USERNAME/{config, crypt_key, filters, etc.)
Would using the former method make things any easier? Or does it not really
matter?
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
