Folks,
(what follows does distinguish between Doug's comments and the ones he
was responding to, just in case anyone wonders...)
SPF vets an RFC2822 author/sender's message.
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
DO> I think much of this confusion comes from continuing reference to SPF+
DO> which has yet to be defined.
My assessment was based on draft-ietf-marid-core. I don't care what
acronym is used.
I was fairly careful in the statement that is quoted at the beginning
of this message, because it applies to all of the *SPF* and *-id
proposals as they have been described.
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.
SPF Classic has/had everything in the world to do with RFC2822
information, because it is the RFC2822.Sender that sets the
RFC2821.MailFrom header.
DO> The checking of the HELO domain by SPF-Classic
DO> does not provide the same results as obtained by CSV. Looking at the
DO> inputs and outputs alone fails to consider the _completely_ different
DO> dataset involved.
right.
DO> The goal of CSV is to establish a _single_ accountable entity for the
DO> mail stream. the SPF-classic occasional validation of the HELO domain
DO> was only to see if _any_ entity was accountable.
this is a rather interesting point that I had not previously
appreciated. thanks!
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>