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

[Julian Mehnle]

[Harald Tveit Alvestrand]

Julian,

not speaking for anyone but myself.....

one matter of principle:

are you of the opinion that the IESG should try to police which experiments
get run on the Internet by refusing to publish RFCs documenting
possibly-conflicting experments?

Both of these documents were published at the request of their authors. I
know that ways in which they could cause conflict were pointed out to the
authors, and that both authors upheld their requests to publish.

If you ask the IESG to assert the power to police this kind of experiment,
please make sure you will be happy with the result if they agree with
you.....

Harald

I believe that draft-lyon-senderid-core-01 conflicts in a significant
aspect with draft-schlitt-spf-classic-02, on which the former depends, and
which has also been approved by the IESG to be published as an
Experimental RFC.[2] The conflicting part of the Sender-ID specification
disrespects the substantial history the SPF specification has outside the
IETF. Through its decision, the IESG also ignores SPF's deployed base.[3]
And even if the IESG intends to run both of the specifications as an
experiment before deciding any further on how to proceed with them, the
publication of conflicting specifications is bound to disrupt these
experiments.

[Bill Sommerfeld]

Post by Harald Tveit Alvestrand
are you of the opinion that the IESG should try to police which experiments
get run on the Internet by refusing to publish RFCs documenting
possibly-conflicting experments?

It depends on the form of the conflict.

I believe that the IESG has the duty to ensure that concurrent
experiments either use experimental codepoints in non-conflicting ways,
or else require them to use distinct codepoints; to fail to do this
creates the risk that any experimental results will be
muddled/contaminated.

In this case, the two experiments interpret the same codepoints in the
DNS in subtly different ways.

A mail-sending domain indicates that it is participating by publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment. This renders any
claimed results of either experiment suspect.

- Bill

[Ned Freed]

Post by Bill Sommerfeld

Post by Harald Tveit Alvestrand
are you of the opinion that the IESG should try to police which experiments
get run on the Internet by refusing to publish RFCs documenting
possibly-conflicting experments?

It depends on the form of the conflict.
I believe that the IESG has the duty to ensure that concurrent
experiments either use experimental codepoints in non-conflicting ways,
or else require them to use distinct codepoints; to fail to do this
creates the risk that any experimental results will be
muddled/contaminated.

Bingo. There is, after all, an "experiment" in "experimental". A conflict that
stands a good chance of making it imposisble to get useful results from the
experiment is something that clearly needs to be resolved prior to publication.

There's even some support for this in RFC 2026. Section 4.2.1 talks about
experimental publication being subject to "verification that there has been
adequate coordination with the standards process".

Now, this is phrased in terms of conflicts with standards, not conflicts
between experiments, likely because the case of conflicting experiments
was never envisioned.

Post by Bill Sommerfeld
In this case, the two experiments interpret the same codepoints in the
DNS in subtly different ways.
A mail-sending domain indicates that it is participating by publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment. This renders any
claimed results of either experiment suspect.

RIght again.

In any case, I support this appeal to the extent that I believe the conflicts
need to be resolved prior to publication. I take no position on the means
by which the conflict is resolved as long as a resolution is reached.

Ned

[Bill Sommerfeld]

Post by Ned Freed
In any case, I support this appeal to the extent that I believe the conflicts
need to be resolved prior to publication. I take no position on the means
by which the conflict is resolved as long as a resolution is reached.

And I wholeheartedly agree with this.

[Dave Crocker]

Post by Ned Freed
In any case, I support this appeal to the extent that I believe the conflicts
need to be resolved prior to publication. I take no position on the means
by which the conflict is resolved as long as a resolution is reached.

All of this raises the obvious question of the purpose in having the IESG
"approve" Experimental status. If the approval does not pertain to basic
technical issues, such as known conflicts with other specifications, it is
difficult to imagine any benefit in the approval process.

On the other hand, the fact of IESG "approval" for these two specifications has
been richly touted as progress on the standards track. Given how sensitive the
IETF community is about misrepresentation of its actions and labels, we should
make sure that the value-add of those actions is clear and real.

[Douglas Otis]

Post by Ned Freed

Post by Bill Sommerfeld
A mail-sending domain indicates that it is participating by
publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment. This renders any
claimed results of either experiment suspect.

RIght again.
In any case, I support this appeal to the extent that I believe the conflicts
need to be resolved prior to publication. I take no position on the means
by which the conflict is resolved as long as a resolution is reached.

As with any conflict, there are two parties involved. In this case,
the SPF group has essentially ignored potential conflicts by
neglecting to include support for a subsequent version of the DNS
record. This newer record explicitly expresses the intended scope.
At the MAAWG meeting in Dusseldorf, Julian suggested SPF developers
would only consider use of the newer DNS record version provided
Sender-ID abdicated use of the initial version of the record. Sender-
ID supports both versions. An appeal was made for the SPF group to
consider supporting the newer version of the record as a solution for
avoiding this conflict. This suggested use of the record is part of
interim advice on the MAAWG website. It would appear this appeal
reflects a decisions to remain intransigent.

http://www.maawg.org/about/whitepapers/spf_sendID/

A condition that Sender-ID abdicate the use of the scope-less version
of the record is puzzling, as once the newer record is also adopted
by SPF, the claimed conflict is resolved. Meng Wong, an author of
both drafts, explained the conflict in his white paper by indicating
the SPF draft was for historical purposes and suggested Sender-ID
embraced both semantics. Sender-ID's use of the initial version of
the DNS record will create problems should the publisher of the
record intend the semantics to exclude Sender-ID. The methods
suggested by the Sender-ID draft to circumvent their semantics could
negatively impact the publisher.

This conflict is not accidental or without a simple solution, but
rather based upon a desire to withdraw Sender-ID semantics in a manor
that negatively impacts the Sender-ID effort. I am _not_ a proponent
of Sender-ID. While the merging of semantics was initially
considered acceptable by the MARID WG, the desire to now exclude the
Sender-ID semantics is primarily due to subsequent licensing
notifications. At that time so long ago, the technical solution to
allow the record publisher to formally indicate their desired
semantics was to change the version of the record that provided the
requisite scoping parameters.

Rather than adopting this solution, the SPF group insists anyone that
published the initial version of this record only intended to support
SPF and not Sender-ID. This would be a difficult conclusion
following any number of gatherings where email administrators have
subsequently and repeatedly been provided information that indicated
this initial record version supports both, and that the subsequent
record versions can be used to isolate the scope of the record.

While this conflict should be resolved, without evidence that Sender-
ID has fallen out of favor, which the stance by the SPF group
prohibits, the obvious solution would likely be for the SPF group to
finally adopt the newer record version.


-Doug

[Andrew Newton]

Post by Bill Sommerfeld
In this case, the two experiments interpret the same codepoints in the
DNS in subtly different ways.
A mail-sending domain indicates that it is participating by publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment. This renders any
claimed results of either experiment suspect.

If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.

