On Mon, 20 Jul 2009 20:06:45 +0200 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
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.
My recollection was the IESG note was slightly different. I'm not in a
position to check right now.
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.
It doesn't. That's why I put it quotes. It does, to some extent,
supercede 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.
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.
Sure we can. There's no obligation for standards track documents to
consider old experiments. The SPF project already gives recommendations
wrt Sender ID. There's no need to give it undue emphasis by dealing with
it in an RFC.
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?
You'd have to ask Hotmail about what they expect their SPF records are meant to
mean. RFC 4408
describes what SPF records are and the only use of which I am aware that is
suitable for
standardization. No, I don't think we have any obligation to deal with
cleaning
up after Microsoft.
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.
Now you are describing something not backward compatible. That should wait
for an eventual SPF v 3.
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