On Thu, 2 Sep 2004 12:51:15 -0700 (PDT), Rand Wacker
<rand(_at_)sendmail(_dot_)com> wrote:
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.
I agree that SPF and Sender ID solve slightly different problems, but
saying one authenticates the channel and the other the message is a
bit of a simplification. (If anything, domain keys actually
authenticates the message.)
It's not any easier for the end-user to see one than the other. In
one case, the MUA has to extract the envelope sender from the
SPF-Received header, in the other case, the MUA has to select one of
the From, Sender, Resent-From, or Resent-Sender headers to highlight.
Patent claims aside, neither seems particularly hard to implement in
an MUA. But that issue is somewhat irrelevant, because last I checked
the M in MARID stands for MTA and the charter says, "The primary
current use case for this facility is to allow recipient MTAs to
confirm that peer MTAs' actions are authorized by specific domains or
networks." Sure, if the MTA can determine this, it can and should let
the end user know, but the main point here is not end users.
What I'd really like to hear about is an actual usage scenario in
which a message author (say a bank sending out statements) actually
requires Sender ID, and could not get the same effect with
SPF-classic. Basically there are outsourcing scenarios where in
Sender ID you have to publish a TXT record in DNS, and with
SPF-classic you either have to publish a CNAME or a TXT and MX record.
But so what? The mechanisms are different, but the effects are the
same.
David