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

[Frank Ellermann <[e-mail]>]

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



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