-andy

[Stephane Bortzmeyer]

On Fri, Aug 26, 2005 at 08:47:17AM -0400,

Post by Andrew Newton
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.

It is an absolutely incredible request since SPF uses these records
since its beginning (a long time before Sender-ID existed) and since
there is (unlike SenderID) actual deployment, which can not be called
back.

[Andrew Newton]

Post by Stephane Bortzmeyer
On Fri, Aug 26, 2005 at 08:47:17AM -0400,

Post by Andrew Newton
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.

It is an absolutely incredible request since SPF uses these records
since its beginning (a long time before Sender-ID existed) and since
there is (unlike SenderID) actual deployment, which can not be called
back.

Is this appeal about avoiding further conflict or is it about
challenging past differences?

-andy

[Frank Ellermann]

Post by Stephane Bortzmeyer
It is an absolutely incredible request since SPF uses these
records since its beginning (a long time before Sender-ID
existed) and since there is (unlike SenderID) actual
deployment, which can not be called back.

SPF is also older than Caller-ID, a patented XML-over-DNS idea.

JFTR, Frank

[Thomas Gal]

Well clearly IANA won't accept 2 differing registrations that
overlap on this matter. Certainly it is the IETF/IESG/IAB's job to rectify
that incongruity? If the two proposals cannot come to a resolution regarding
the differing interpretations of the DNS records then clearly they must be
required to use different/non-overlapping syntax. For the IESG to say
"Change your records to v=senderid or something that doesn't conflict with
this other previously printed document and large number of installations or
we can't really distribute this document" makes perfect sense. Certainly,
though everyone may not agree on the solution, we agrees that publishing
both unchanged seems silly(using common sense not procedure for a moment)?
Certainly not publishing either seems to make more sense than publishing
both. If these documents are distributed elsewhere and conflicting that's
one thing (beccause they'll be read no matter which forum they are
distributed through), but if we distribute them without anything close to
rough consensus on the acceptability of this conflict between documents
(which I don't think we have) then what has anyone accomplished? Have we
followed the spirit of our rules (rough consensus and working code) if it's
clear that it's NOT POSSIBLE to have working code because the proposals are
mutually exclusive?
I'm not going to try to harp on IPR, or the end of the IETF, or
industry blah blah regarding this decision, but this decision seems
important, so iresspective of all the other things involved, I think it's
important that a good decision is made on this matter. No consensus and non
possiblity for working code.
I would be interested in polling to know how people feel on these 2
matters:

(1) This draft should not be published by the IETF due, at LEAST due to the
fundamental conflict with SPF, which makes running code impossible. Even a
split on this issue will indicate lack of consensus for publishing this
document.

(2) The document should either:
a. be published elsewhere if consistency (i.e. no changes) is
paramount
b. the conflict should be resolved (most useful, least likely based
on history)
c. the syntax should be changed by the RFC editor (or author) which
will essentially also resolve the conflict, make the documents consistent,
and not sacrafice IETF principles.

-Tom



-----Original Message-----
From: ietf-***@ietf.org [mailto:ietf-***@ietf.org] On Behalf Of
Frank Ellermann
Sent: Friday, August 26, 2005 9:10 PM
To: ***@ietf.org
Cc: ietf-***@imc.org
Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in
conflictwith referenced draft-schlitt-spf-classic-02

Post by Stephane Bortzmeyer
It is an absolutely incredible request since SPF uses these records
since its beginning (a long time before Sender-ID
existed) and since there is (unlike SenderID) actual deployment, which
can not be called back.

SPF is also older than Caller-ID, a patented XML-over-DNS idea.

JFTR, Frank

[Frank Ellermann]

Post by Thomas Gal
Well clearly IANA won't accept 2 differing registrations that
overlap on this matter. Certainly it is the IETF/IESG/IAB's
job to rectify that incongruity?

There's IMHO no IANA problem, using the same DNS RR type 99 is
possible / desirable.

Post by Thomas Gal
For the IESG to say "Change your records to v=senderid or
something that doesn't conflict with this other previously
printed document and large number of installations or we
can't really distribute this document" makes perfect sense.

Yes, that's in fact all that has to be done, and what the
appeal proposes, spf2.0 may interpret v=spf1 as spf2.0/mfrom,
but not as spf2.0/mfrom,pra The proposed remedy is "KISS".

Post by Thomas Gal
I'm not going to try to harp on IPR, or the end of the IETF,

IANAL and not very much interested in the former - excl. the
day when I tried to read and understand the IPR boilerplate
in the first CID draft, because it was obvious right from the
day when CID was published that something very odd happens.

IIRC the plan for MARID was to use several ASRG LMAP proposals
as input (SPF, CSV, MTAMARK among others). After CID was added
and the ASRG cochair resigned (ASRG almost dead since this day)
the situation deteriorated.

So back to your statement above: The senderid-appeal is the
continuation of the "shuffle those deck chairs" thread here.

Bye, Frank

[wayne]

Post by Andrew Newton

Post by Bill Sommerfeld
In this case, the two experiments interpret the same codepoints in the
DNS in subtly different ways.
A mail-sending domain indicates that it is participating by publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment. This renders any
claimed results of either experiment suspect.

If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
-andy

The stated goal of draft-schlitt-spf-classic is to document SPF,
basically as it was before the IETF got involved. Yes, the IETF is
calling it an experiment, which I don't agree with. It is documenting
an existing, well established, protocol.


Are you saying that the IETF shouldn't publish an RFC that documents
SPF?

Yes, the IETF, via that MARID WG, tried to create a new protocol
called SenderID that was based on both SPF and CallerID. I can see
that newly created protocol being called an experiement, but I don't
see why the IETF should go out of its way to bless a new protocol that
is incompatible with an existing one.

Is this the normal process of the IETF to create conflicting
standards, just because one standard was developed outside the IETF?


-wayne

[Andrew Newton]

Post by wayne

Post by Andrew Newton

Post by Bill Sommerfeld
In this case, the two experiments interpret the same codepoints in the
DNS in subtly different ways.
A mail-sending domain indicates that it is participating by
publishing
certain DNS RR's.
Crucially, a mail-sending domain cannot opt in to the SPF experiment
without also opting in to the senderid experiment. This renders any
claimed results of either experiment suspect.

If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.
-andy

The stated goal of draft-schlitt-spf-classic is to document SPF,
basically as it was before the IETF got involved. Yes, the IETF is
calling it an experiment, which I don't agree with. It is documenting
an existing, well established, protocol.
Are you saying that the IETF shouldn't publish an RFC that documents
SPF?

I stated that the SPF and Sender ID experiments should not use the
v=spf1 records to avoid conflict. I did not state that the IETF
should not publish an Experimental RFC about SPF.

But since you brought this up: if you (the author of the document) do
not consider this to be an experiment, then perhaps the IETF should
not publish SPF as an Experimental RFC.

-andy

[wayne]

Post by Andrew Newton
But since you brought this up: if you (the author of the document) do
not consider this to be an experiment, then perhaps the IETF should
not publish SPF as an Experimental RFC.

I asked for the IESG to not consider the SPF I-D to be experiemental.
It was turned down. According to Ted, *none* of the IESG members
expressed interest in changing the status from Experiemental.

So far, no one has appealed that decision, and there are only a few
days left to do so. Like the appeal on the re-use of SPFv1 records, I
don't think it would be a productive use of my time to write an appeal
on the experimental status, and thus I won't do it.


-wayne

[Douglas Otis]

Post by wayne

Post by Andrew Newton
But since you brought this up: if you (the author of the document) do
not consider this to be an experiment, then perhaps the IETF should
not publish SPF as an Experimental RFC.

I asked for the IESG to not consider the SPF I-D to be experiemental.
It was turned down. According to Ted, *none* of the IESG members
expressed interest in changing the status from Experiemental.
So far, no one has appealed that decision, and there are only a few
days left to do so. Like the appeal on the re-use of SPFv1 records, I
don't think it would be a productive use of my time to write an appeal
on the experimental status, and thus I won't do it.

If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should be on an historic track. ; )

SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, these potential semantic conflicts, as well
as those introduced by Sender-ID, have not been addressed. Prudent
accommodations were made within the Sender-ID draft however. The SPF
Classic draft has not found higher ground in this regard. Expecting
any standards group to retroactively arbitrate semantics restrictions
for a previously enigmatic DNS record would be disruptive. An
unfrozen SPF Classic draft adding provisions for a scoped version of
the DNS record would allow some percentage of publishers the means to
indicate their intended semantics when so needed. The conflict issue
being described seems specifically based upon a design flaw within
SPF Classic.

-Doug

[wayne]

Post by Douglas Otis
If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should be on an historic track. ; )

RFC2026 says:


4.2.4 Historic

A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the "Historic" level. [...]

This wouldn't apply because there are no newer specifications for SPF,
nor is it obsolete.

Post by Douglas Otis
SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, [...]

There isn't a "pristine" version of SPF, there are several different
draft specifications and a whole bunch of implementation. There are,
unfortunately, conflicts between these. The SPF-classic I-D attempts
to document the most coherent intersection of these.

There have been *very* few semantic changes that were introduced in
the current spf-classic I-D. Almost everything was either part of one
of the earlier, pre-MARID specs, or part of one of the earlier,
pre-MARID implementations.

Of hand, I can think of only the following three "new" items in the
spf-classic I-D:

1) The introduction of a new DNS RR type. Personally, I would be
happy to get rid of this, but there are a lot of folks, especially
in the IETF who think this is very important.

2) The SPF result code "unknown" was renamed "PermError" and the
result code "Error" was renamed "TempError". This is truely a
holdover from MARID. I think the names are much better, but yeah,
it is a change.

3) The result of a redirect modifier that has, as its target, a domain
name that has no SPF records has been changed from returning a
result code of "None" to "PermError". Actually, I'm not certain
what the result code in the earlier draft should be because it was
a corner case that was not addressed.


There were quite a few places where we either removed things like
Receiver Policy, or changed things from "MUST" to either "SHOULD" or
"MAY". We did this when we found that existing implemenations did not
obey the "MUST" and in practice, a "SHOULD" or "MAY" would be more
productive as the standard.

In some cases we also had to tighten the requirements in order to make
things more portable. For example, there were a couple of SPF
implementations (pre-MARID) that enforced processing limits needed to
prevent SPF from being used as an (effective) DoS vector. Since these
implementations were deployed, domain owners need to make sure their
records conform to these limits in order to make sure their records
would be processed correctly everywhere.

Finally, we found some cases where features were simply not used in
practice. For example, the ABNF for the Received-SPF: header in the
older specs could allow for the creation of headers that did not
conform to what RFC2822 wants. In practice, the Received-SPF: headers
generated by actual implementations conformed to RFC2822, and so the
ABNF could be tightened up.


It took a great deal of work to find as many SPF implementations as we
could, figure out how the actually worked, find as many SPF records as
we could, figure out which features are used, and to resolve as many
conflicts as we could in the best, most coherent, way we could.


While I'm sure that the SPF-classic I-D can be improved, I think it
has done a good job of meeting the goal of documenting SPF, as it
existed pre-MARID.


-wayne

[Douglas Otis]

Post by wayne

Post by Douglas Otis
If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should be on an historic track. ; )

4.2.4 Historic
A specification that has been superseded by a more recent
specification or is for any other reason considered to be
obsolete is
assigned to the "Historic" level. [...]
This wouldn't apply because there are no newer specifications for SPF,
nor is it obsolete.

My apologies for this poor attempt at humor. With the authors
insisting the draft only documents prior art that is now in conflict,
it becomes difficult to consider this draft as experimental.

With an experimental draft, one would expect modifications addressing
issues as they arise. This record conflict has been a problem for a
long time. If this draft is really only for historical purposes,
perhaps SPF Classic should dropped. Sender-ID would then need to
introduce a different draft defining the syntax related to the DNS
records.

Post by wayne

Post by Douglas Otis
SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, [...]

There isn't a "pristine" version of SPF, there are several different
draft specifications and a whole bunch of implementation. There are,
unfortunately, conflicts between these. The SPF-classic I-D attempts
to document the most coherent intersection of these.

The reduction in processing limitations seemed substantial with
understandable reasons. There was a change that including HELO in
parallel with the MAIL FROM rather than when the MAIL FROM was NULL.
A number of other changes have since been struck. Problems created
when modifying record processing or what identifies are applied could
be ameliorated through use of record versioning. This would ensure
the server understood how to utilize the record being offered.

While I agree with the view that PRA semantics may create problems
when applied against the initial record version, the Sender-ID draft
permits the use of a scoped version of the record which makes it
clear what semantics are expected. Accommodating this identical
provision within SPF would have resolved the potential Sender-ID
conflict and also would have been a means to acknowledge adherence to
newer processing limits and HELO checking, for example.

Sender-ID does not define the syntax of the record, but instead
depends upon the SPF draft for these definitions. It would appear
the Sender-ID draft is willing to follow the syntax defined by the
SPF draft. The major difference is that Sender-ID accommodates both
versions of the record, whereas, despite the reasons, SPF has
deliberately elected not to support the scoped version.

This difference relates to a prefix of "v=spf1 ..." versus "spf2.0/
<scope>,<scope> ..."

Post by wayne
While I'm sure that the SPF-classic I-D can be improved, I think it
has done a good job of meeting the goal of documenting SPF, as it
existed pre-MARID.

I understand this is the justification used for the draft then
ignoring the scoping problem. : (


Solutions:

a) Sender-ID avoids applying any RFC-2822 content semantics to the
initial DNS record version.

b) SPF incorporates support for a scoped version of the DNS record.

c) a & b

d) Drop SPF Classic and create a separate syntax document.


