ietf-mxcomp
[Top] [All Lists]

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

2005-08-25 13:27:38

On Aug 25, 2005, at 11:26 AM, Ned Freed wrote:


A mail-sending domain indicates that it is participating by publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment.  This renders any
claimed results of either experiment suspect.


RIght again.

In any case, I support this appeal to the extent that I believe the conflicts need to be resolved prior to publication. I take no position on the means
by which the conflict is resolved as long as a resolution is reached.


As with any conflict, there are two parties involved. In this case, the SPF group has essentially ignored potential conflicts by neglecting to include support for a subsequent version of the DNS record. This newer record explicitly expresses the intended scope. At the MAAWG meeting in Dusseldorf, Julian suggested SPF developers would only consider use of the newer DNS record version provided Sender-ID abdicated use of the initial version of the record. Sender- ID supports both versions. An appeal was made for the SPF group to consider supporting the newer version of the record as a solution for avoiding this conflict. This suggested use of the record is part of interim advice on the MAAWG website. It would appear this appeal reflects a decisions to remain intransigent.

http://www.maawg.org/about/whitepapers/spf_sendID/

A condition that Sender-ID abdicate the use of the scope-less version of the record is puzzling, as once the newer record is also adopted by SPF, the claimed conflict is resolved. Meng Wong, an author of both drafts, explained the conflict in his white paper by indicating the SPF draft was for historical purposes and suggested Sender-ID embraced both semantics. Sender-ID's use of the initial version of the DNS record will create problems should the publisher of the record intend the semantics to exclude Sender-ID. The methods suggested by the Sender-ID draft to circumvent their semantics could negatively impact the publisher.

This conflict is not accidental or without a simple solution, but rather based upon a desire to withdraw Sender-ID semantics in a manor that negatively impacts the Sender-ID effort. I am _not_ a proponent of Sender-ID. While the merging of semantics was initially considered acceptable by the MARID WG, the desire to now exclude the Sender-ID semantics is primarily due to subsequent licensing notifications. At that time so long ago, the technical solution to allow the record publisher to formally indicate their desired semantics was to change the version of the record that provided the requisite scoping parameters.

Rather than adopting this solution, the SPF group insists anyone that published the initial version of this record only intended to support SPF and not Sender-ID. This would be a difficult conclusion following any number of gatherings where email administrators have subsequently and repeatedly been provided information that indicated this initial record version supports both, and that the subsequent record versions can be used to isolate the scope of the record.

While this conflict should be resolved, without evidence that Sender- ID has fallen out of favor, which the stance by the SPF group prohibits, the obvious solution would likely be for the SPF group to finally adopt the newer record version.


-Doug

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

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