-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
A quick outline:
1 - the problem
2 - the proposed remedy
3 - explanation (maybe swap 2 and 3)
[...]
3 [...] is partially simple:
3.1
State that v=spf1 is deployed since early 2004 (or even say late 2003,
but that's shaky) with an unknown but huge number of published policies,
last estimate by MS 750,000 at <date> (whenever it was, IIRC late 2004
shortly after the demise of MARID).
These policies were published based on draft-mengwong-01 and
predecessors, they are all designed for the MAIL FROM and HELO identities
(essentially the same as in draft-schlitt). Add a link to an old draft-
mengwong in any public archive, at the IETF it's expired, maybe it's
somewhere on the new SPF site.
I dug out Wayne's survey from September 2004[1], more precisely, just one
day after MARID died. That seemed like a good date to me in order to prove
that S-ID (the "v=spf1" part of it) could not have played a significant
role in publishers' minds.
The oldest sensible numbers from MS I could find were "750,000 domains
[...] publishing [SPF] records" in their March 2005 press release[2].
March 2005 however is a bit late. The only other number I could find was
in a pseudo-interview[3] from October 2004: "60,000 or so domains out there
that have already published their records" -- but this number seems to be
bogus or/and related to "spf2.0" records only.
Thus I tend to simply neglecting to refer to any numbers from MS.
3.2
PRA and MAIL FROM are different in at least 4 cases:
- mailing list without its own PRA Sender (e.g. Sympa / Yahoo), actually
any mailing list behaving as specified in 2821 x.y or 1123 5.3.6 b
(check the sections) would cause MAIL FROM != PRA and not work with
v=spf1. (Don't mention that it also won't work with spf2.0/pra,
that's not our problem)
- mail submission (MSA) implementing 2476bis 6.1 but not 8.1, and a MUA
not adding a missing Sender on the fly
- news submission to the moderator of a newsgroup by the news server if
it's done by as normal "forward".
- empty Return-Path (the MAIL FROM identity is then determined by the
HELO, pointer to a section of draft-schlitt)
I tend to omitting the "MSA/MUA disregards the RFCs and/or common sense"
case because it doesn't make a good argument. Similarly, the "news
submission" case is quite obscure. Instead I added the "BATV, SES, SRS,
VERP not caring about the headers" case in my draft.
3.3
MARID agreed to use a version string v=marid or later spf2.0 or finally
spf2.0/pra especially to avoid this kind of problems with existing v=spf1
policies.
Add links to the evidence, Meng's CYA article (v=marid), and two articles
in MARID introducing spf2.0 and spf2.0/pra resp. -- if possible by the
Chairs (IIRC Andy) or Meng / Mark / Wayne, Or Jim and Harry. Not by
random WG members like me. Sorry, I don't have relevant Message-IDs for
this part (but I could find Meng's v=marid Olson CYA article).
I could not find anything about a "v=marid" version string, and so I also
couldn't find "Meng's CYA" article. Instead, I found two appropriate (I
think) messages from Ted Hardie and Wayne[4,5].
If you can, please find "Meng's v=marid Olson CYA" article.
3.4
IMHO that's a complete case. It starts to get tricky if you want to give
reasons why the IESG isn't supposed to allow such conflicting
experiments. Maybe say something about useless results.
Yes, there is simply no _strong_ argument against having two conflicting
"Experimental" RFCs. RFC 2026 is pretty fuzzy about those. I have done
the best I can pleading the "Don't make the experiments useless!" case.
3.5
Mention that even PASS results could be misleading (cross-user forgery at
an 2476bis 6.1 MSA not supporting 8.1, same problem as in 3.2), and could
allow pseudo-PRA-PASS phishing. That's a security problem.
I'm not so sure about that one. I mean, I'm certain this case is
theoretically valid, but it appears to me as quite obscure. It is based on
an MSA which allows a weird form of cross-user forgery. It could be argued
that the MSA just should be fixed.
Do you really think this is a _real_ security threat?
3.6
Mention that some mails will be only marked as FAIL, and not rejected.
Users will delete it without checking _because_ PRA != MAIL FROM false
positives might be rare.
This case is based on a heuristic assessment of probable user behavior.
I'm not sure this makes a strong argument; instead it could sidetrack from
our (so-far) strongest argument, the dilution of any intended experiments.
Last but not least don't make it too long, read the public IESG page with
the few appeals so far (some failed, some okay), and especially the
latest appeal by John C. Klensin, that's the best example how it could
and should be done.
All done.
Maybe add links to articles explaining the problem _before_ the RfCs were
approved (IETF list, Council list, mxcomp - articles with Cc: IESG make
sense, I could propose two of my Message-IDs if you don't find them, but
better use only article per author)
Hmm, I haven't linked to any spf-discuss or spf-council messages in the
draft so far. Does anybody know any good candidates?
That's more or less the idea for this step, remove anything that's not
very convincing or too obscure, your normal footnote style is ideal for
this exercise).
Done.
References:
1. http://www.imc.org/ietf-mxcomp/mail-archive/msg05105.html
2. http://www.microsoft.com/presspass/press/2005/mar05/03-02SIDFPR.mspx
3. http://www.microsoft.com/presspass/features/2004/oct04/10-25SenderID.mspx
4. http://www.imc.org/ietf-mxcomp/mail-archive/msg03164.html
5. http://www.imc.org/ietf-mxcomp/mail-archive/msg03081.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDCk2kwL7PKlBZWjsRAuWBAJ9/G2Rh9WcvujkCTSa2uBObpY0pQgCguQ3c
Vo7vXukWGXuqKkBgBnOC+qg=
=B88n
-----END PGP SIGNATURE-----