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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 26 Aug 2005 12:14:58 -0700

> > 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?

It does not matter which way you try to slice it, the sender of the
message has no connection to any of the forwarder mechanisms or any
other part of the email infrastructure.

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.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: wayne <[email-masked]>
Date: Fri, 26 Aug 2005 14:24:46 -0500

> OK, "All SPF does is ATTEMPT TO provide a mechanism whereby "

Sorry, but no..

> 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

---

From: "Nicholas Staff" <[email-masked]>
Date: Sat, 27 Aug 2005 15:24:12 -0700

"Two will leave but only one shall return"...I'm by no means suggesting
that's a desirable approach to decision making but we've managed to get
ourselves into a place where I think it's now the best way out.  Fortunately
since this incompatibility will result in email that should have been
received not being received I can't imagine the fight lasting very long
(when the president of one company can't send an email and the president of
another company can't receive that email, one of those companies will be
making changes to their messaging infrastructure).  The alternative, having
the IETF Chair or IESG make the decision, would in my opinion generate so
much bad blood for such a long time that it would be detrimental to most
everything else the IETF is involved in.

Ultimately the technology that breaks email less will win regardless of
which one has more benefits or which one offers better protection for this
or that.  Form follows function.

Thanks,
Nick