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

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Dec 2005 23:05:49 +0100

The IESG decided:

> while we have found merit in Julian Mehnle's technical
> concerns, we will not change our decision to publish the
> draft as an Experimental RFC without change to its technical
> content.

> The IESG did consider this conflict in its original
> discussions, and that is one of the reasons why we crafted
> the original IESG note to be included in these documents,
> which highlights that there are concerns about using these
> mechanisms in tandem.

That's beside the point.  Of course "consenting adults" can use
"spf2.0/mfrom,pra", and that's semantically almost the same as
"v=spf1" plus an identical "spf2.0/pra" policy.  There are no
technical issues with using these mechanisms in tandem for all
senders explicitly wishing to participate in both experiments.

The issue are senders _not_ wishing to participate in the later
PRA experiment:  "v=spf1" is semantically almost the same as
"spf2.0/mfrom" _without_ "spf2.0/pra".

That's what the v=spf1 spec. says with its "NOT RECOMMENDED" in
chapter 2.4.  It simply reflects what all v=spf1 specifications
and implementations did since 2003.
  
> It is quite clear that this conflict would not be acceptable
> for a standards track specification. 

It's also unacceptale for a standards organization with a bare
minimum of ethical and engineering principles.

> document the different approaches as they were considered in
> the MARID working group.

The MARID WG came to the conclusion that PRA (spf2.0/pra) is in
fact so different from SPF (v=spf1 or spf2.0/mfrom) that they
should be clearly separated.  That was the last MARID decision
before this WG was dissolved unilaterally by Mr. Hardie.

 [he = Julian]
> he requested that we modify draft-lyon-senderid-core to
> address the conflict.

Yes, backed by the SPF community and more than 200 signatures
<http://old.openspf.org/cgi-bin/openspf_pledge.cgi>.  This does
not include several competent voices who don't like v=spf1, but
still agree that (ab)using v=spf1 for PRA without the explicit
consent of the v=spf1 participants is an ethical and technical
nightmare.

> his proposed modification amounted to a substantive technical
> change.

That's not the case.  His proposal affects _four characters_ in
a chapter about the alleged spf2.0 "backwards" compatibility:

Instead of 'treat v=spf1 like spf2.0/mfrom,pra' this should be
           'treat v=spf1 like spf2.0/mfrom'.

> The IESG did not consider this an appropriate action to take
> in this case.

Well, you are wrong, and everybody can see it.  If one draft
says "SHOULD do x", and another draft says "SHOULD NOT do x",
then something has to give.

> Depending on the content of the record, this may mean that
> Sender-ID heuristics would be applied incorrectly to a
> message.

This does _not_ depend on the content of the v=spf1 record.  It
depends on a PRA being identical to the MAIL FROM.  Which isn't
the case for a significant portion of all mails.

> Participants publishing SPF experiment DNS records should
> consider the advice given in section 3.4 of RFC XXXX
> (draft-lyon-senderid-core) and may wish to publish both
> v=spf1 and v=spf2.0 records to avoid the conflict.

There's no such thing as "v=spf2.0 records".  This "advice" is
completely bogus, there are more than a million v=spf1 records,
and it will take years to migrate this installed base to use
the new SPF RR.  

For this migration period the best they can do is to publish
both SPF and TXT records, "v=spf1" or "spf2.0".  Asking the
participants of the older "experiment" to publish four records
instead of two won't fly, let alone anytime soon.

Besides, since when favours the IESG "opt-out" for experiments
with non-consenting participants ?

> we hope that this augmented IESG note will address his
> concerns.

I seriously doubt it.  Bye, Frank

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Dec 2005 08:49:07 +0200 (EET)

> then something has to give.

There seem to be three options going forward:

  1) make no changes to the spec.   The spec (assumably) documents the
     existing behaviour, even if it is conflicting.

  2) make the spec to disallow that.  The implementations are not
     changed.  The spec no longer documents the existing behaviour, and
     the conflicts continue, but those who implement the spec aren't
     allowed to say it's compliant (but no one is enforcing this in
     any case, so....).

  3) make the spec to disallow that.  Someone convinces the
     implementors to change their running code, and all the code is
     actually changed.

Basically the IESG decided that accurate documentation of the running 
code is more important than documenting something that does not exist, 
and maybe never will exist.

That's certainly an understandable tradeoff to make, and it gets back 
to the more philosophical role of the IETF: should it be OK to 
document even disrupting running code, or should the IETF "just say 
no" (and then we'd likely have no documentation of the running code 
whatsoever).

Note: I have no knowledge whether the implementors would or would not 
be willing to change the code.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 9 Dec 2005 04:36:40 -0800 (PST)

On Fri, 9 Dec 2005, Pekka Savola wrote:

> Basically the IESG decided that accurate documentation of the running code 
> is more important than documenting something that does not exist, and maybe 
> never will exist.

> That's certainly an understandable tradeoff to make, and it gets back to the 
> more philosophical role of the IETF: should it be OK to document even 
> disrupting running code, or should the IETF "just say no" (and then we'd 
> likely have no documentation of the running code whatsoever).

What you're saying has merit but if this were purely documentation of
the running code then document would go as INFORMATIONAL RFC and then
I have to agree that bar low enough and it makes more sense to document
a [bad] system then not document it at all.

However SID drafts are going for EXPERIMENTAL status and are NOT purely
documentation of running code but rather IETF sanctioned internet-wide
experiment with possible intention to move to standard if experiment
is successful. In my view, in this case approving experiment with known
bad behavior or that is non-compliant with existing standards makes more 
harm them good for IETF.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Julian Mehnle <[email-masked]>
Date: Fri, 9 Dec 2005 13:03:36 +0000

> and maybe never will exist.

As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was 
submitted for experimental status, there was no "running code" that 
actually interpreted "v=spf1" as "spf2.0/mfrom,pra".  So what running code 
was being documented when draft-lyon-senderid-core-00 was submitted?

Or does the fact that such running code has been created _since_ the draft 
was submitted justify the treatment of that draft as "documenting running 
code"?  I hope that's not what you mean.

Julian.

References:
 1. http://www.xyzzy.claranet.de/home/test/senderid-appeal.htm

---

From: "Dick St.Peters" <[email-masked]>
Date: Fri, 9 Dec 2005 08:58:24 -0500

Julian Mehnle writes:
> actually interpreted "v=spf1" as "spf2.0/mfrom,pra".

Perhaps you shouldn't have said that.  Sendmail's sid-milter has used
v=spf1 records for PRA checks since its initial release in August
2004.  I don't know the date for draft-lyon-senderid-core-00, but I
believe it was well after August.

--
Dick St.Peters, [email-masked]

---

From: wayne <[email-masked]>
Date: Fri, 09 Dec 2005 07:41:12 -0600

> was being documented when draft-lyon-senderid-core-00 was submitted?

Actually, I think the SenderID implementation from sendmail was
interpreting "v=spf1" records using the PRA, but Julian's point is
largely true: the vast majority of implementations that are abusing
SPF version 1 records were released *SINCE* the first objections to
the senderid drafts were raised.  The number of SenderID
implementations is still small.  While I doubt that all
implementations will be fixed, I think the IETF blessing the conflict
will cause the number of implemenations to grow, rather than shrink.

The IESG's first reaction to learning of the conflict between the use
of SPF version 1 records by SenderID was to direct the RFC editor to
remove the warning placed in the SPF I-D.  The IESG did this *without*
informing either of the draft authors about this technical change.  It
took a fair amount of discussion with the IESG to even allow this
problem to be acknowledged.

Now, obviously the IESG feels that they can freely make technical
changes to drafts without the approval of draft authors.  They also
acknowledge that the abuse of SPF version 1 records by the SenderID
spec causes problems.

So, the question is:  why didn't the IESG just change the SenderID
drafts to something that doesn't conflict?

-wayne

---

From: wayne <[email-masked]>
Date: Fri, 09 Dec 2005 07:45:18 -0600

> bad behavior or that is non-compliant with existing standards makes more 

Indeed, I fail to see the point of running an experiment when it is
known that the algorithm will have to be changed in an incompatible
way before it can advance to the standard track.

Isn't the time to fix the problem now?  Before the experiment is run?

-wayne

---

From: wayne <[email-masked]>
Date: Fri, 09 Dec 2005 09:02:25 -0600

> believe it was well after August.

