In article <[EMAIL PROTECTED]>, Stephen Warren <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Doug Hardie wrote: > > I am doing the initial testing of tmda and installed it with minimal > > configuration. I setenv for RECIPIENT, SENDER, and EXTENSION and > > manually cat'd a message to tmda. It recognized that it needed to send > > a confirmation which it did, but then it put the incoming message in > > root's pending directory, not the user's. > > Are you running tmda as user root, with root's HOME environment variable > defined (or running tmda as the correct non-root user, but using an su > mechanism that doesn't reset the HOME environment variable to the > correct user-specific value, thus leaving it set to root's HOME value?) Setting the HOME env variable before calling tmda-filter does work. I didn't see HOME used in the code, but it must be there somewhere. That is the easiest way to get NIS users to work. I decided to create my own wrapper for tmda-filter as procmail and others introduce yet another layer of overhead with reading the entire message and processing it just to set the env variables. I created a small c program that sets the variables. My original idea was to have it set the variables and then execv tmda-filter. That would eliminate a couple of fork overheads. However, the note about the 99 return code indicates that approach will have problems. I am currently reading stdin and piping it to tmda-filter which allows me to alter the return code as described in earlier postings. I did find a reference to the 99 code in tmda-rfilter, but under the conditions it says the 99 will be returned, I am not receiving that. I am always getting a zero. Has the 99 situation been changed or is my testing too light to have encountered the issue? I now have the receive side of mail properly using sendmail, clamav, dspam, and tmda. The interesting thing is that a ktrace of the entire process (including sendmail, dspam, and tmda) shows that 85% of the ktrace output is python reading (and re-reading) its various library modules. dspam uses most of the remaining 15%. However, tmda-rfilter code is read at least 3 times. In addition, /etc/hosts, /etc/services, the password file etc. are read numerous times. Often several times in a row. There is an unbeliveable amount of overhead in this. The last remaining issue is to be able to have mail sent by users get added to the whitelist. We use two seperate mail servers. One for incoming and one for outgoing. Is there a way to update the whtielist from another server? _____________________________________________ tmda-users mailing list (tmda-users@tmda.net) http://tmda.net/lists/listinfo/tmda-users
