ietf-mxcomp
[Top] [All Lists]

Re: Differences between CSV and Sender-ID

2004-07-04 00:17:10

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>