In <x4ekhyqj4x(_dot_)fsf(_at_)footbone(_dot_)midwestcs(_dot_)com> wayne
<wayne(_at_)schlitt(_dot_)net> writes:
In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0412091138090(_dot_)31092-100000(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
I'm working on updating updating the SPF I-D now, [...]
One of my core goals with the new I-D is to having it remain as
compatible as possible with previous SPF specs.
Again, I'm looking for justification of why the SPF checking policy of
draft-200406.txt and draft-schlitt-spf-00 should be changed. I've
read comments from quite a few people, but so far, I do not see the
justification to change the semantics of previous SPF specs.
If I was to design SPF's HELO checking today, I would do things much
differently. Maybe the removal of the scope= modifier from the earlier
SPF specs really was a mistake. However, I think it is *WAY* too late
to change things now for SPFv1.
SPFv1 can support HELO checking, if you are willing to put up with
some ugliness. It can do just about anything you want to do with HELO
verification.
* In most cases, MTAs give a subdomain to their email domain on the
HELO command. Therefore, you can easily publish separate policies
for legitimate HELO checking and MAIL FROM checking.
* the %{l} is always set to "postmaster" for HELO checking and can
be used to distinguish the scopes and to change the policy for
HELO checking.
* SPF HELO checking uses more DNS lookups than is absolutely needed,
but not so many more to make it impractical.
Furthermore
* SPF HELO checking has been in the spec for 18+ months.
* The SPF spec has, for all practical purposes, been frozen for 6+
months, and in many ways has been pretty slushy for 12+ months.
* I did a quick survey of HELO domains that have recently been used
to send email to me. In the tiny sample, I found more published
SPF records at the HELO domain level than there probably exist for
all CSV publishers in the world. I think we have a large enough
installed base of SPF records preclude incompatible changes.
* All SPF implementations that I know of will check the HELO domain
in cases of a null MAIL FROM. The install base of SPF
checkers is large enough to preclude incompatible changes to the
semantics of SPF records, including that all SPF records can and
will be checked using the HELO domain in at least some cases.
* There exists at least a couple of significant SPF implementations
that are already always checking the HELO domain, even when the
MAIL FROM is not null. (SpamAssassin 3.0, AOL, Hector's systems,
etc.)
* The SPF wizard on spf.pobox.com has told you to create SPF records
at the HELO domain level.
* Over the last year or so, many people have suggested that, as a
Receiver Policy, that when MTA servers (receivers) are doing HELO
checking, they should reject on SoftFail, or even on Neutral (but
not None).
-wayne