Scott Kitterman wrote:
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.
The four of them look exactly like one another (except for the
"aParticipants"). However, the paragraph about Resent-* headers is for
SenderID only.
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'm not sure how DKIM supersedes SPF. For example, if I wanted to send
feedback loop reports for failed DKIM verification, I would only
bother SPF-valid senders.
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.
I agree republishing shouldn't be a requirement. I also agree SenderID
should be transitioned to historic. However, it is not clear to me if
a new RFC can pretend that SenderID never existed, and avoid to even
mention it, but at the same time ostentatiously point an invisible
finger to the "Category: Historic" field of the relevant SenderID's
RFCs for the readers to take note.
Even hotmail.com's TXT records start with "v=spf1", and I wonder if
they mean they should be interpreted as "spf2.0/mfrom,pra". What
should newcomers publish? How are existing records to be interpreted?
As a new RFC oughts to be part of the solution, it should probably
mention "spf2.0" and what is the correct record selection and
interpretation in the various cases. Shouldn't it?
We may be able to do that without introducing yet another version.
Will it be much simpler that way? And how about the transition to SPF
RRs exclusively? In case the new RFC will be a Proposed or Draft
Standard, we will have to stick to that text for an eventual Full
Standard.
-------------------------------------------
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