Skip Menu |
 

This queue is for tickets about the Mail-SPF CPAN distribution.

Report information
The Basics
Id: 67073
Status: stalled
Priority: 0/
Queue: Mail-SPF

People
Owner: Nobody in particular
Requestors: jdfalk [...] returnpath.net
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: spf2 record includes spf1 record
Date: Tue, 29 Mar 2011 18:13:16 -0600
To: "bug-mail-spf [...] rt.cpan.org" <bug-mail-spf [...] rt.cpan.org>
From: J D Falk <jdfalk [...] returnpath.net>
Download (untitled) / with headers
text/plain 1.4k
We've run into an interesting issue -- not sure if it's a bug, or a difference in interpretation. The spf2.0/pra record for vodafone.it has two include statements: vodafone.it text = "v=spf1 include:spf1.vodafone.it include:aspmx.googlemail.com include:t.contactlab.it ~all" vodafone.it text = "spf2.0/pra include:spf2.vodafone.it include:aspmx.googlemail.com include:senderid-a.contactlab.it -all" Google's included record redirects to a record which is only spf1: aspmx.googlemail.com text = "v=spf1 redirect=_spf.google.com" _spf.google.com text = "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all" One possible interpretation is that when processing spf2 records & includes, spf1 records should be ignored -- we believe that's what Mail::SPF is doing when it says "Included domain \'aspmx.googlemail.com\' has no applicable sender policy." Another is to interpret the included spf1 record the way SenderID interprets standalone spf1 records, which we're pretty sure is what Microsoft is doing when they mark the same message as having passed. But since only Microsoft cares about SenderID these days, our clients want our tools to act the way theirs do -- and we use Mail::SPF. Is this behavior configurable? Or is something else going on? -- J.D. Falk Editor, The Received: Blog Return Path Inc. http://www.returnpath.net/blog/received/
Subject: Re: [rt.cpan.org #67073] spf2 record includes spf1 record
Date: Wed, 30 Mar 2011 05:26:11 +0000
To: bug-Mail-SPF [...] rt.cpan.org
From: Julian Mehnle <julian [...] mehnle.net>
Download (untitled) / with headers
text/plain 1.2k
Hi J D, you wrote: Show quoted text
> [...] > One possible interpretation is that when processing spf2 records & > includes, spf1 records should be ignored -- we believe that's what > Mail::SPF is doing when it says "Included domain 'aspmx.googlemail.com' > has no applicable sender policy." > > Another is to interpret the included spf1 record the way SenderID > interprets standalone spf1 records, which we're pretty sure is what > Microsoft is doing when they mark the same message as having passed. > > But since only Microsoft cares about SenderID these days, our clients > want our tools to act the way theirs do -- and we use Mail::SPF. Is > this behavior configurable? Or is something else going on?
The first interpretation is correct. It is a conscious design choice. RFCs 4408 (SPF) and 4406 (Sender ID) conflict in this regard, and since Mail::SPF is meant to be a reference implementation of RFC 4408, this is the school of thought it follows. The support for "spf2.0" records was added merely as an exercise and as a courtesy to the user. The behavior is not configurable, although it could possibly be made that way. It's certainly not a priority for me at this time. I would consider taking a patch, though, that makes it configurable in a way consistent with Mail::SPF's design. -Julian
Subject: Re: [rt.cpan.org #67073] spf2 record includes spf1 record
Date: Mon, 11 Apr 2011 18:48:58 -0600
To: "bug-Mail-SPF [...] rt.cpan.org" <bug-Mail-SPF [...] rt.cpan.org>
From: J D Falk <jdfalk [...] returnpath.net>
Download (untitled) / with headers
text/plain 228b
Thanks for the reply. I think this makes sense. Not sure if/when we'll be able to submit a patch, but we'll keep it in mind. -- J.D. Falk Director, Internet Standards & Governance Email Intelligence Group Return Path Inc.
Download (untitled) / with headers
text/plain 253b
FYI, I haven't had the time to deal with this yet — from my personal PoV the issue simply doesn't have a very high priority since it merely concerns Sender ID support. I'm going to mark the issue as stalled but will gladly accept a patch at any time.
Download (untitled) / with headers
text/plain 256b
Unfortunately the author of this ticket, J. D. Falk, passed away in late 2011: http://jdfalkmemorial.org I will still accept a patch from anyone interested in making this behavior configurable in Mail::SPF, but I will not make it an initiative of my own.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.