You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ted Mittelstaedt <te...@ipinc.net> on 2010/06/15 20:31:34 UTC
SA not filtering on distribution lists??!
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: sales@example.com)
do not get checked.
any suggestions?
Ted
Re: SA not filtering on distribution lists??!
Posted by Martin Gregorie <ma...@gregorie.org>.
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: john@example.com, mary@example.com, sue@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??!
Posted by Ted Mittelstaedt <te...@ipinc.net>.
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)
Arrgggg! 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
>> 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??!
Posted by Martin Gregorie <ma...@gregorie.org>.
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??!
Posted by Ted Mittelstaedt <te...@ipinc.net>.
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: sales@example.com)
>>> do not get checked.
>>>
>>> any suggestions?
>>
>> SpamAssassin does no make any difference about sales@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??!
Posted by Ted Mittelstaedt <te...@ipinc.net>.
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: sales@example.com)
>> do not get checked.
>>
>> any suggestions?
>
> SpamAssassin does no make any difference about sales@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??!
Posted by Jari Fredriksson <ja...@iki.fi>.
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: sales@example.com)
> do not get checked.
>
> any suggestions?
SpamAssassin does no make any difference about sales@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
Re: SA not filtering on distribution lists??!
Posted by Jari Fredriksson <ja...@iki.fi>.
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: sales@example.com)
> do not get checked.
>
sales@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"
Re: SA not filtering on distribution lists??!
Posted by John Hardin <jh...@impsec.org>.
On Tue, 15 Jun 2010, Ted Mittelstaedt wrote:
> System is running sendmail and SA 3.2.5
How are they glued together?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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