Magnus Holmgren wrote:
On Thursday 19 October 2006 09:55, Jo Rhett took the opportunity to say:
Mark wrote:
We cannot really say SA's autodetection is broken, because SA is designed
to be called post-SMTP. Nor that a milter is broken per se for not adding
a Received: header, as that is the responsibility of the MTA itself. But
a milter using SA *can* be said to be broken if it's not proving SA with
the required post-SMTP view of things. Instead of patching SA, or trying
to "fix" it even, any milter using SA should simply DTRT (Do The Right
Thing): which is: add a pseudo Received: header before handing it over to
SA.
You'all are way behind the boat. We've already patched it to support
the undocumented requirement. That's not an issue.
Perhaps SA being focused on "post-SMTP" is the problem here. Why is
this the focus? In the modern world, you want to reject during SMTP not
send backscatter to the poor folks whose e-mail got forged.
Frankly, a milter environment is the only possible right way to run SA.
So why the constant comments as if this is some one-off weird config?
Exim, another MTA, adds a preliminary Received: line before processing the
DATA ACL, which is usually where spamd is called from (this is to say that
not all MTAs have problem calling SA during SMTP). This lets SpamAssassin
handle varying setups in a general way, without having to pass the parameters
of the last hop out-of-band (e.g. command-line arguments). Since obviously
Sendmail/Postfix and the milter protocol are different, a milter that talks
to SpamAssassin must do the part of adding that preliminary header.
Just to straighten things out, are you saying that auto-detection doesn't even
work when there is a single "Received: from remote.example.com ([w.x.y.z]) by
my.domain.example with ESMTP id 1234-567-9" and my.domain.example resolves to
a local interface address?
Magnus, you're still stuck on old news. amavisd-milter has been patched
to add the (undocumented) required forged Received: line. This isn't
related to that any more.
I'm saying that in reviewing the code, it is fairly clear that the code
does an adequate job but not a great job and it will fail too easily,
too often and the failure will usually be a decrement of the score -
which is the wrong way to fail (should fail with no effect on the score)
--
Jo Rhett
Network/Software Engineer
Net Consonance
