On Mon, 29 Jan 2007, David MacQuigg wrote:
op=pra "it is ok to use this SPF record for PRA checking"
op=nohelo "do not check HELO for this SPF record"
op=helo "reject this domain in HELO unless SPF gets PASS"
op=auth "We've taken steps to prevent cross customer forgery
for SPF PASS"
OK, I found the draft (draft-ellermann-spf-options-01). Doesn't look like
op=helo will do what we need, however. Section 3.2 of the draft refers to
"the FQDN given in a HELO command", and I assume this means the complete
hostname, not just the domain name which we are using as the transmitter's
ID. If I understand it correctly, this option offers basically the same
It means the HELO name. It can be any FQDN you wish that resolves to
an IP. You can use the same name for multiple hosts, just list all
the IPs authorized to use that name in the SPF record. (You can also
list them via multiple A records for the name.)
functionality as CSV, requiring an authentication record for each and every
host, which we can't expect domain owners to do.
You need an authentication record for each and every name you
want to authenticate with SPF, HELO or otherwise.
There was a proposal for "zone cuts" for SPF a while back to provide
default SPF records and reduce the number of records to be published
in some cases. But it really doesn't save publishers any work, and made
checking more complicated. For instance, a Bind zonefile macro works
just as well to save typing.
We need a way to generate a complete list of authorized HELO addresses by
"compiling" an SPF record. We can't ignore ?all, ptr mechanisms,
%{macros}, and other stuff that prevent such a compilation unless there is
some signal from the domain owner stating that this is his intent.
"compiling" is just a performance hack. It doesn't change SPF results.
So as things stand now, and if my understanding of op=helo is correct, we
will keep the "helo=spf" option in our _auth records, as a convenience for
domain owners who publish SPF records and want us to use the same set of
addresses in their Registry record. I'm working now on a webtool that will
allow domain owners to experiment with their SPF records and see if they
compile as expected. See http://open-mail.org/webtool.html As always,
suggestions are welcome.
I really can't comment on your new protocol. I've spent a lot of time
understanding SPF thoroughly, and don't have any left over.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
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/?list_id=735