In
<17305(_dot_)50310(_dot_)846622(_dot_)280515(_at_)saint(_dot_)heaven(_dot_)net>
"Dick St.Peters" <stpeters(_at_)NetHeaven(_dot_)com> writes:
wayne writes:
In
<17305(_dot_)36224(_dot_)584090(_dot_)853821(_at_)saint(_dot_)heaven(_dot_)net>
"Dick St.Peters" <stpeters(_at_)NetHeaven(_dot_)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
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com