On Sun, 23 Oct 2005, Richard Clayton wrote:
> hmmm... there appears to be an underlying assumption here that the
> bad guys will not preload the email with interesting looking
> Received header fields containing misleading "envelope-sender"
> comments
A good strategy for auto inspecting headers is to work down them
systematically (i.e from the latest towards the earlier ones), paying
attention only to those you have reason to trust, and stopping after
you hit one rated as untrustworthy for some reason.
For example, with certain otherwise-bona-fide relaying hosts of
importance to us which have inadequate anti-spam defences, we work our
way down past *their* headers - which we can trust - until we find the
header which shows them accepting the mail from an untrusted IP; then
we look up that IP in DNSrbls etc. and add appropriate spam penalties
to what spamassassin is reporting.
We'd been doing this since before Spamassassin was documenting the
trusted_networks configuration option - find that a little way into
the "Network Test Options" part, e.g at this URL:
http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin_Conf.html#network_test_options
Based on the explanation there, I think it's meant to do pretty much
what we were previously doing as a one-off - just in a rather more
general way, and we could well consider changing to it at the next
major workover. Please correct me if that's a misunderstanding, as
you may be able to save us some effort ;-)
Certainly it's been our observation that some spammers insert what are
supposed to be convincing-looking Received: headers, but they're
further down the stack (earlier in the chronology), and thus beyond
the first untrusted header if the software is working to plan.
hope that helps
