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

On Fri, 26 Aug 2005, John Glube wrote:

> |The only relevant boundary is between what the sender
> |controls and what they do not. All that any sender,
> |forwarder or any other mail injector can ever be expected
> |to do is to define the boundaries of the systems they
> |control.
> |
> |Once that boundary is defined the definition is fair game
> |for any party to use to interpret it to meet their
> |operational needs.
>
> I have a real problem with this last position.
>
> The underlying thrust behind sender authentication is to
> establish a framework for use by certification and
> reputation services, both external and internal to
> facilitate the delivery of ham, while rejecting spam. [1]

|With such a statement you're making an assumption that the
|technology (i.e. SPF and SID) is only good for sender
|authentication and anti-spam.

With respect, this does not correctly state what I mean, which
is partially my fault as I should have written:

|The underlying benefit of e-mail authentication for senders
|interested in e-mail delivery is to establish a framework that
|supports certification and reputation services, both external
|and internal to facilitate the delivery of ham, while rejecting
|spam [1]

I fully understand that the design objective of SPF (Mail
From authentication) is to help thwart domain spoofing and
that of Sender ID (PRA authentication) is to help prevent
domain phishing. 

My point is that saying to commercial entities involved in
the sending of solicited bulk e-mail, transactional and
relationship e-mail that receivers can use their sender
policy records for what ever purpose they want,
irrespective of the stipulated protocols is not acceptable.


As to the rest of the discussion, it seems SPF folks
supporting the appeal are not interested in pushing back on
Microsoft as it relates to the IPR and License, but simply
want to fully sever the relationship between spfv1 and
spf2.0.

In that case, I presume the SPF Community has no problem
with these potential developments:

* The IESG, based on the Chair's recommendation, deciding
to revoke publication of the SPF Classic and Sender ID
drafts as Experimental RFC's.

* The IESG asking Messrs Lentczner, Wong, Katz and Lyon to
produce a set of drafts for spf2.0 as experimental RFCs
based on the work done during MARID, with Messrs Lentczner
and Wong doing the work on spf2.0, mfrom and Katz and Lyon
doing the work on spf2.0, pra.

* The IESG asking Messrs Schlitt and Wong to resubmit the
spf-classic draft as an individual submission outside of
MARID for consideration as an informational RFC.

* Hotmail/MSN and various vendors of filtering software
that presently use spfv1 records telling senders they need
to publish spf2.0 records.

* Hotmail/MSN dropping all public support for spfv1,
including amending its web sites and wizard accordingly.

* SpamAssassin, to remain competitive, announcing its
support for spf2.0, mfrom in the next version of its
product.

* AOL, having been spurned by the SPF Community, deciding
to join Hotmail/MSN and support the full transition to
spf2.0.

Will these developments happen? I don't know. But,
hopefully folks have gone into this with their eyes wide
open. Given the reaction of some to the initial comments
posted by members of the IESG, I fear this is not the case.

As such, there is every possibility that those supporting
"technical purity" within the SPF Community are in for a
rude awakening, with the end result being further Internet
balkanization.

John Glube