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".
I have developed, on my own and originally for my own use, fixes for
some sid-milter bugs and some extensions. (One of the extensions is an
option NOT to use v=spf1 for PRA. I run it with that option on.)
As a member of the sid-milter user community, I wrapped my stuff into
a patch, made it available by ftp, and posted an announcement on the
sid-milter-discuss mailing list. Much of what I've done will be
incorporated into the next release of sid-milter, hopefully due out
any day now, and I have been in private communication with the
maintainer about that.
However, I do not work for Sendmail Inc. and do not in any way pretend
to represent them or have any relationship with them. I am just a
highly-experienced programmer who uses sendmail open-source stuff,
tends to meddle with code I use, and tries to give back anything I do
that might be useful to others.
Perhaps you can answer some questions:
My responses wont' be very useful.
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.
Are they any at all?
Probably. For one thing, SenderID does not do HELO checks. As it
happens, I think the notion that only a single SPF record is needed to
specify policy for HELO and MFROM is as silly as the notion that only
one is needed to specify policy for MFROM and PRA.
sid-milter doesn't do HELO checks. I think it also regards the "h"
macro as deprecated and does not implement it.
If not, why does the senderid-core document need to be 17 pages long?
I have no idea.
If there are, how many of them are correctly implemented by Sendmail
Inc's sid-milter?
I don't know. sid-milter is a work-in-progress, and the last release
was a bugfix release before the July SenderID drafts came out.
Do you know if Sendmail Inc. is committed to conforming to the RFCs
and will change if the RFCs change?
You'll have to ask them. However, I suspect it's safe to say that
they will conform to any RFCs that become standards.
That said, I will be interested in seeing how they handle the
"Resent-" header issue. Currently, it is difficult, if not
impossible, to make sendmail insert such a header when forwarding (as
opposed to re-mailing).
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com
-------
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