In <1118709257(_dot_)26495(_dot_)86(_dot_)camel(_at_)thunk> Bill Sommerfeld
<sommerfeld(_at_)sun(_dot_)com> writes:
While I have not been following this issue particularly closely, this
appears to be a case where two experiments are using the same codepoint
to enode data with (allegedly) different meaning.
Indeed this is the case. Originally, most of these records were
published under the draft-mengwong-spf-* SPF specifications. During
the MARID WG lifetime, there was an attempt to merger the SPF and
CallerID proposals, with the reuse of the SPF records. However, as
time went by, it became increasingly clear that there were cases where
such reuse would cause problems and at IETF-60, it was ruled that the
MARID protocol needed to use a different version number. When the
MARID WG was closed, authors were asked to submit their drafts as
individual submissions. At this point, the I-Ds were changed to again
reuse the SPFv1 records.
Two examples of where these two experiments will give different
results are documented in the spf-classic I-D in section 2.4. See:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#anchor6
(note: this same I-D is available from the IETF website, but not in
HTML form so I can't give an link to the correct section.)
In partciular, mailing lists are known to give different results:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#mailing-lists
Also, one of the open issues with SPF is the ability to deal with
forwarded email. One of the most promising solutions to this problem
will break if the MARID proposal is used. See section 9.3.1.2:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#forwarding
Far more cases have been documented on both the MARID list and on the
spf-discuss list. I'm sorry I don't immediately have the references.
-wayne
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf