Pretty much all that Frank just said is good. I'll note that there is no
requirement to send copy of appeal to ietf(_at_)ietf(_dot_)org(_dot_) What
should be done
(just as a way to confirm the day of the appeal and that it happened) is
send copy to some public list (i.e. it could be spf-discuss or even
mxcomp list), but sending well worded appeal to main ietf list could
facilitate discussion of this topic with general IETF audience which maybe
beneficial to the case (but could backfire as well). Also it might be
good to mention that experiments should not conflict with existing standards
(and not only with other experiments) and should be limited only to those
who agreed to participate - neither one is true in case of SID (but the
problem is I can't find any IETF document that actually formally says
there should be no conflicts although to me as probably to many others
this is kind of obvious prerequisite)
Now I note that since Wayne said that SPF Council made a resolution to
go with appealing the decision it is COUNCIL'S responsibility to follow
up on this resolution (and QUICKLY!). That means you either decide who
of the SPF Council members would be making an appeal next week or you
deligate to to somebody else, but you can't just leave it up in the air
as time to will run out very very soon.
On Sun, 21 Aug 2005, Frank Ellermann wrote:
johnp wrote:
I would be glad to look through it and give my 2cents worth.
Perhaps you could post it here, or at least circulate it
amongst teh people you know are active?
Added below, I've snipped the quotes - there are no special
"trade secrets" about appeals, they are published on an IETF
Web page.
Date: Mon, 25 Jul 2005 07:58:34 +0200
From: Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
[...]
Yes, the MARID appeal - didn't make it to the offiial list,
because Mr. Hardie was fast babbling about a required remedy
etc,, and events changed from day to day, so I didn't answer
Harald's (former IETF chair) confirmation request in time.
[...]
Or Mark or William or all three of you. A quick outline:
1 - the problem
2 - the proposed remedy
3 - explanation (maybe swap 2 and 3)
2 (remedy) is simple:
Replace "SHOULD treat as spf2.0/pra,mfrom" by "spf2.0/mfrom".
Find the proper text in draft-lyon-senderid-core-01, quote
it (specifying the section), propose new text, ready.
1 (problem) is also simple:
draft-schlitt v=spf1 and draft-lyon are mutually exclusive
experiments. The former has NOT RECOMMENDED (insert proper
quote), the latter has SHOULD (see 1), that's incompatible.
3 (reasons, or 2' if you swapped 2 and 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.
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)
3.3
MARID agreed to use a ersion 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).
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.
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.
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.
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.
Send stuff to chair(_at_)ietf, Brian, and the IESG-list, maybe Cc:
ietf list as John did. Or better exactly as he did, send a
copy to the IETF list later if Brian (current Chair) doesn't
react.
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)
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).
[...]
Discuss it also with William. If you don't have the two or
three mails I sent to Wayne about this ask, I could copy them.
Maybe add a link to the Community position list of signers in
your "evidence" footnotes. Only as a gimmick, not as a major
point.
Bye, Frank