By default, it seems SA will honor Received-SPF headers, while I would
guess most people aren't inserting it at their MTA, so it's a great
opportunity for spammers to forge the header to say their email passed SPF.
So, shouldn't it be disabled by default, by setting
ignore_received_spf_header to
On Thu, 21 Apr 2011 12:55:38 -0400, dar...@chaosreigns.com wrote:
By default, it seems SA will honor Received-SPF headers, while I would
guess most people aren't inserting it at their MTA, so it's a great
opportunity for spammers to forge the header to say their email passed
SPF.
this header
I meant to link to the relevant docs:
http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Plugin_SPF
On 04/21, Benny Pedersen wrote:
this header could be removed in mta, and readded if spf pass in mta, its
just not any stable milters that does it so far, but if headers is removed
Yep, I have a bunch of emails where google inserted a Received-SPF: pass
header that didn't hit SA's SPF_PASS rule. Then I started inserting that
header myself, and it hits SPF_PASS. So it is ignoring Received-SPF
headers from non-local relays. Nicely done.
(The ignore_received_spf_header
On Thu, 21 Apr 2011 13:36:16 -0400, dar...@chaosreigns.com wrote:
Ohh, sounds like it might ignore anything added before an internal
relay,
so the current default is fine?
this mail have:
Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
client-ip=140.211.11.3;
On 21/04/2011 1:41 PM, dar...@chaosreigns.com wrote:
Yep, I have a bunch of emails where google inserted a Received-SPF: pass
header that didn't hit SA's SPF_PASS rule. Then I started inserting that
header myself, and it hits SPF_PASS. So it is ignoring Received-SPF
headers from non-local
