Matt Kettler said:
> This is the result of the way SA is invoked and the limited information
> it's given when it runs. SA is designed as a standard message filter, so it
> never sees the message delivery envelopes, just the headers and bodies.
>
> Unless your MTA inserts header which tell who the actual recipient is, SA
> has no way of knowing and must rely on what is available in the headers.
> This makes the all_spam_to configuration a bit of a kludge because it's not
> completely effective, but it's the best that SA itself can do given what
> access it has to the message.
Oh -- BTW -- something occurred to me. There *IS* an API that
milter/MTA-plugin developers can use to specify this info to SpamAssassin,
after all. It's just implicit and hadn't occurred to me before.
Our all_spam_to, etc. black/whitelisting code will check the following
headers, since about SpamAssassin v2.40:
X-Envelope-From: for the MAIL FROM: SMTP command
X-Envelope-To: for the RCPT TO: SMTP command
Some MTAs already create those headers, which is why they're already
supported. If an MTA plugin adds these headers, it will allow
white/blacklisting to work correctly with the SMTP data.
And for completeness:
X-HELO: for the HELO SMTP command
hey, why not, it'll make a good Bayes token ;)
--j.
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