The number of domains publishing the initial version of the DNS
records negatively affected is likely less than those that benefit.
By itself, SPF is not without its own significant issues. Even
Hotmail publishes just the initial record version, but depends upon
the PRA. It would seem that while the SPF effort claims
guardianship, they have been guilty of versioning abuses as well.
Although option b is not perfect, it is good enough.

-Doug

[wayne]

Post by Douglas Otis

Post by wayne

Post by Douglas Otis
SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, [...]

There isn't a "pristine" version of SPF, there are several different
draft specifications and a whole bunch of implementation. There are,
unfortunately, conflicts between these. The SPF-classic I-D attempts
to document the most coherent intersection of these.

The reduction in processing limitations seemed substantial with
understandable reasons.

The reduced process limits has existed dating back to Feb 23, 2004 in
the libspf-alt implementation. It was picked up later (still
pre-MARID) by at least one other SPF implementation.

Post by Douglas Otis
There was a change that including HELO in
parallel with the MAIL FROM rather than when the MAIL FROM was NULL.

Independent HELO checking was argued for since the summer of 2003.
The Spamassassin development version was doing HELO checking in the
Dec 2003 or Jan 2004, I'm not sure which. The change in the spec
dates back to May 16 2004. While MARID was going on at that point, it
was still before the MARID WG had adopted any drafts.

In reality, this is an incredibly minor change because almost all
MTAs send email with a null MAIL FROM every once and a while, so the
HELO domain would be checked at least some of the time. Having it be
checked all the time makes very little practical difference.

Post by Douglas Otis
A number of other changes have since been struck.

Yes, there were a HUGE number of incompatible changes made during the
MARID process and, in hind sight, starting with the MARID drafts and
trying to make it compatible was probably a mistake. However, we did
try to eliminate as many changes as we could find.

Post by Douglas Otis
Problems created
when modifying record processing or what identifies are applied could
be ameliorated through use of record versioning.

Maybe, but the implementations that did the processing limits were
deployed in early 2004, so unless you have a time machine, we are
pretty much stuck with them now.

Post by Douglas Otis
While I agree with the view that PRA semantics may create problems

s/may/will/

Post by Douglas Otis
when applied against the initial record version, the Sender-ID draft
permits the use of a scoped version of the record which makes it
clear what semantics are expected.

Our goal in writing the spf-classic draft was to document what is and
was, not to create something new. The job of creating something new
was given by Ted Hardie to the MARID authors.

Post by Douglas Otis
Accommodating this identical
provision within SPF would have resolved the potential Sender-ID
conflict and also would have been a means to acknowledge adherence to
newer processing limits and HELO checking, for example.

The SenderID drafts have never contained the HELO identity. This
makes it not fully backwards compatible with SPF-classic. The
SenderID drafts are not under our control, so we can't fix it.


-wayne

[Sam Hartman]

Post by Andrew Newton
But since you brought this up: if you (the author of the
document) do not consider this to be an experiment, then
perhaps the IETF should not publish SPF as an Experimental RFC.

wayne> I asked for the IESG to not consider the SPF I-D to be
wayne> experiemental. It was turned down. According to Ted,
wayne> *none* of the IESG members expressed interest in changing
wayne> the status from Experiemental.


As a point of fact, I only saw requests from you to publish as a
proposed standard or some other standards track document rather than
experimental.

Of course I would not have seen private communication between you and
Ted.

however if you do not consider SPF an experiment, standards track is
not the only status to consider.

[wayne]

Post by Sam Hartman
wayne> I asked for the IESG to not consider the SPF I-D to be
wayne> experiemental. It was turned down. According to Ted,
wayne> *none* of the IESG members expressed interest in changing
wayne> the status from Experiemental.
As a point of fact, I only saw requests from you to publish as a
proposed standard or some other standards track document rather than
experimental.
Of course I would not have seen private communication between you and
Ted.
however if you do not consider SPF an experiment, standards track is
not the only status to consider.

Yes, good point. I really hadn't considered other status. I guess
Informational might also be appropriate.

I still think Standard Track is most appropriate, but again, I don't
think it would be a productive use of time to try and change the
current Experimental designation.


-wayne

[Frank Ellermann]

Post by wayne
Informational might also be appropriate.

Not from my POV, I wanted this beast under IETF control.

That's why I pushed for an RfC, and later after reading
the "fine print" 2026 for standards track.

"Informational" is something the authors could update
whenever it pleases them. There was no SPF Council
last year, "we" (TINW) trusted that the IETF and MARID
would get it right.

