Subject: IESG intends to publish conflicting RfCs causing loss of legit e-mails

From: Frank Ellermann <[email-masked]>
Date: Tue, 14 Jun 2005 01:18:09 +0200

Hi, found in

<http://mid.gmane.org/p0621020bbed3921e8366@%5B129.46.227.161%5D>

The IESG intends to forward the SPF draft, along with the
Sender-ID drafts to the RFC Editor as Experimental RFCs.

The SPF draft says:

| Without explicit approval of the domain owner, checking other
| identities against SPF version 1 records is NOT RECOMMENDED
| because there are cases that are known to give incorrect
| results.

In other words this doesn't work without explicit consent.  The
outcome in one application (known a post-SMTP check, again NOT
RECOMMENDED) will be bogus FAIL or PASS results, leading either
to the deletion of legit mail, or to unwarranted trusted in
phishing attempts.  One of the "Sender-ID experiments" states:

| Sender ID implementations SHOULD interpret the version prefix "v=spf1"
| as equivalent to "spf2.0/mfrom,pra", provided no record starting with
| "spf2.0" exists.

This is known to cause havoc.  There are literally hundreds of
articles pointing this out again and again since 2005-08.  The
activities of Mr. Hardie in this case should be scrutinized by
an indepedent body,
                         Regards, F.Ellermann

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Jun 2005 17:08:27 -0700

Hi Frank,
	This is one of the issues that the IESG believes is at
the heart of concerns about using them in tandem.  Your message
highlights, though, that one of the statements in the IESG note
got dropped accidentally.  The original said: "the IESG
believes that documenting the different approaches does less harm
than not documenting them."   I'll send an updated message to
Wayne including the text.
	The IESG believes that SPF and Sender-ID
are both going forward in the market place, and that having open
specifications of them is of benefit to the community.  As the
IESG note states, we believe there are serious open issues.  We
are not recommending publication in order to recommend them,
but for the information of the community and with the hope that
those specifications in hand will enable a clearer analysis of the
behavior.
			regards,
				Ted Hardie

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 13 Jun 2005 20:34:18 -0400

Ted,

While I have not been following this issue particularly closely, this
appears to be a case where two experiments are using the same codepoint
to enode data with (allegedly) different meaning.

Specifically (quoting from Frank's message):

>articles pointing this out again and again since 2005-08.

I have not been able to find a concise description of exactly what havoc
will ensue, but if we take them on their word it seems inappropriate to
conduct an experiment where the same codepoint published in the DNS will
be interpreted differently by the competing experiments. 

It seems far more appropriate to amend the Sender ID spec to say that
implementations of Sender ID SHOULD NOT interpret v=spf1 lines so that
both experiments can run in parallel without interference.

						- Bill

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 13 Jun 2005 17:52:21 -0700 (PDT)

On Mon, 13 Jun 2005, Ted Hardie wrote:

> than not documenting them."

Can I ask you then to comment in light of the following paragraph from RFC2026:

|  (d)  Limited Use:  The TS is considered to be appropriate for use
|      only in limited or unique circumstances.  For example, the usage
|      of a protocol with the "Experimental" designation should generally
|      be limited to those actively involved with the experiment

on what form is taken to limit those involved to only those who have 
agreed to participate in SID experiment and similarly on how is that
done for SPF experiment?

Also can I ask IESG to resolve my misunderstanding on if it is considered
ok for EXPERIMENTAL RFC to be incompatible with existing standard-track 
RFCs for any internet-wide experiment?

Lastly, I would like a clarification on if you expect any of these 
experimental proposals to go forward in the future for standard track 
publication based on result of the experiment?

Looking forward to your answers,

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: wayne <[email-masked]>
Date: Mon, 13 Jun 2005 20:48:33 -0500

> to enode data with (allegedly) different meaning.

Indeed this is the case.  Originally, most of these records were
published under the draft-mengwong-spf-* SPF specifications.  During
the MARID WG lifetime, there was an attempt to merger the SPF and
CallerID proposals, with the reuse of the SPF records.  However, as
time went by, it became increasingly clear that there were cases where
such reuse would cause problems and at IETF-60, it was ruled that the
MARID protocol needed to use a different version number.  When the
MARID WG was closed, authors were asked to submit their drafts as
individual submissions.  At this point, the I-Ds were changed to again
reuse the SPFv1 records.

Two examples of where these two experiments will give different
results are documented in the spf-classic I-D in section 2.4.  See:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#anchor6
(note:  this same I-D is available from the IETF website, but not in
HTML form so I can't give an link to the correct section.)

In partciular, mailing lists are known to give different results:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#mailing-lists

Also, one of the open issues with SPF is the ability to deal with
forwarded email.  One of the most promising solutions to this problem
will break if the MARID proposal is used.  See section 9.3.1.2:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html#forwarding

Far more cases have been documented on both the MARID list and on the
spf-discuss list.  I'm sorry I don't immediately have the references.

-wayne