On 6/20/04 9:19 PM, wayne sent forth electrons to convey:
In <40D6274F(_dot_)8070201(_at_)elvey(_dot_)com> Matthew Elvey
<matthew(_at_)elvey(_dot_)com> writes:
SPF
already required that the HELO be valid, so the change from saying
that it MAY be checked to it MUST be checked is not an issue, [...]
I think you are misunderstanding what SPF and the "unified" SPF
require. In both cases, the suggestion is that you should reject HELO
domains that fail, but invalid HELO domains, such as IP addresses,
unqualified domain names, etc., would be passed on to the next check.
For more on my reading, see my reply to Scott, e.g. the link to the
slide. Some HELO checks would result in a pass, some in a fail, some in
a deferral to a check of the next identity.
A HELO domain that passes can be checked to see if it is whitelisted.
If it is, then the other checks may be skipped.
A mailing list post with a forged From proved a point rather well: No
proposal with an I-D listed in the MARID charter would have completely
prevented the forgery from making it to the list.
That's not true. SPF would have prevented that email from getting to
the list. What SPF wouldn't have done is prevent the From: header
from claiming to be from Harry Katz.
Right. That's what I meant to say it wouldn't prevent.
But then, neither would have any
other proposal, including Caller-ID. This is one of the things I
dislike about Caller-ID and the merged SPF/Caller-ID: it doesn't
protect the From: header.
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).
I do not think that "nearly all" HELO strings are correct, far from
it.
I think the vast majority of the HELO strings sent by untrusted client
are correct. Helo strings from MUAs and other trusted clients are often
not valid FQDNs. That is what I'm saying. FRDNS (Forward and reverse
DNS) checks of many antispam systems have been forcing this vast
majority into compliance.
Initially, I was pushing for CSV mainly because it checked HELO, and I
had strongly felt ideas about why a HELO check was the best thing to
check.
The above is a rephrasing of this post:
http://www.imc.org/ietf-mxcomp/mail-archive/msg01175.html and this post:
I may have missed something here, but I think my response to this
message still stands unchanged. See:
http://www.imc.org/ietf-mxcomp/mail-archive/msg01178.html
Your statement,
Once tools and MTA updates have been created, almost all of the
proposals are equally easy for domain owners and mail admins to
implement.
Is indefensible; it simply ignores the refutation in my argument. And
it ignores the work that SPF requires of end users.
You also ignore my argument for why with HELO checks, SPF can protect
From better than it can without 'em.