In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0412111157590(_dot_)31092-100000(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
On Sat, 11 Dec 2004, wayne wrote:
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!
Well, the scope= modifier that was removed slightly over a year ago is
not the same as the support for scoping that people have been talking
about since then. It was functionally equivalent to the
"spf2.0/scope1,scope2,scope3" stuff in the MARID I-Ds with the
exception that you could only have one record.
Again, I wish I knew back in the spring of 2003 what I know today, and
I'm sure many other people involved in the developement of SPF feel
the same way.
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.
As far as designated sender systems go, SPF HELO checking lags only
SPF MAILFROM checking and SPF HELO checking almost certainly is used
more than all other (non-SPF) designated sender systems combined.
Yes, the fact that SPF folks generally stopped harping on the fact
that SPF does HELO checking after MARID switch to 2822 identities,
while the CSV folks continued to say "we need HELO checking with CSV"
has lead many people to believe that SPF doesn't do HELO checking. We
need to educate people.
There are simply too many deployed SPF implementations that are
checking the HELO domain to easily change things now.
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.
Actually, I strongly disagree that SPF is at the Experimental level of
standardization, at least according to the requirements in RFC2026.
SPF, as of before MARID started, satisfied most of the requirements of
the Draft level of RFC standardization. SPF already has more
deployment than deployment and and implementations than many (most?)
Proposed level RFCs.
* 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.
I think there are more problems with CSV than just marketing. In
particular, they lack working code, they lack CSV wizards and their
abuse of SRV records makes creating and reading CSV published SRV
records very hard.
On the contrary, the CSV folks have had *far* more marketing and hype
than SPF HELO checking had at an equivalent stage of development
(e.g. a year ago).
But did you also make comparison to number of SPF records published
direct at domain level?
No, I didn't, but it is hard to compare. The list of HELO domains is
a list of what I found used, which includes a great deal of forged and
bogus HELO domains. The lists of MAIL FROM domains has generally been
list that were intended to be valid. Obviously, there will be a far
smaller percentage of SPF records at forged and bogus domains.
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?
Considering the deployment of SpamAssassin 3.0 and the number of null
MAIL FROMs, I would guess that ration is far too high. It wouldn't
surprise me if the number was under 100 SPF MAIL FROM checks to 1 SPF
HELO check.
I have set up a tracking exists:%{l}._spf.%{d} to see. I would
encourage others to collect data via similar methods.
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.
I can't see how you could consider this to be early experiemental
design when the fallback to the HELO domain was in the oldest SPF spec
that I can find (Jun 2003).
-wayne