-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wayne Schlitt wrote:
William Leibzon writes:
I also received the answer to my appeal. IESG basicly agrees that use
of Resent fields is not compatible with standards but considers that
is not enough to not publish the draft for EXPERIMENTAL status and
instead chooses to add [yet another] note about it:
This is good news, I guess. SenderID can't be made a standard without
critical changes to the PRA.
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.
However if you meant the other IESG note about the re-use of "v=spf1"
records by Sender ID...
Ugh.
So, what we got out of this appeal is a note in the SPF draft blessing
the opt-out requirement in the SenderID drafts. I can't see how this
helps us at all, and may well hurt.
...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...
| Note that the Sender ID experiment may use DNS records which may have
| been created for the current SPF experiment or earlier versions in this
| set of experiments. Depending on the content of the record, this may
| mean that Sender-ID heuristics would be applied incorrectly to a message.
| Depending on the actions associated by the recipient with those
| heuristics, the message may not be delivered or may be discarded on
| receipt.
|
| Participants relying on Sender ID experiment DNS records are warned that
| they may lose valid messages in this set of circumstances. 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:
| 2.4. Checking Authorization
|
| [...]
|
| 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.
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.
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.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDmDFCwL7PKlBZWjsRAmDeAJ9ryaqK2qfkGKqEFwOK+CJGHFN3YgCeNSvZ
CyEcZQgfXXaIuotJcimVXr8=
=003e
-----END PGP SIGNATURE-----
-------
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