On Wed, 2010-06-16 at 12:14 -0700, Ted Mittelstaedt wrote: > Well I have a bit more info on this now. > > The problem goes away IF I put the aliases as usernames into > the password file > What you've demonstrated is that this is an MTA problem whose implications depend critically on when and how the MTA uses the aliases file in conjunction with the collection of known valid mail destinations to determine whether mail is deliverable. In particular, can matter whether this is before or after calling the milter/invoking SA.
> For example: > > tedm - in password file > eatme - not in password file > > /etc/mail/aliases > > eatme: tedm > > problem happens. > > tedm - in password file > eatme - ALSO in password file > > /etc/mail/aliases > > eatme: tedm > > problem DOES NOT happen. > It appears from this that your MTA calls the milter BEFORE using aliases to determine the message's destination. Other MTAs may get a different result by calling the milter after the aliases translation chain has been completed. > I am suspecting something in how spamd is passing data to spamass-milter > though the socket. > It matters a lot whether this is done before or after the message is passed to SA via the milter. IOW, if the deliverability check is done before the milter is called, SA will never see undeliverable mail. Its nothing to do with the way spamc/spamd work - they can only handle messages that are passed to them and don't have any ability to skip a message except on size grounds. > spamd complains in the log when the userID doesen't exist: > > spamd: handle_user unable to find user: eatme > This sounds like a combined MTA/milter thing. If the MTA passes the message to SA before it has used aliases to determine where the message is to be delivered *AND* your milter is running SA under the destination user then of course you'll see SA fail to process the message. This is not for some internal SA quirk, but because the OS prevents it from running under a non-existent user or one that won't grant it permission to execute. > even though the userID is in the alias file. Whenever I see that > complaint then I see the following a bit later in the log: > > ail sm-mta[88401]: o5GIG91G088401: Milter delete: header X-Spam-Status: > No, score=0.7 required= > ail sm-mta[88401]: o5GIG91G088401: Milter delete: header > X-Spam-Checker-Version: SpamAssassin 3.3.1 (2 > > and while the message is delivered, it is lacking any evidence that it > has been checked with Spamassassin, (no headers) even though > /var/log/maillog clearly showed that it was. > What you're seeing is the milter cleaning up after spamd was unable to run as the requested user. Martin