draft-ietf-marid-protocol-03 was released on Sept 15th 2004, after the
consensus of the working group was that the SPFv1 records should not
be reused for SenderID.  So, yeah, there was a few weeks where the
Sendmail milter was within spec.

-wayne

---

From: Julian Mehnle <[email-masked]>
Date: Fri, 9 Dec 2005 15:22:41 +0000

Dick St.Peters wrote:
> Julian Mehnle writes:
> > As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00
> > was submitted for experimental status, there was no "running code"
> > that actually interpreted "v=spf1" as "spf2.0/mfrom,pra".
>

draft-lyon-senderid-core-00 was submitted in October 2004.  However, I 
again quote from my appeal[1]:

| So when Mark Lentczner changed[2] the version identifier to "spf2.0" in
| draft-ietf-marid-protocol-01 in the aftermath[3,4] of IETF-60, there was
| clearly a consensus to avoid the use of "v=spf1" records for checking of
| PRA or other unexpected identities.

So if in August 2004 the Sendmail people chose to make sid-milter use 
"v=spf1" records, they clearly did it against IETF consensus.  I don't 
think this practice should be sanctioned ex post despite them having 
ignored that consensus.

References:
 1. http://www.xyzzy.claranet.de/home/test/senderid-appeal.htm
 2. http://www.imc.org/ietf-mxcomp/mail-archive/msg03282.html
 3. http://www.imc.org/ietf-mxcomp/mail-archive/msg03164.html
 4. http://www.imc.org/ietf-mxcomp/mail-archive/msg03081.html

---

From: wayne <[email-masked]>
Date: Fri, 09 Dec 2005 09:19:21 -0600

In <[email-masked]> "Dick St.Peters" <[email-masked]> writes:

> [...]

I know you have worked quite a bit on Sendmail Inc.'s sid-milter for
them.  Perhaps you can answer some questions:

The draft-lyon-senderid-core-01 document is fairly long, some 17
pages.  This is the document that references the SPF-classic spec and
modifies the semantics for use by SenderID.  (There are two other
SenderID documents to describe the PRA and the SMTP SUBMITTER
extention.)

Can you list the semantic differences between SPF-classic and SenderID
that need to show up in implementations that support both?

Are they any at all?

If not, why does the senderid-core document need to be 17 pages long?

If there are, how many of them are correctly implemented by Sendmail
Inc's sid-milter?

Do you know if Sendmail Inc. is committed to conforming to the RFCs
and will change if the RFCs change?

-wayne

---

From: "Dick St.Peters" <[email-masked]>
Date: Fri, 9 Dec 2005 12:53:10 -0500

wayne writes:
> them.

No, I have not ... not "for them".

I have developed, on my own and originally for my own use, fixes for
some sid-milter bugs and some extensions.  (One of the extensions is an
option NOT to use v=spf1 for PRA.  I run it with that option on.)

As a member of the sid-milter user community, I wrapped my stuff into
a patch, made it available by ftp, and posted an announcement on the
sid-milter-discuss mailing list.  Much of what I've done will be
incorporated into the next release of sid-milter, hopefully due out
any day now, and I have been in private communication with the
maintainer about that.

However, I do not work for Sendmail Inc. and do not in any way pretend
to represent them or have any relationship with them.  I am just a
highly-experienced programmer who uses sendmail open-source stuff,
tends to meddle with code I use, and tries to give back anything I do
that might be useful to others.

>  Perhaps you can answer some questions:

My responses wont' be very useful.

> that need to show up in implementations that support both?

No, I can't.  I've read parts of the documents but haven't read any in
detail.

> Are they any at all?

Probably.  For one thing, SenderID does not do HELO checks.  As it
happens, I think the notion that only a single SPF record is needed to
specify policy for HELO and MFROM is as silly as the notion that only
one is needed to specify policy for MFROM and PRA.

sid-milter doesn't do HELO checks.  I think it also regards the "h"
macro as deprecated and does not implement it.

> If not, why does the senderid-core document need to be 17 pages long?

I have no idea.

> If there are, how many of them are correctly implemented by Sendmail

I don't know.  sid-milter is a work-in-progress, and the last release
was a bugfix release before the July SenderID drafts came out.

> and will change if the RFCs change?

