In <40955E2B(_dot_)4030208(_at_)elvey(_dot_)com> Matthew Elvey
<matthew(_at_)elvey(_dot_)com> writes:
MTA admins just need to ensure that they are sending appropriate HELO
strings, which nearly all already are, and create DNS records. Wow,
that's not a lot of systems that need touching, relatively speaking!
(Around 2 orders of magnitude fewer than SPF+SRS).
Maybe your experience is different, but in my experience, there is a
very significant number of legitimate mail servers that do not send a
valid HELO domain. This subject has come up several places, such as
the SPF list and SPAM-L, and from what I can tell, my experience
matches most others.
As Greg pointed out, the current SPF spec says that people can always
check the HELO domain and reject the connection if it fails. This is
a very small change in semantics from earlier specs, where the HELO
domain was only checked on an env-from of <>.
ALL the other proposals so far don't accomplish significantly more
than Crocker's CSV, and yet do impose significantly larger costs.
I disagree. I think that validating, when possible, the env-from and
the From: header are both significant accomplishments.
It's bloody hard to read! An intro that explains what it does
specifically but briefly in the real world would be great. (I'd be
happy to give it a shot.)
If by "it", you mean Dave's CSV proposal, I agree. I have found it
very hard to read and confusing. Part of it may be that I can't see
what it accomplishes that SPF doesn't and lose interest half way
through the doc.
Because CSV has a much lower implementation cost, it will get
implemented sooner.
Once tools and MTA updates have been created, almost all of the
proposals are equally easy for domain owners and mail admins to
implement.
-wayne