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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Let me phrase it this way: the IESG should not sanction conflicting 
> experiments by publishing conflicting specifications, 

I agree.

But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this was accepted by the WG right up to the point where
people started to complain about IPR licenses.

I do not think that the IESG should block a proposal citing a conflict
when the real animus here is entirely due to the IPR issue.

All SPF does is provide a mechanism whereby sending parties can describe
their outgoing edge mail servers. The recipient has the absolute right
to interpret that data in any way they see fit. That is the entire point
of a spam filtering scheme.

Nobody has ever demonstrated a conflict as far as I am concerned, all
attempts to allege a conflict begin, "the sender intends" which is
utterly irrelevant. The sender does not have the right to decide what
email client I use, they do not have the right to determine what spam
filter I use either. 

Sender-ID simply describes one means of interpreting an SPF record. It
may or may not work, it may or may not be optimal, that is why it is an
experiment.

An SPF record may be constructed in such a fashion that Sender-ID
verification is not possible. That is not a conflict, it is simply an
artifact that results from the baroque nature of the SPF spec.

I do not believe that one group should be able to block a proposal they
do not like by alleging a non-existent conflict.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]