Okay, that failed spectacularly forcing "us" to create
the SPF Council. I still prefer standards track, not
some obscure one and a half standards SDO "SPF". The
role model for "us" might be XMPP (not Phil's idea W3C,
that's megalomaniac).

Post by wayne
I still think Standard Track is most appropriate

ACK. Now if the IESG thinks that something with less
than one million participants covering roughly about 80%
of AOL's inbound mails is an "experiment", then that's
their choice, and we'll remind them of their own choice
for each and every wannabe-PS with a smaller deployment.

Post by wayne
I don't think it would be a productive use of time to
try and change the current Experimental designation.

ACK. Better get a proper PS later, with interoperability
reports, relevant "lessons learned", etc. - too late for
DKIM, but still useful for other / later efforts trying
to do wild and wonderful things with DNS. Bye, Frank

[Alan DeKok]

Post by Frank Ellermann
Not from my POV, I wanted this beast under IETF control.

Why? The concerns you expressed in your previous message about the
IETF leadership and methods were serious.

How do you believe you can move forward, given your concerns?

Alan DeKok.

[Frank Ellermann]

Post by Alan DeKok

Post by Frank Ellermann
Not from my POV, I wanted this beast under IETF control.

Why?

Because Meng and the SPF community as it was before MARID
produced at least three ideas how to change the spec. per
hour, and that made me very nervous.

With a reason, Meng manouvered himself in a very awkward
position, after all he's the co-author of both drafts in
the subject. He claims that it's sitting on a fence, but
actually it's barbed wire.

Post by Alan DeKok
The concerns you expressed in your previous message about
the IETF leadership and methods were serious.

Some of them, not all of them. It's a test, interesting
for anybody volunteering time for the IETF if it turns
out to be "directorated" by the commercial interests of
some big players.

Post by Alan DeKok
How do you believe you can move forward, given your
concerns?

Julian proposed a simple remedy, it could be even shorter,
delete four letters in chapter 3.4 of senderid-core. Bye.

[Graham Murray]

Post by Andrew Newton
But since you brought this up: if you (the author of the document) do
not consider this to be an experiment, then perhaps the IETF should
not publish SPF as an Experimental RFC.

That would be a good idea. As there is already more than one implementation of
the SPF protocol, should it not be possible to 'skip' the experimental phase
and go straight to the start of the standards track?

[Andrew Newton]

Post by Graham Murray

Post by Andrew Newton
But since you brought this up: if you (the author of the document) do
not consider this to be an experiment, then perhaps the IETF should
not publish SPF as an Experimental RFC.

That would be a good idea. As there is already more than one
implementation of
the SPF protocol, should it not be possible to 'skip' the
experimental phase
and go straight to the start of the standards track?

It should not be possible. Please consult RFC 2026 and RFC 2418.

-andy

[Julian Mehnle]

Post by Andrew Newton

Post by wayne

Post by Andrew Newton
If this is the source of the conflict, then BOTH experiments should
not use the v=spf1 records.

The stated goal of draft-schlitt-spf-classic is to document SPF,
basically as it was before the IETF got involved. Yes, the IETF is
calling it an experiment, which I don't agree with. It is
documenting an existing, well established, protocol.
Are you saying that the IETF shouldn't publish an RFC that documents
SPF?

I stated that the SPF and Sender ID experiments should not use the
v=spf1 records to avoid conflict. [...]

I does not make sense in any practical way whatsoever to make SPFv1 not
use "v=spf1" records. The fact that the IESG chose to perceive SPF as an
experiment doesn't change that, either.

I know that there are many people who would like to eradicate SPF from
history for a variety of reasons, but (a) it just cannot be done, and (b)
many other people, me included, would consider it a gross waste, because
it is evidently far from useless (even if a successor specification might
be desirable, or if other protocols are also not useless).

Please also remember that nobody is asking for Sender ID not to make use
of "v=spf1" records _at_all_. The appeal is about Sender ID using them
for PRA checking, so please be careful when wording statements like the
above.

[Frank Ellermann]

Post by Andrew Newton
I stated that the SPF and Sender ID experiments should not
use the v=spf1 records to avoid conflict.

Yes, you are a prominent part of this "embrace and extend"
strategy also known as "steal or destroy".

Post by Andrew Newton
if you (the author of the document) do not consider this to
be an experiment, then perhaps the IETF should not publish
SPF as an Experimental RFC.

Perhaps the IETF should choose its leadership more carefully.

It didn't work, this trick to get rid of the critical "NOT
RECOMMENDED" in draft-schlitt by a note to the RfC editor.

It didn't work, this trick to close MARID when it was clear
that abusing v=spf1 for PRA is a non-starter.

Hopefully it also won't work by the infamous "SHOULD abuse
v=spf1" in senderid-core-01.

The persons listed on...
http://www.ietf.org/u/ietfchair/dea-directorate.html
as well as all "no objections" on http://tinyurl.com/ayaun
will have a hard time to redeem themselves in my eyes, and
so far only one managed this.

When Keith said here that all this was only an error, not
intentional, I fear that isn't the case for some of these
persons.
No paseran

[Stephane Bortzmeyer]

On Thu, Aug 25, 2005 at 10:14:39AM -0700,

Post by Harald Tveit Alvestrand
are you of the opinion that the IESG should try to police which
experiments get run on the Internet by refusing to publish RFCs
documenting possibly-conflicting experments?

If the IESG were to refuse to publish the Sender-ID document as it is,
it would not "police" everything: anyone can still do what he wants on
the Internet.

The only thing than the IETF can do is to "bless" or not the document,
saying in essence "it is interesting and worth more
experimentation". Not blessing it does not mean actively using lethal
force against those who still want to try it.

So, cool down, nobody asked the IESG to police or to censor or to
forbid, just to NOT bless a bad idea (reusing SPF records in an
unattended way).

[Theodore Ts'o]

Post by Stephane Bortzmeyer
If the IESG were to refuse to publish the Sender-ID document as it is,
it would not "police" everything: anyone can still do what he wants on
the Internet.
The only thing than the IETF can do is to "bless" or not the document,
saying in essence "it is interesting and worth more
experimentation". Not blessing it does not mean actively using lethal
force against those who still want to try it.
So, cool down, nobody asked the IESG to police or to censor or to
forbid, just to NOT bless a bad idea (reusing SPF records in an
unattended way).

I agree with this sentiment. It's not like the RFC series is the only
place that protocol specifications for such experiments can be
published, and with Google and the Wayback Archive, the search and
persistence problems are solved as well. So we should only publish if
we think we can add some kind of value beyond that which any yahoo who
owns a web server can do with publishing some random specification on
the web.

Making sure that experiments don't collide with one another seems like
a very basic starting point. This is especially important in this
particular case given how contentious the debate over proposals in
this problem space have been in the past.

- Ted

[Hallam-Baker, Phillip]

Let me phrase it this way: the IESG should not sanction conflicting
experiments by publishing conflicting specifications,

I agree.

But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this was accepted by the WG right up to the point where
people started to complain about IPR licenses.

I do not think that the IESG should block a proposal citing a conflict
when the real animus here is entirely due to the IPR issue.

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.

Nobody has ever demonstrated a conflict as far as I am concerned, all
attempts to allege a conflict begin, "the sender intends" which is
utterly irrelevant. The sender does not have the right to decide what
email client I use, they do not have the right to determine what spam
filter I use either.

Sender-ID simply describes one means of interpreting an SPF record. It
may or may not work, it may or may not be optimal, that is why it is an
experiment.

An SPF record may be constructed in such a fashion that Sender-ID
verification is not possible. That is not a conflict, it is simply an
artifact that results from the baroque nature of the SPF spec.

I do not believe that one group should be able to block a proposal they
do not like by alleging a non-existent conflict.

[Dotzero]

Post by Hallam-Baker, Phillip

Let me phrase it this way: the IESG should not sanction conflicting
experiments by publishing conflicting specifications,

I agree.
But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this was accepted by the WG right up to the point where
people started to complain about IPR licenses.

Not quite correct. The reason that people did not complain was that
supporters of SID were pushing for use of SPF2 records at the time. It
was only after the announcement that SID would use (abuse) SPF1
records that it became an issue.

Post by Hallam-Baker, Phillip
I do not think that the IESG should block a proposal citing a conflict
when the real animus here is entirely due to the IPR issue.

So all of the discussion on the spf-discuss list has nothing to do
with technical issues and has only been a cover for unhappiness with
IPR issues? I find that a stretch.

Post by Hallam-Baker, Phillip
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.

Let us remind ourselves what SPF stands for SENDER Policy Framework.
If the publisher of a record has no reasonable expectation of how that
record will be used and every expectation that it may be abused then
what incentive do they have to publish the record?

SPF does not describe outgoing edge mail servers.... it describes the
policies associated with the domain. The issue at hand is not whether
an individual recipient chooses to interpret the data a particular
way. Interpretation by the recipient is should I reject on softfail or
not or should I assign a point value in conjunction with other things.
Writing a standard which subverts the intent of individuals publishing
to a different and existing standard is simply unethical and wrong.

What happened was essentially a political move because people chose
not to publish SPF2 records for PRA. So, the response was to force
people to opt-out (publish an essentially meaningless SPF2 record)
because the SID camp was losing in the real world marketplace.

Post by Hallam-Baker, Phillip
Nobody has ever demonstrated a conflict as far as I am concerned, all
attempts to allege a conflict begin, "the sender intends" which is
utterly irrelevant. The sender does not have the right to decide what
email client I use, they do not have the right to determine what spam
filter I use either.

An interesting argument. Of what value is publishing a record (of any
sort) if the publisher of said record has a reasonable expectation
that it will be used in arbitrary ways to the publishers detriment?
One argument that was put forth after the announcement that SID would
apply PRA to SPF1 records was that it was a conspiracy to get
publishers to yank their SPF1 records.

People and organizations chose to publish a record according to a
standard because they have a reasonable expectation on how that record
will be used. While there may be edge cases of abuse, the expectation
is that most people will respect the standard. That's why it's called
a standard.

Post by Hallam-Baker, Phillip
Sender-ID simply describes one means of interpreting an SPF record. It
may or may not work, it may or may not be optimal, that is why it is an
experiment.

I can see someone using this "logic" in any number of circumstances....

"Your honor, I have this alternative means of interpreting what a red
stoplight indicates.....go go go as fast as you can".

Post by Hallam-Baker, Phillip
An SPF record may be constructed in such a fashion that Sender-ID
verification is not possible. That is not a conflict, it is simply an
artifact that results from the baroque nature of the SPF spec.

You are implying that individuals published SPF1 records with the
intent of subverting SID verification. This is akin to blaming the
victim for the actions of the mugger. I would argue that most of those
who published SPF1 records did so with no knowledge or anticipation
that PRA would be applied to those records.

Post by Hallam-Baker, Phillip
I do not believe that one group should be able to block a proposal they
do not like by alleging a non-existent conflict.

I don't hear anyone trying to block the SID proposal in its entirety.
I only see the blocking of an abusive portion of the proposal.

Why weren't the supporters of the SID proposal willing to go out and
promote use of SPF2/PRA format/records? I haven't seen any of the core
SPF activists oppose the use of SPF2 records by SID for PRA.

We again come back to the politics of the issue. SID was losing in the
marketplace (numbers of published records). A significant aspect of
these types of experiments is whether people buy in to the approach.
Applying PRA to SPF1 records was a way of sidestepping this issue
regardless of whether the (publisher)marketplace bought into SID.

Mike

[Frank Ellermann]

Post by Dotzero
Writing a standard which subverts the intent of individuals
publishing to a different and existing standard is simply
unethical and wrong.

+1

Post by Dotzero
What happened was essentially a political move because people
chose not to publish SPF2 records for PRA. So, the response
was to force people to opt-out (publish an essentially
meaningless SPF2 record) because the SID camp was losing in
the real world marketplace.

+1

Post by Dotzero
One argument that was put forth after the announcement that
SID would apply PRA to SPF1 records was that it was a
conspiracy to get publishers to yank their SPF1 records.

Yes, when I said "excessive technical incompotence or outright
corruption" it wasn't the polite way to put it, but it was and
still is how I feel about it.

Post by Dotzero
People and organizations chose to publish a record according
to a standard because they have a reasonable expectation on
how that record will be used. While there may be edge cases
of abuse, the expectation is that most people will respect
the standard. That's why it's called a standard.

+1

Post by Dotzero
"Your honor, I have this alternative means of interpreting
what a red stoplight indicates.....go go go as fast as you
can".

LOL, precisely. Full ACK on all your points, bye, Frank

[Jeff Macdonald]

On Fri, 2005-08-26 at 10:23 -0700, Hallam-Baker, Phillip wrote:
<snip>

Post by Hallam-Baker, Phillip
I do not believe that one group should be able to block a proposal they
do not like by alleging a non-existent conflict.

A conflict does exist interpreting v=spf1 records in a PRA scope. I had
a customer who was a victim of joe-jobbing. We use separate domains for
RFC821 and RFC822 identities. The RFC821 identity (MAIL FROM) would
never be used as a RFC822 identity (FROM).

RFC821 FROM: ***@customer.bounce.esp.com
RFC822 From: ***@brand.esp.com

Before Sender-ID came I had this:

brand.esp.com IN TXT "v=spf1 -all"

This means if brand.esp.com was ever seen as a RFC821 MAIL FROM domain,
it could be considered a forgery.

Along comes Sender-ID, reusing v=spf1 records for PRA tests. Microsoft
then decides to put a warning for those records that fail Sender-ID
tests for its Hotmail/MSN users.

Since Sender-ID checks RFC822 identities against a record meant for
RFC821 identities, it gets an erroneous FAIL.

This is what I believe is the conflict. It is real. It exists. In order
to get correct results I have to publish 2 records in DNS:

brand.esp.com IN TXT "spfv2.0/pra a:outbound.brand.esp.com -all"
brand.esp.com IN TXT "v=spf1 -all"

OR (this one opts out of Sender-ID):

brand.esp.com IN TXT "spfv2.0/pra"
brand.esp.com IN TXT "v=spf1 -all"

This also means that to participate in one experiment I have to
participate in another. That seems wrong to me.

[wayne]

Post by Hallam-Baker, Phillip
I do not think that the IESG should block a proposal citing a conflict
when the real animus here is entirely due to the IPR issue.

There are certainly people who have problems with introducing
technology into a core Internet protocol such as SMTP that has a
license that conflicts with with a significant number of deployed
servers.

That is by no means the only thing that people object to. Even if the
license problems went away, there would still be people that have
objections to the conflicting use of SPFv1 records, and, I'm sure,
people who object to the basic techniques to that both SPF and
SenderID use.

Post by Hallam-Baker, Phillip
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.

If this was the case, then there wouldn't be cases where SenderID gaves
incorrect results when using SPFv1 records.

Post by Hallam-Baker, Phillip
Nobody has ever demonstrated a conflict as far as I am concerned, all
attempts to allege a conflict begin, "the sender intends" which is
utterly irrelevant.

There are several known conflicts, as outlined in the appeal, and they
don't begin with "the sender intends".


-wayne

[Julian Mehnle]

Post by Hallam-Baker, Phillip

Let me phrase it this way: the IESG should not sanction conflicting
experiments by publishing conflicting specifications,

I agree.
But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this was accepted by the WG right up to the point where
people started to complain about IPR licenses.

You do not seem to have read the appeal and the referenced items. There
was a consensus that "v=spf1" records should not be used for checking RFC
2822 identities. This re-use was only introduced into the Sender ID spec
after MARID had already died and after the IESG had asked for individual
submissions.

Post by Hallam-Baker, Phillip
I do not think that the IESG should block a proposal citing a conflict
when the real animus here is entirely due to the IPR issue.

How do you know what the (the SPF project's) "real animus" is in making
this appeal?

Post by Hallam-Baker, Phillip
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.
Nobody has ever demonstrated a conflict as far as I am concerned, all
attempts to allege a conflict begin, "the sender intends" which is
utterly irrelevant. The sender does not have the right to decide what
email client I use, they do not have the right to determine what spam
filter I use either.

Following that logic, it would not objectionable for the IETF to publish
as an Experimental RFC a specification which told receivers to bit-wise
invert the calling MTA's IP address before applying SPF processing to it.
Sorry, I don't subscribe to that sort if nihilism.

Post by Hallam-Baker, Phillip
I do not believe that one group should be able to block a proposal they
do not like by alleging a non-existent conflict.

Burying your head in the sand doesn't make the conflict go away.
Besides, the appeal does not aim to generally block the proposal from
being published. Perhaps you should stop reading tea leaves.

[Frank Ellermann]

Post by Hallam-Baker, Phillip
But I do not believe that SPF and Sender-ID conflict in any
way whatsoever and this was accepted by the WG

What you believe is your business, but this was never accepted
by the WG, because it's plain wrong, see also reference [12]
in the appeal:

http://purl.net/xyzzy/home/test/senderid-appeal.htm#r12

The complete thread (starting in mxcomp) is very interesting:
http://news.gmane.org/group/gmane.mail.spam.spf.discuss/thread=8111

Bye, Frank

[Frank Ellermann]

Post by Hallam-Baker, Phillip
I do not think that the IESG should block a proposal citing a
conflict when the real animus here is entirely due to the IPR
issue.

Hogwash, I've proposed a way to "fix" PRA to avoid at least
the worst incompatibility (a "default Sender" derived from
the Return-Path in the spirit of RfC 3834).

After that was ignored (maybe it was a bad idea) I proposed
a clean "opt-in" modifier for those, where both "boundaries"
for PRA and MAiL FROM are in fact identical. After all that
is possible, even likely (somebody says 80%). But it is not
guaranteed (80% is not good enough, BLs operate near 99.5%).

The WG settled on "spf2.0/pra,mfrom" in the last week of its
existence, I supported this. Certainly not my fault that
the WG was closed exactly at the time when a clean solution
was in sight, http://purl.net/xyzzy/home/test/MARID.appeal.txt

JFTR. the last quote in this mail was an article from you.

MARID was closed as soon as it was clear that abusing v=spf1
for PRA without explicit consent of the sender policy publisher
is a non-starter, because it would be _tschnical_ FUBAR.

Post by Hallam-Baker, Phillip
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.

Sure, you do what you like, use PRA, or how about Message-IDs ?
Or better try a random generator., no DNS headaches if all you
want are random rejections. Most mails are spam, so rejecting
mails always hits more spam than legit mail, no matter how you
decide this.

But v=spf1 FAIL is no 80% or 99.5% idea, it is 100% if you do
it right accepting all consequences. "Interpret v=spf1 with
PRA" is not implicitly the intent of most publishers. If they
explicitly want this they are free to publish spf2.0/pra.

We're talking about RfCs defining _sender policies_ - what you
as receiver do with it is beside the point, as long as domain
owners can express their intention.

Several hundred thousand domain owners did this, they know or
should know that it means what the relevant v=spf1 drafts said.

And the SPF RfC reflects this as good as possible (calling
that an "experiment" is a part of the many MARID legends all
featuring the "let's steal v=spf1 for PRA" theme).

PRA doesn't necessarily reflect what these publishers intended.

Post by Hallam-Baker, Phillip
That is the entire point of a spam filtering scheme.

Neither v=spf1 (spf2.0/mfrom) nor PRA (spf2.0/pra) are a good
"spam filtering scheme". PRA is a (dubious) anti-phishing
idea, and the MAIL FROM part of v=spf1 fights bogus bounces
to innocent (spoofed) bystanders.

You can use both as input for "spam filtering", e.g. use PASS
as "asssume innocent until proven guilty" like AOL, or use a
FAIL as "once a liar, always a liar" indicator for the sending
IP or HELO identity.

But the primary purpose of v=spf1 is MOT "yet-another-FUSSP".
It's about avoiding bounces to spoofed Return-Paths, and maybe
offer a base for FQDN-reputation systems with HELO-PASS (same
idea as CSV-CSA).

So the design goals of v=spf1 and PRA are already different,
no surprise that many resulting policies are also different.

Post by Hallam-Baker, Phillip
Nobody has ever demonstrated a conflict as far as I am
concerned, all attempts to allege a conflict begin, "the
sender intends" which is utterly irrelevant.

That's not true, this has been proven numerous times. PRA and
MAIL FROM identity can be different for various valid reasons.

2476bis 6.1 and 2476bis 8.1 are different chapters. v=spf1 is
in the spirit of 2476 6.1, RfC 3834, STD 10, and draft-hutzler.

It has nothing to do with 2822-identities, 2476bis 8.1, or PRA.

Essentially PRA wants "SHOULD add Sender" where 2476 only says
"MAY add Sender" in 8.1. We could discuss this, and in fact
"we" (TINW) did, see also:

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

That's in the same thread mentioned before (started in mxcomp):
http://news.gmane.org/group/gmane.mail.spam.spf.discuss/thread=8111

Post by Hallam-Baker, Phillip
Sender-ID simply describes one means of interpreting an SPF
record. It may or may not work, it may or may not be optimal

If you want "sub-optimal" bogus interpretations then that's
your personal right as receiver, but the IETF (mis)represented
by the IESG should not sanction this abuse as RfC.

You can't publish an RfC where you say "if no MX works just
try A", because that would be broken and cause harm. RfCs are
not supposed to cause foreseeable harm intentionally - as the
very minimum they'd need corresponding security considerations.

Post by Hallam-Baker, Phillip
that is why it is an experiment.

The experimental status of v=spf1 is fictitious and beside the
point. The author proposed "PS" with a proper IETF last call.

Post by Hallam-Baker, Phillip
I do not believe that one group should be able to block a
proposal they do not like by alleging a non-existent conflict

Nobody proposed to "block" PRA. It should only stay away from
sender policies designed for the incompatible v=spf1. There's
nothing wrong with PRA-experiments using spf2-0/pra policies.

While I guess that PRA will fail miserably I've no problem if
others wish to paricipante in this PRA-experiment. But (not
only) I don't want this. No experiments with non-voluntary
participants. We're talking about legit mails lost in limbo,
and spectacular pseudo-PRA-PASS phishing opportunities. Bye

[Brian E Carpenter]

Julian,

The IESG will consider your appeal as soon as reasonably
possible.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
IETF Chair

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
IESG Chair Brian Carpenter,
as per the Internet Standards Process, section 6.5, and on behalf of the
SPF project, I am filing a formal appeal on the IESG's approval on
2005-06-29[1] to publish the draft-lyon-senderid-core-01 I-D[3] as an
Experimental RFC as-is.
I believe that draft-lyon-senderid-core-01 conflicts in a significant
aspect with draft-schlitt-spf-classic-02, on which the former depends, and
which has also been approved by the IESG to be published as an Experimental
RFC.[2] The conflicting part of the Sender-ID specification disrespects
the substantial history the SPF specification has outside the IETF.
Through its decision, the IESG also ignores SPF's deployed base.[3]
And even if the IESG intends to run both of the specifications as an
experiment before deciding any further on how to proceed with them, the
publication of conflicting specifications is bound to disrupt these
experiments.
Please find the full appeal included below.
Regards,
Julian Mehnle.
The Problem
===========
[...] 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 means that the I-D recommends that "v=spf1" records be used for
checking the PRA identity defined in draft-lyon-senderid-pra-01[5].
However, this is in direct conflict with draft-schlitt-spf-classic-02[6],
[...] At least the "MAIL FROM" identity MUST be checked, but it
is RECOMMENDED that the "HELO" identity also be checked beforehand.
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. [...]
"v=spf1" records have always been published by domain owners with only the
MAIL FROM and HELO identities in mind. Checking them against other
identities will most likely not only produce non-trivial amounts of false
results, but also distort the results of any intended experiments.
Proposed Remedy
===============
Change the relevant part of draft-lyon-senderid-core-01, section 3.4
Sender ID implementations MUST interpret the version prefix "v=spf1"
as equivalent to "spf2.0/mfrom", provided no record starting with
"spf2.0" exists.
In any case, draft-lyon-senderid-core should not be published until this
conflict is resolved.
Justification
=============
On 2005-06-29, the IESG announced the decision to publish both the "SPF,
version 1" <draft-schlitt-spf-classic-02> I-D and the "Sender-ID" <draft-
lyon-senderid-core-01, draft-lyon-senderid-pra-01, draft-katz-submitter-
01> I-Ds as Experimental RFCs.
The re-interpretation of SPFv1's "v=spf1" records by draft-lyon-senderid-
core-01 to be equivalent to "spf2.0/mfrom,pra", and thus to be applicable
for checking against the PRA identity defined in draft-lyon-senderid-
pra-01, conflicts with the substantial history of SPF outside the IETF
standards process. Ever since late 2003, SPF has been defined to apply
only to the MAIL FROM and HELO identities.[7,8,9]
It should be noted that at the time of the dissolution of the MARID working
group in September 2004[10], there had been at least 650,000 domains with
"v=spf1" policies published in the com/net/org TLDs alone.[11] It can be
safely assumed that the vast majority of these policies was published
based on draft-mengwong-spf.02.9.4[7], draft-mengwong-spf-00[8], or draft-
mengwong-spf-01[9], and thus with only the MAIL FROM and HELO identities in
mind.
Even though the SPF specification has undergone quite some changes since
late 2003, the focus has always been on maintaining backwards compatibility
and protecting the meaning of existing sender policies. The different
interpretation by the Sender ID specification however has significant
implications of which many domain owners were not, and could not be, aware
when they defined and published their "v=spf1" policies.
The PRA and MAIL FROM / HELO identities are not generally interchangeable,
and as a matter of fact there are prominent cases where they differ from
* Many mailing lists rewrite the MAIL FROM identity when distributing
messages, but do not change the header (PRA) identities. And they are
not required to do so by RFCs 2821 or 1123 or any other current IETF
standards.
* Many organizations with their own domains outsource their bulk message
sending (newsletters, etc.) to ESPs, who use their own domain in the
MAIL FROM identity and the organization's domain in the From: header,
but do not add a Sender: header.[12]
* If the MAIL FROM is empty ("MAIL FROM:<>"), the MAIL FROM identity, as
defined by the SPF specification, falls back to HELO identity[5,
section 2.2], while the PRA identity is usually unpredictable.
The bottom line of all these cases is that even though it might be
desirable in the long run to enforce congruence between the envelope and
header identities, this is still far from reality. And the often atypical
but otherwise perfectly standards compliant configurations in which
"v=spf1" records have been deployed over the past 1.5 years should not be
ignored just because the IESG chooses[13,1,2] to see SPF as a simple
offshoot of the failed standardization attempt in the MARID working group.
This view seems to have prevailed at the 60th IETF meeting in June 2004,
3) draft-ietf-marid-protocol-00
[...]
The room discussed the version identifier in the TXT record. Mark
introduced the subject by explaining that most people today publish
"v=SPF1" with the intention that receivers will be checking MAIL FROM
and not PRA. Many participants expressed concern over the semantic
meaning and suggested the version number would change. Marshall asked
if anybody in the room had any serious objections to changing the
version identifier; none were given. Andy directed Mark to send
suggestions for the new version identifier to the list where this would
be discussed.
So when Mark Lentczner changed[15] the version identifier to "spf2.0" in
draft-ietf-marid-protocol-01 in the aftermath[16,17] of IETF-60, there was
clearly a consensus to avoid the use of "v=spf1" records for checking of
PRA or other unexpected identities.
It is also worth noting that at the time the MARID WG was closed, the
then-current Sender ID specification draft-ietf-marid-protocol-03[18] did
not include the re-use of "v=spf1" records for PRA checking. This was
only introduced in the individual submission draft-lyon-senderid-core-00
[19] in October 2004. Also did Microsoft's record generation wizards
generate only "v=spf2.0/pra" records until the end of October[20,21], when
they began generating only "v=spf1" records.
SPF and Sender ID are potentially complementary but generally separate.
Not only should domain owners, who are the primary target audience of all
domain-based sender authentication schemes, have a choice in which
experiments they participate and in which they don't, but also should they
be able to feel confident that the experiments in which they participate
will not unnecessarily be tampered with.
In any case, the practical impact of the semantic conflict is currently
still a field of research, and even if the IETF intends to publish the
Sender ID and SPF specifications as Experimental RFCs in order to gain more
experience and reach community consensus in the future[1,2], then setting
up conflicting experiments is certainly going to prove counter-productive.
1. http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01356.html
2. http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01357.html
3. http://article.gmane.org/gmane.mail.spam.spf.council/340
4. http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
5. http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt
6. http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-02.txt
7. http://spf.pobox.com/draft-mengwong-spf.02.9.4.txt
8. http://spf.pobox.com/draft-mengwong-spf-00.txt
9. http://spf.pobox.com/draft-mengwong-spf-01.txt
10. http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html
11. http://www.imc.org/ietf-mxcomp/mail-archive/msg05105.html
13. http://article.gmane.org/gmane.mail.spam.spf.council/339
14. http://www.ietf.org/proceedings/04aug/116.htm#cmr
15. http://www.imc.org/ietf-mxcomp/mail-archive/msg03282.html
16. http://www.imc.org/ietf-mxcomp/mail-archive/msg03164.html
17. http://www.imc.org/ietf-mxcomp/mail-archive/msg03081.html
18. http://web.archive.org/web/20041115043332/http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-03.txt
19. http://web.archive.org/web/20041117011615/http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-00.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDDPiHwL7PKlBZWjsRApnbAKDFRk3VaEiPrXv7ulF2atjbW85w1QCeJUnS
kj3OjXsjR1KEQiFTUNK0Y1M=
=x3Lt
-----END PGP SIGNATURE-----