Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



In <198A730C2044DE4A96749D13E167AD375A2ABD at MOU1WNEXMB04.vcorp.ad.vrsn.com> "Hallam-Baker, Phillip" <pbaker at verisign.com> writes:

>> > 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.
>> 
>> You have long advocated this position, but unfortunately the 
>> definition of "outgoing edge mail servers" is not a nice, 
>> clean, crisp concept.  It sounds good, but unfortunately, it 
>> doesn't work.
>
> OK, "All SPF does is ATTEMPT TO provide a mechanism whereby "
>
> Happy now?

Sorry, but no..

> At some point there is a boundary between infrastructure the sender has
> control of and where he does not. That boundary is very clearly defined
> in my universe but even if it was ambiguous it would still exist.

The problem is that for different identities, this "boundary" is
different.  In particular, the boundaries between the SPF identities
(2821.MAILFROM and 2821.HELO) are different than SenderID (PRA).


-wayne


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.