spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Outcome of the IESG appeals

2005-12-08 06:33:10
In <200512081312(_dot_)34718(_dot_)julian(_at_)mehnle(_dot_)net> Julian Mehnle 
<julian(_at_)mehnle(_dot_)net> writes:

Wayne Schlitt wrote:

On the downside, the IESG seems to think that this warning about
SenderID belongs in the SPF spec, which will probably just confuse the
issue between SPF and SenderID some more.

"this warning"?  I don't think _this_ warning (that which resulted from 
William's appeal) is supposed to be inserted into the SPF spec.

Well, Brian said that the note would be inserted in all four I-Ds.


...then you're mostly right.  (Although I do see some value in warning 
readers of the RFC about possible conflicts.)

We should examine the wording of that IESG note...

| [snip]  Participants
| publishing SPF experiment DNS records should consider the advice given in
| section 3.4 of RFC XXXX (draft-lyon-senderid-core) and may wish to
| publish both v=spf1 and v=spf2.0 records to avoid the conflict.

...to find out if it perhaps contradicts the actual wording of the SPF 
spec:

| [...]
| Without explicit approval of the domain owner, checking other identities
| against SPF version 1 records is NOT RECOMMENDED because there are cases
| that are known to give incorrect results.

Such a contradiction could be a reason to ask the IESG to change their IESG 
note for the SPF spec, or to escalate the appeal to the IAB.

I'm not sure that there is a contradiction here.  The IESG note says
that peoplem *may* want to consider adding both records, not that they
MUST.  The SPF draft says "NOT RECOMMENDED" not, "MUST NOT".  SPF
records can be used with other identities if you are careful with the
technical details.  For example, I can't think of any problems that
would be caused if SenderID only gave PASS and NEUTRAL results.


After all, none the IESG notes accounts for the fact that "the SPF 
experiment" was there _way_before_ "the Sender ID experiment" was.  Also I 
don't think the SPF RFC referring to the Sender ID RFC ("section 3.4 of 
RFC XXXX") is appropriate.

From the IESG's point of view, this is the only appropriate solution.
They are approving both SPF and SenderID, and so a note needs to be
made in the SPF spec about the conflict.


And finally, should we consider letting the SPF spec be formalized by some 
other, more serious standards body, such as the Open Group?  (I think 
there was an offer by them to publish the SPF spec.)

I highly doubt that any other standards body is going to be more
vendor neutral.


For what it is worth, I will not approve of an appeal to the IAB.
That doesn't stop people from filing appeals, but I see very little
chance of anything positive happening from it and I think it will just
waste more time.



-wayne

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

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