ietf-mxcomp
[Top] [All Lists]

Re: (DEPLOY) In Support of Sender ID

2004-09-02 13:30:24

On Thu, 2004-09-02 at 12:51, Rand Wacker wrote:
On Thu, 2 Sep 2004, Kevin Peuhkurinen wrote:

This is the most troubling issue that I forsee, I agree. However, I have
to wonder why everyone who is pro-Sender-ID doesn't feel it necessary to
try to pressure Microsoft into adopting SPF instead. To my mind, there
are ZERO hinderences to Microsoft adopting SPF, but there are plenty of
hinderences for most everyone else to adopt the encumbered Sender-ID.

^Microsoft^the Internet at large

SPF and Sender ID solve different problems.  Sender ID authenticates the
message, SPF authenticates the channel.  While channel authentication is
useful for some purposes, message-based authentication of something the
end-user can see is much more desirable to many senders and recipients to
control spoofing of user-visible headers.

In that regards, the Sender ID technology presents the best IP-based
message authentication I have seen, and can provide an immediate benefit
to a large majority of message paths.  In the long run, a crypto-based
solution for message authentication is of course the best solution, and we
are all working on those as well.

When we start discussing channel authentication then we should compare SPF
and CSV, but SPF doesn't solve the immediate problems of header spoofing
that I want to address right now.

I have introduced the MPR draft to illustrate how to arrive at either
the SPF level of RFC2821 MAIL FROM as well as the RFC2822 From building
upon the CSV standard.  This also overcomes problems of the
indeterminate DNS overhead, replication of DNS addresses, "open" lists
creating spam exploits, and removes an ability to hide listing by way of
macros.  One fundamental difference is the treatment of reputation as a
separate function from that of mailbox domain to outbound server
association.

-Doug