On Mon, Aug 22, 2005 at 11:06:25PM +0200, Julian Mehnle wrote:
It seems that nobody else has prepared one,
so I went ahead and did it, making use of Frank's write-up (thanks!).
All right!
Thank you, thank you, Julian! (And Frank!)
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 had outside the IETF. And
even though the IESG intends to run both of these as an experiment before
deciding any further on how to proceed with them, the publication of
conflicting specifications is bound to disrupt these experiments.
Well worded.
Proposed Remedy
===============
Change the relevant part of draft-lyon-senderid-core-01, section 3.4
"Compatibility", to read:
Sender ID implementations MUST interpret the version prefix "v=spf1"
as equivalent to "spf2.0/mfrom", provided no record starting with
"spf2.0" exists.
I was under the impression that the spf2.0/mfrom and v=spf1 syntaxes
weren't precisely compatible. I don't remember the details off the top
of my head, but I'm sure it's been brought up here on the spf-discuss list.
If it is true that the syntax is different, then Sender ID
implementations shouldn't read v=spf1 records at all.
Sender ID and SPF 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 semantical conflict is currently
still a field of research, and 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.
Extremely well worded.
Two things:
1. Should the patent issue be brought up at all? I'd hate for a
patent-encumbered and patent-divisive standard to become entrenched
due to a long experimental phase.
I can suggest wording if you don't think it would distract from
the appeal.
2. I have just thought of a possible "re-use" thought experiment:
The spv1 spec could re-purpose MX records to be RMX-type records if
the domain owner doesn't "opt-out" by including a "v=spf1 ?all"
record.
That is, the spf1 spec could consider, if there were no spf1 record
for a domain, that there be a default assumed spf record of: "v=spf1
mx -all", meaning that compliant receivers would drop all mail that
didn't come from the incoming mail servers from non-spf-publishing
domains.
I wonder if the ietf would be okay with that sort of re-use, as it's
similar to what they're doing by planning to accept Sender ID's
re-use of spf1 records, while being similarly prone to problems.
In other words, I wonder if that could be turned into a useful
example for the appeal.
(If not, that's fine--I just wanted to throw out the rough idea in
time for it to be useful if it could at all help.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com