Re: SA not filtering on distribution lists??!
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 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. I am suspecting something in how spamd is passing data to spamass-milter though the socket. spamd complains in the log when the userID doesen't exist: spamd: handle_user unable to find user: eatme 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. I have another mailserver configured with the same version of spamassassin, AND spamass-milter that does NOT do this. However, the problem server is FreeBSD 6.2 and the other server is FreeBSD 7.3 plus newer versions of all the perl modules that are used by SA, as well as sendmail version 8.14.4 on the newer server, so the milter libraries are newer. Ted On 6/15/2010 12:11 PM, Ted Mittelstaedt wrote: spamass-milter Ted On 6/15/2010 11:55 AM, Jari Fredriksson wrote: On 15.6.2010 21:31, Ted Mittelstaedt wrote: Hi All, OK I thought I knew SA but I have a strange one here that is probably due to a configuration directive set wrong, but I don't know what it is. System is running sendmail and SA 3.2.5 mails sent to user e-mail addresses get checked, and get the X-Spam-Status header placed in them. Mails sent to a e-mail distribution list (ie: sa...@example.com) do not get checked. any suggestions? SpamAssassin does no make any difference about sa...@example.com and other addresses. It scans all mail passed to it. If some mail is not passed to SpamAssassin, the decision to not scan is made in software that is responsible starting SpamAssassin (in form or spamc or spamassassin executables, or Mail::SpamAssassin perl library code). What is initiating SpamAssassin in your setup?
Re: SA not filtering on distribution lists??!
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
Re: SA not filtering on distribution lists??!
On 6/16/2010 1:15 PM, Martin Gregorie wrote: 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. OK after rereading the docs for spamass-milter and your explanation I think the light dawned. Here's the invocation of spamass-milter on the working server: /usr/local/sbin/spamass-milter -f -p /var/run/spamass-milter.sock And here is the invocation on the non-working server: /usr/local/sbin/spamass-milter -f -u root -p /var/run/spamass-milter.sock When I first setup spamass-milter I read the man page where it said: -u defaultuser Pass the username part of the first recipient to spamc with the -u flag. This allows user preferences files to be used. If the message is addressed to multiple recipients, the username defaultuser is passed instead. Note that spamass-milter does not know whether an email is incom- ing or outgoing, so a message from us...@localdomain.com to us...@yahoo.com will make spamass-milter pass -u user2 to spamc. I interpreted the -u root as a forced username, meaning any messages passed to spamc would contain root as their username, the idea being that since many recipient userID wouldn't exist (as the case with both an outbound user and an alias entry) it would provide a default user ID for the scoring, as well as insure that everything runs under the root userID But instead this is a polymorphic option basically meaning the exact opposite. From the looks of it, normally WITHOUT this userID, spamass-milter runs everything under the root userID. This is what you want if the mailserver is being used as both an incoming and outgoing mailserver. With this option, if the message recipient username portion happens to match a userID on the mailserver, then spamass-milter apparently runs spamc under that UID and uses that users score file/bays file, etc. This is great if the server is a destination server not used for outbound relays. Of course, you have the problem of aliases - but you either do what I did which is create a UID for each alias entry or you just don't use aliases at all. What is dumb, though is that spamass-milter is basically locked to sendmail (since no other MTA implements a milter interface, although I think that one other one out there is beginning to) and sendmail does alias expansions and comma expansions AFTER the milter is run - thus you would never get a situation of multiple recipients being passed to the milter unless the mail originated from the localhost server itself (very unlikely since even clients like Pine which are intended to run on the server, pass the mail via smtp to the localhost) Arr! Damn man pages! Ted 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
Re: SA not filtering on distribution lists??!
On Wed, 2010-06-16 at 15:27 -0700, Ted Mittelstaedt wrote: OK after rereading the docs for spamass-milter and your explanation I think the light dawned. Yep, your view looks right. I can't say more because once I got a look at sendmail configuration and saw the huge chunks missing from the O'Reilly Sendmail book I headed straight for Postfix. Of course, you have the problem of aliases - but you either do what I did which is create a UID for each alias entry or you just don't use aliases at all. They're useful: I redirect all root's mail to my usual mailbox and sweep up a bit of other stuff such as cron mail and mandatory mail and web usernames, so in a normal day I don't need to visit root at all. What is dumb, though is that spamass-milter is basically locked to sendmail (since no other MTA implements a milter interface, although I think that one other one out there is beginning to) and sendmail does alias expansions and comma expansions AFTER the milter is run - thus you would never get a situation of multiple recipients being passed to the milter unless the mail originated from the localhost To me the real problem is that, by calling spamass-milter before applying alias translation you are prevented from using aliases to allow users like postmaster, abuse and webmaster to be nonexistent by redirecting them to root or a single dedicated user and still be able to use spamass-milter's -u option for per-user SA rules. Thats also a situation where per-user SA preferences could be rather useful. server itself (very unlikely since even clients like Pine which are intended to run on the server, pass the mail via smtp to the localhost) Que? Surely an inbound message addressed To: j...@example.com, m...@example.com, s...@example.com would cause spamd to be run under the user specified with -u. However, I agree that -u wasn't a good option to use since it usually means use this user. Martin
Re: SA not filtering on distribution lists??!
On 15.6.2010 21:31, Ted Mittelstaedt wrote: Hi All, OK I thought I knew SA but I have a strange one here that is probably due to a configuration directive set wrong, but I don't know what it is. System is running sendmail and SA 3.2.5 mails sent to user e-mail addresses get checked, and get the X-Spam-Status header placed in them. Mails sent to a e-mail distribution list (ie: sa...@example.com) do not get checked. any suggestions? SpamAssassin does no make any difference about sa...@example.com and other addresses. It scans all mail passed to it. If some mail is not passed to SpamAssassin, the decision to not scan is made in software that is responsible starting SpamAssassin (in form or spamc or spamassassin executables, or Mail::SpamAssassin perl library code). What is initiating SpamAssassin in your setup? -- http://www.iki.fi/jarif/ I use PGP. If there is an incompatibility problem with your mail client, please contact me. Whenever you find that you are on the side of the majority, it is time to reform. -- Mark Twain signature.asc Description: OpenPGP digital signature
Re: SA not filtering on distribution lists??!
On 15.6.2010 21:31, Ted Mittelstaedt wrote: Hi All, OK I thought I knew SA but I have a strange one here that is probably due to a configuration directive set wrong, but I don't know what it is. System is running sendmail and SA 3.2.5 mails sent to user e-mail addresses get checked, and get the X-Spam-Status header placed in them. Mails sent to a e-mail distribution list (ie: sa...@example.com) do not get checked. sa...@example.com is not an email distribution list, it is an email address. It may be directed to some email distibution list implementation, but SpamAssassin hardly makes a difference. It's just an email address just like the rest of them. -- http://www.iki.fi/jarif/ I use PGP. If there is an incompatibility problem with your mail client, please contact me. Every why hath a wherefore. -- William Shakespeare, A Comedy of Errors signature.asc Description: OpenPGP digital signature
Re: SA not filtering on distribution lists??!
On Tue, 15 Jun 2010, Ted Mittelstaedt wrote: System is running sendmail and SA 3.2.5 How are they glued together? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- False is the idea of utility that sacrifices a thousand real advantages for one imaginary or trifling inconvenience; that would take fire from men because it burns, and water because one may drown in it; that has no remedy for evils except destruction. The laws that forbid the carrying of arms are laws of such a nature. They disarm only those who are neither inclined nor determined to commit crime. -- Cesare Beccaria, quoted by Thomas Jefferson --- 3 days until SWMBO's Birthday
Re: SA not filtering on distribution lists??!
spamass-milter Ted On 6/15/2010 11:55 AM, Jari Fredriksson wrote: On 15.6.2010 21:31, Ted Mittelstaedt wrote: Hi All, OK I thought I knew SA but I have a strange one here that is probably due to a configuration directive set wrong, but I don't know what it is. System is running sendmail and SA 3.2.5 mails sent to user e-mail addresses get checked, and get the X-Spam-Status header placed in them. Mails sent to a e-mail distribution list (ie: sa...@example.com) do not get checked. any suggestions? SpamAssassin does no make any difference about sa...@example.com and other addresses. It scans all mail passed to it. If some mail is not passed to SpamAssassin, the decision to not scan is made in software that is responsible starting SpamAssassin (in form or spamc or spamassassin executables, or Mail::SpamAssassin perl library code). What is initiating SpamAssassin in your setup?