spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Feature list for SPFv3

2009-07-20 12:14:13
On Mon, 20 Jul 2009 16:53:58 +0100 alan <spfdiscuss(_at_)alandoherty(_dot_)net> 
wrote:
At 15:31 20/07/2009  Monday, Dotzero wrote:
On Mon, Jul 20, 2009 at 10:14 AM, Scott 
Kitterman<scott(_at_)kitterman(_dot_)com> 
wrote:
On Mon, 20 Jul 2009 15:44:36 +0200 Alessandro Vesely 
<vesely(_at_)tana(_dot_)it> 
wrote:
I'm no expert on standardization practices, but I read on rfc 2026
that "A Proposed Standard specification [...] has resolved known
design choices", and the IESG Note indeed expresses concern about SPF
and SenderID not being conciliable, as though the two approaches
typify the corresponding design choices. My understanding is that we
shall resolve that conflict before we get on the standards track. And
we need "spf3" for that.

Not at all (I'm not an expert either, but this is my guess).  If you 
look
at the Sender ID RFCs (particulary, IIRC, the one that defines PRA), 
there
is an additional note from the IESG about Sender ID.  These have not 
been
resolved.

There has been a proposal to move both the SPF and Sender ID RFCs to
historic status since they are 'superceded' by DKIM.  I objected to this
for SPF.  No one objected about Sender ID.

I think Sender ID should be transitioned to historic and the conflict
resolved that way.  We cannot afford to require all SPF records to be
republished as we move forward.

Scott K


I would agree with Scott on this. It is not simply about whether we
can afford to require republishing of SPF records. There are specific
issues with SenderID that came up during the experimental period that
justify relegating it to a historic status. SPF has enough of a track
record that it should be retained and moved to a regular track.

but these issues only arise if the sender only publishes SPF and ignores 
sender-id
{as sender-id checking clients will mis-use the SPF record in ONLY this 
case}

if we mandate the use of a {blank is enough} sender-id policy with SPF the 
issue is no more
ie
for domain have
"v=spf1 redirect:_spf1.domain.tld"
"spf2.0/mfrom redirect:_senderid_mfrom.domain.tld"
"spf2.0/pra +all"

and have _spf1.domain.tld and _senderid_mfrom.domain.tld
return the same spf record
with appropriate "v=spf1 or "spf2.0/mfrom start

thus no crosstalk or conflict and issue resolved

but only if SPF group advises people to mitigate rather than ignore 
sender-id will it go away till v3 

People will always do odd things with SPF records because they believe it's 
useful.  We can't stop it.

Moving the Sender ID RFCs to historic is sufficient to stop standardized 
misuse.  The other kind we can't control and shouldn't try.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>