Daryl, this part of the conversation is academic at best. Amavisd
milter has been patched and is providing the proper received headers,
and network autodetection is still broken.
I was trying to build a test case for documenting the flaws, and
after reviewing the code realized that it would take less effort to
rewrite the entire autodetection bit than to explain to Matt Kettler
and others why they need to fix it. I'll submit back something that
works reasonably, and fails gracefully.
On Oct 17, 2006, at 7:05 PM, Daryl C. W. O'Shea wrote:
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
--
Jo Rhett
Senior Network Engineer
Network Consonance
