Re: Sendmail milter weirdness

[Cassandra Lynette Brockett]

----- Original Message ----- 
From: "Dan Nelson" <address@hidden>
To: "Cassandra Lynette Brockett" <address@hidden>
Cc: <address@hidden>
Sent: Wednesday, July 02, 2003 3:30 PM
Subject: Re: Sendmail milter weirdness

<snip>
>
> Spamass-milter will pass a default username (i.e. whatever the argument
> to -u was when you started the milter) to spamc when there are multiple
> recipients.  This is probably what's happening.

Umm... So what's happening is the spammer is sending to multiple email
accounts?  That doesn't seem right if it is only happening with the one
account locally, and the address field when the message is fully delivered
is set to only having one recipient... unless somehow the message is being
re-written by the sendmail locally to remove all recipients and replace the
details with only the local delivered user - which seems like a complete
breach of how sendmail works...

> Also note that the snippet you pasted has two separate spamassassin
> runs in it; one for an unknown messageid, which got sent to spamc with
> "-u nobody", and one with messageid
> <address@hidden>, which got sent with
> "-u flinx".

Actually no, that's not right.  The first spamd process is from when
spamass-milter runs on the message - the second is from the run from
/etc/procmail (yes I run it twice, and as you can see from the score
difference - there is a reason for it).  Sendmail adds a messageid in the
case of this message as the spammer's software does not add a message-id
itself.  The message delivery snippet from the maillog file is for the one
message.

If you look, the messageid's are the same, as is the message queue sequence
:-

> Jul  1 23:55:22 hotline sendmail[31431]: h626tKn31431:
from=<address@hidden>, size=1236, class=0, nrcpts=1,
msgid=<address@hidden>, bodytype=8BITMIME,
proto=SMTP, daemon=MTA, relay=[211.198.18.97]

messageid :- address@hidden
queue id :- h626tKn31431

> Jul  1 23:55:28 hotline spamd[31442]: processing message
<address@hidden> for flinx:500.
> Jul  1 23:55:34 hotline sendmail[31438]: h626tKn31431:
to=<address@hidden>, delay=00:00:14, xdelay=00:00:06,
mailer=local, pri=31031, dsn=2.0.0, stat=Sent

message id :- address@hidden
queue id :- h626tKn31431

Both of those two fields look identical to me - and the message id is one
generated by the local sendmail as it did not receive a message id from the
original mail process.

And just a reminder, I run SpamAssassin twice for all messages - once from
spamass-milter and the second time from the /etc/procmail file on the
mailserver.  This allows me to have the best of both worlds in that I can
use the primary feature of the milter I need (rejecting based on too high a
score), and also get definitive SpamAssassin score checks, as spamass-milter
is still not passing through the message the same as it would for a run of
spamc from procmail.  Oh, and I run spamass-milter with these flags "-m -u
nobody -r35 -i127.0.0.1 -i192.168.250.0/23,192.168.252.0/23", and spamd with
these flags "-q -d".

Due to testing run previously, spamass-milter definately does not pass the
message through the same as the message goes through via procmail - this is
normal for the milter-run/actual-delivery style, as such I lose a lot of
features of spamassassin by running through the milter - for instance I
almost never get a razor check hit when the message is sent to spamd via the
milter - but when spamc is run from /etc/procmail I get a large percentage
of razor hits (for spam messages).  I do get pyzor checks hitting though -
which is fine as far as I am concerned, but when I get checks such as the
above one :- where the message id is not brought over from the milter, so
spamassassin doesn't tag the message with the right score due to messageid's
and other such things it just proves I need to keep the current system in
place for a while longer.  I am attempting to find each and every one of the
missed checks and pass the details along, but it is difficult to actually
trace down the reason(s) a message isn't tagged - as I don't have a copy of
the original received message (before sendmail actually did it's updates for
local delivery).  Any ideas on how I might be able to get those messages?
Because at that point I would definately have the details to be able to
provide the correct information to fix the problems I see.

Regards,
    Cassandra





---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 6/30/2003