[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-devel
Subject:    [Bug 6535] Unparseable received header for authenticated mail sent
From:       bugzilla-daemon () issues ! apache ! org
Date:       2011-01-19 22:01:49
Message-ID: 201101192201.p0JM1mT1007587 () thor ! apache ! org
[Download RAW message or body]

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6535

--- Comment #11 from Steve Freegard <steve.freegard@fsl.com> 2011-01-19 17:01:43 UTC ---
 > It's also one of the reasons that I disagree with Barracuda's recommendation
to
> use "deep header parsing".  It's the same thing as not using last-external
> relay and we know it has FPs especially due to DHCP pools.

Just wanted to make a further point here.

The Barracuda saga was caused by the deep-header parsing using RBLs that stated
they shouldn't be used for that purpose *and* they were doing this at SMTP time
(e.g. as a boolean accept/reject).

Here - we're scoring on it; and that's by design.  The RCVD_IN_BL_SPAMCOP_NET
has gone through the scoring process as a deep-header parsing test and been
scored accordingly because of that.

Which also gives me the idea; why don't you add a -lastexternal variant of the
SpamCop lookup to your sandbox and see how it fares in the mass-checks compared
to the current version.

To continue Mark's point about non-parsing of a Received header as a bug;
consider that the patch I provided doesn't just supply the IP address of that
hop; but also the HELO used by that host (which *is* definitely useful in
rules).

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[prev in list] [next in list] [prev in thread] [next in thread]