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