You'll have to ask them.  However, I suspect it's safe to say that
they will conform to any RFCs that become standards.

That said, I will be interested in seeing how they handle the
"Resent-" header issue.  Currently, it is difficult, if not
impossible, to make sendmail insert such a header when forwarding (as
opposed to re-mailing).

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Dec 2005 18:37:10 +0100

Pekka Savola wrote:
 
> 1) make no changes to the spec.   The spec (assumably)
>    documents the existing behaviour, even if it is
>    conflicting.

SPF (both v=spf1 and spf2.0, there is no "v=pf2.0") allows
to log DNS queries.  That's documented in the v=spf1 draft:
With SPF's "exists:"-mechanism it's possible to log when
somebody tries to evaluate the policy.

Result of this experiment (last state that I've heard of):
Absolutely nobody evaluates "spf2.0/pra".  This "opt-out"
strategy from the PRA-experiment does not work.

Adding an "IESG note" to the v=spf1 spec. how participants
of this "experiment" could "opt-out" from the PRA-experiment
by adding dummy PRA-records, where this in practice doesn't
work, is pointless.

For SPF-"experiment" read about 1.000.000 published policies
with about 10 independent interoperable implementations, and
for PRA-experiment read "nobody really uses or wants PRA".

No joke, I offered a simple PRA-"opt-in" modifier for v=spf1,
and the precise number of interested v=spf1 users was _zero_ :
<http://purl.net/xyzzy/home/test/draft-spf-6-3-options-09.txt>

So in practice nobody wants PRA, and almost nobody bothers to
implement spf2.0/pra, "opt-out" by dummy PRA records is doomed.

But there's still the danger that somebody implements a post-
SMTP PRA-check abusing v=spf1 records.  An ignorant somebody
thinking that a PRA-PASS or a PRA-FAIL indicated by a MUA is
cute even if it's wrong.

At this point he has already violated several SHOULD NOT and
won't care about details like "this PRA-result is a bad PRG".

But unfortunately it will _apparently_ work as expected for
most mails.  Users will believe that a PRA-FAIL is spam, and
a PRA-PASS is no phish.   Getting it wrong in those cases
where the PRA is not the same as the Return-Path.

> the IESG decided that accurate documentation of the running
> code is more important than documenting something that does
> not exist, and maybe never will exist.

If there is running spf2.0/pra code it apparently fails to
honour the dummy "opt-out" records.  And there's of course no
chance to add those dummy spf2.0 records to about 1.000.000
published v=spf1 policies in this decade:

SPF (both v=spf1 and spf2.0) is designed that you can forget
a published policy as soon as it's correct, and as long as
you don't change your (sending) mail setup.  

Publishers of v=spf1 policies in 2004/05 have no reason to
find an obscure "IESG note" asking them to "opt out" from the
unrelated PRA-experiment of 2005/06.

Maybe it won't work even if they'd find and try it, see above.

                         Bye, Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 9 Dec 2005 10:18:54 -0800 (PST)

> they will conform to any RFCs that become standards.

SPF & SID document if they become RFCs will not be "standard" - just
documented IETF "experiment".

But as you say Sendmail tries to be compliant with any RFC that is an
email standard and this is a problem if they want to implement SID.

> impossible, to make sendmail insert such a header when forwarding (as

One thing the IESG note [due to my appeal] forgot to mention is that
its impossible for implementation to both be compliant with standards
and be doing SID checking (because interpretation of Resent- header
fields in automatic manner is already violation of a standard). The same 
applies to adding Resent- header fields as per SID - if system is doing 
it, this is violation of standards, if it is not doing it, it can not 
claim to be compliant with SID.

So the conflict remains unresolved and it is not just that SID systems 
will have problems with other systems that are complying with standards 
(that is certainly true and would lead to unpredictable results as per
IESG note) but that using SID itself already implies that implementor 
would be violating the standard - I still don't understand how IETF/IESG 
can support publication of such a document for anything but the
INFORMATIONAL use.

The correct thing to do to avoid the conflict (and still use similar
algorithm) is to choose new header field name and register it with IANA.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: wayne <[email-masked]>
Date: Fri, 09 Dec 2005 13:04:00 -0600

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

> Absolutely nobody evaluates "spf2.0/pra".

fyi;

There have been a couple of people who have run stats on the usage of
spf2.0/pra vs SPF.  It *is* being used, but no where near as much as
SPF.

-wayne

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Dec 2005 14:24:20 -0500

>>>>> "wayne" == wayne  <[email-masked]> writes:

    wayne> Isn't the time to fix the problem now?  Before the
    wayne> experiment is run?

Can you convince the sender ID authors to do so and to change their
implementations?

I don't think the IETF or IESG could accomplish that.  If you can then
I agree we will have a better Internet.

---

From: wayne <[email-masked]>
Date: Fri, 09 Dec 2005 12:59:54 -0600

> No, I have not ... not "for them".

Indeed, I should have said "for it", and I apologize.

I'm going to keep my reply to the IETF list terse and reply more fully
on the SPF list.  I think quite a bit of this is off-topic here.

> No, I can't.  I've read parts of the documents but haven't read any in

These were somewhat of trick questions.  I *have* read the SenderID
drafts, and made a long list of comments, sent to both the authors and
the IESG.  (This was during the IESG evaluation period.)

There is a fairly long list of different semantics between an v=spf1
record evaluated under the SPF spec, and under the SenderID
spec, *even* when doing the "mfrom" evaluation.  For those that don't
know, the SenderID spec has two different identities that the records
can be evaluated under: the "mfrom" and the "pra".  The "mfrom" is
supposed to be compatible with SPF, the "pra" is new.

For example, the SenderID I-D talks about DNS zone cuts and such,
which were in earlier drafts of the SPF spec, but were removed from
the final draft because not enough people implemented them.  

So, when the SenderID spec says to evaluate "v=spf1" records as if
they were "spf2.0/mfrom,pra", even the evaluation of the "mfrom" part
is not wholely compatible.

Many, but not all, of these semantic differences are minor.  It
really is not clear at all what exactly these differences are, why
they exist, and what the ramifications are.

-wayne

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 9 Dec 2005 11:39:23 -0800 (PST)

> I agree we will have a better Internet.

You might not be able to accomplish that, but you need not support its
publication as RFC either. Tell them clearly that if they want their
docs published as RFC, the experiment needs to be defined so that it
does not cause interoperability problems with other experiments and
does not violate existing standards.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Dec 2005 21:07:56 +0100

wayne wrote:

> For example, the SenderID I-D talks about DNS zone cuts and
> such, which were in earlier drafts of the SPF spec, but were
> removed from the final draft

Their May 2005 draft still references your December 2004 state:

| If the PRA version of the test is being performed and no
| records remain, the requirement in [SPF] to find the Zone Cut
| and repeat the above steps is OPTIONAL.

That has to be removed.  You sent this to the authors and the
IESG, and they all ignored it ?

> even the evaluation of the "mfrom" part is not wholely
> compatible.

In practice nobody implements spf2.0/mfrom, so this is only a
theoretical incompatibility, and removing the quoted paragraph
could fix it.

> Many, but not all, of these semantic differences are minor.

Dick's idea "let's ignore %{h}" is certainly interesting. ;-)
IIRC that was a MARID concept, the first thing you put back
into spf-classic to reflect SPF's status-quo-antea.  How is
postmaster@%{h} supposed to work without %{h} ?

AFAIK spf2.0/mfrom (and even spf2.0/pra) inherit %{h} from
v=spf1.  Otherwise a wannabe-spf2.0 implementation is broken.

> It really is not clear at all what exactly these differences
< are, why they exist, and what the ramifications are.

For the positional modifiers in spf2.0 I could sing it, but in
practice it's of course irrelevant:  So far there is not one
implemented new modifier, let alone any positional modifier.

That's the complete list of semantic differences I'm aware of.

                            Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Dec 2005 21:44:19 +0100

wayne wrote:

> There have been a couple of people who have run stats on the
< usage of spf2.0/pra vs SPF.  It *is* being used, but no where
> near as much as SPF.

I was referring to your article in spf-discuss some months ago,
where you found that a dummy spf2.0/pra "opt out" is apparently
not evaluated by Hotmail.  Did this change ?  Here's a link to
your 2005-07-24 article:

<http://article.gmane.org/gmane.mail.spam.spf.discuss/18037>

                          Bye, Frank