On Fri, 2004-07-02 at 21:42, wayne wrote:
In <603278271(_dot_)20040702123837(_at_)brandenburg(_dot_)com> Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> writes:
GC> Mechanically, CSV and SPF are both capable of checking HELO.
Mechanically, CSV and SPF are both fruit. But let me tell you, you do
not want to think about or use durian the same way you think about and
use oranges.
However, your statement highlights a deeper problem in most of the
efforts to discuss CSV and SPF differences: Such efforts are almost
entirely tied to mechanical and syntactic issues and do not focus on
underlying concepts.
CSV and SPF are fundamentally different pardigms.
CSV vets an MTA's traffic.
SPF vets an RFC2822 author/sender's message.
Dave:
You appear to be confusing SPF with Sender-ID. SPF vets the 2821.FROM
and the 2821.HELO. Sender-ID and Caller-ID vet the
2822.From:/Sender:/etc.
I posted the following messages as a direct reply to address your
confusion:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02494.html
Your continued confusing of Sender-ID with SPF is as bad as if people
confused your earlier proposals of DSAR/HNAA with CSV. Worse, it
appears that your confusing is creating problems for others.
I think much of this confusion comes from continuing reference to SPF+
which has yet to be defined. As such, there is no clear definition yet
as to what SPF _currently_ checks, so your distinctions are only
somewhat accurate, if at all. I agree that looking at the historical
documents of what SPF _had_ been checking and what Sender-ID _is_
checking is different, but as Sender-ID _is_ the current incarnation of
SPF, why are you making this distinction? Are you suggesting a desire
to abandon Sender-ID? This is confusing.
Now, since SPF-classic (see link above) doesn't have anything to do
with the 2822 information and *does* validate the HELO domain, most of
your message is, at best, irrelevant.
Here you are confused. The checking of the HELO domain by SPF-Classic
does not provide the same results as obtained by CSV. Looking at the
inputs and outputs alone fails to consider the _completely_ different
dataset involved. There was wisdom in Sender-ID dropping this
meaningless HELO check made by SPF-Classic. This continues to confuse
many others as well.
Granted, SPF-classic's validation of the HELO domain has not been
cited as a key feature of SPF, so this confusion is a little more
understandable. I did address it in this recent message:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02508.html
The goal of CSV is to establish a _single_ accountable entity for the
mail stream. the SPF-classic occasional validation of the HELO domain
was only to see if _any_ entity was accountable. Even if this check is
made every time, it still remains an entirely different (and
meaningless) check. The goal of SPF/Sender-ID was to flag some concept
of "from" as having been confirmed. The HELO domain provides a very
nebulous reference for such confirmation, and thus the wisdom excluding
this check. Reinstating this check would only continue this original
muddle. CSV is, was, and remains entirely orthogonal to SPF/Sender-ID.
-Doug