Re: Sendmail milter weirdness

[Dan Nelson]

In the last episode (Jul 02), Cassandra Lynette Brockett said:
> 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.

Ok, that makes more sense.  Unfortunately, Message-ID is one of the
fields I can't easily fake when sending to spamc; for spamassassin to
trust it, it has to be before all the other received headers, and
spamass-milter currently writes them as sendmail sends them.  I'd have
to buffer them all, and only insert a messageid at the top if none
existed anwhere.

> 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

I'm not sure what's up with razor; assuming the username gets passed to
spamc, it should work just as if procmail called it.

> 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?

You can try adding "-d spamc" to spamass-milter, which will make it log
the data it sends to spamc.  Not very easy to extract back into a real
message, but good enough to see the headers that get sent.

-- 
        Dan Nelson
        address@hidden