On Sat, 11 Dec 2004, wayne wrote:
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.
Well, wasn't that an understatement :)
And you know, its not too late to fix that apparent oversight!
However, I think it is *WAY* too late to change things now for SPFv1.
That is where we differ. While use of SPF1 for MAIL-FROM has taken of,
I do not think the same is true about HELO.
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.
At the same time, this requires modifications to dns and mail servers as
well as multiple dns lookups if there is a desire of different HELO and
MAIL-FROM records. Its ugly to say the least and we should do it the
right way. But hey - you listed these problems below yourself:
* 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.
Its a matter that HELO record should be a lot simpler and can be done
in a way that requires at most one or two dns lookups all and so it
would be best to have separate document for HELO and its use with SPF.
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.
We have responsibility to come up with an effective standard solution.
If existing standard document is found to have certain problem when
its at DRAFT level, then it may not be advanced to full STANDARD and
may require new spec to be issued.
And I personally believe that SPF is not at the DRAFT or PROPOSED level
yet and we're just early at the EXPERIMENTAL stage. Technical specs often
change certain aspects of functionality when they move from EXPERIMENTAL
to STNADARD track - that is why there is why this is an EXPERIMENT - so
we could assess the problems and if necessary make changes.
* 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'm not surprised - but that only speeks for problems with marketing CSV.
But did you also make comparison to number of SPF records published
direct at domain level?
And not that it matters but perhaps couple of you can do practical test
and set exists for HELO as way to track down how much real use is there
really right now for HELO SPF checking. Would I be wrong to assume that
for every one HELO SPF test there are 10,000 MAIL-FROM SPF tests?
* 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.
In my view it should be treated same as if there was domain with no SPF
record published at all, which is certainly a lot lot lot more common
right now then cases of null MAIL FROM.
This HELO testing for null mail from is in my view early experimental
design for future Unified SPF with goal to have be able to see at leat
one authenticated session identity. This becomes important only when
we have situation of requirying use of authentication for all domains
and not accepting any mail without that and I do not think this is
going to be practical within next 2-3 years and as such we have more
then enough time to make necessary changes and I believe it is not
a big problem for implementors if they had to change and require
different version for HELO records or to require certain modifier.
* 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.)
SA3 is very new and we have good relationship with them and with Hector
as well (well, hopefully :), I think they will make changes if we ask
them. And in both cases they are using it as additional component of
their ranking system and not as the only solution for that space.
There is also no great urgency on fixing hello spoofing problem as it
does not cause bad bounces to you if your name is spoofed, nor is it
ever seriously seen by end-users as being source of email.
* The SPF wizard on spf.pobox.com has told you to create SPF records
at the HELO domain level.
Did it also ask if they know what HELO domain is and if user actually
knows what HELO name his software is using? :)
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net