Mark wrote:
-----Original Message-----
From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED] Sent: dinsdag 17 oktober 2006 5:37
To: Matt Kettler
Cc: Jo Rhett; Magnus Holmgren; users@spamassassin.apache.org
Subject: Re: ALL_TRUSTED creating a problem


As discovered today, Jo's milter isn't adding the required
received header for his MX before passing the mail
to SA which is what is causing his problem.

Jo's milter ain't broken: incoming email is passed to a milter prior to
sendmail adding its local Received: header. That's the way milters work:
they are hooks into the SMTP dialogue. When that communication ends, and
the milter has not deciced to reject or discard the message, only then
will sendmail actually prepend it's own Received: header.

I'm fully aware of how the Sendmail milter interface works. A milter that is not providing SpamAssassin with the required message context "ain't not" broken. The primary purpose of the interface between the milter (the actual milter, not the milter interface between the milter and Sendmail) and SpamAssassin is to provide SpamAssassin with the complete message and message context.

SA, which was initially designed as a mail filter to be called post SMTP, expects to see the complete set of received headers. The data contained in the final received header is vital to a large number of the decisions SA makes.

Since SA is not itself a milter (if it were there would be no point in yet another milter to access the SpamAssassin libraries) it has no way to access the symvals that a milter would have access to. Thus any milter that utilizes the SpamAssassin libraries must provide SA with the info that it would normally see in a post SMTP environment. Providing the SA factory with some context object would do it, but would be dependent on the milter interface spec that the milter itself is interfacing with. It's much more simpler, and a heck of a lot more portable, to just have the milter forge a received header (based on the context object it has access to) for the sole purpose of providing SpamAssassin with the required info.

Anyone who has considered SA's origin as a post SMTP filter, or even paid attention to the debug output from either "spamassassin" or "spamd" would immediately see why this is important and necessary. For anyone who hasn't, there's always the MTA Intergration Development note on the wiki: http://wiki.apache.org/spamassassin/MtaIntegrationDevNotes


Daryl

Reply via email to