In <17305.50310.846622.280515@xxxxxxxxxxxxxxxx> "Dick St.Peters" <stpeters@xxxxxxxxxxxxx> writes: > wayne writes: >> In <17305.36224.584090.853821@xxxxxxxxxxxxxxxx> "Dick St.Peters" <stpeters@xxxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf