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
