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

In <17305.50310.846622.280515@saint.heaven.net> "Dick St.Peters" <stpeters@NetHeaven.com> writes:

> wayne writes:
>> In <17305.36224.584090.853821@saint.heaven.net> "Dick St.Peters" <stpeters@NetHeaven.com> writes:
>> 
>> > Julian Mehnle writes:
>> >> As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was 
>> >> submitted for experimental status, there was no "running code" that 
>> >> actually interpreted "v=spf1" as "spf2.0/mfrom,pra".
>> >
>> > Perhaps you shouldn't have said that.  Sendmail's sid-milter has used
>> > [...]
>> 
>> I know you have worked quite a bit on Sendmail Inc.'s sid-milter for
>> them.
>
> No, I have not ... not "for them".

Indeed, I should have said "for it", and I apologize.

I'm going to keep my reply to the IETF list terse and reply more fully
on the SPF list.  I think quite a bit of this is off-topic here.

>> The draft-lyon-senderid-core-01 document is fairly long, some 17
>> pages.  This is the document that references the SPF-classic spec and
>> modifies the semantics for use by SenderID.  (There are two other
>> SenderID documents to describe the PRA and the SMTP SUBMITTER
>> extention.)
>> 
>> Can you list the semantic differences between SPF-classic and SenderID
>> that need to show up in implementations that support both?
>
> No, I can't.  I've read parts of the documents but haven't read any in
> detail.

These were somewhat of trick questions.  I *have* read the SenderID
drafts, and made a long list of comments, sent to both the authors and
the IESG.  (This was during the IESG evaluation period.)

There is a fairly long list of different semantics between an v=spf1
record evaluated under the SPF spec, and under the SenderID
spec, *even* when doing the "mfrom" evaluation.  For those that don't
know, the SenderID spec has two different identities that the records
can be evaluated under: the "mfrom" and the "pra".  The "mfrom" is
supposed to be compatible with SPF, the "pra" is new.

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 because not enough people implemented them.  

So, when the SenderID spec says to evaluate "v=spf1" records as if
they were "spf2.0/mfrom,pra", even the evaluation of the "mfrom" part
is not wholely compatible.

Many, but not all, of these semantic differences are minor.  It
really is not clear at all what exactly these differences are, why
they exist, and what the ramifications are.

-wayne

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf