There seems to be a fair amount of discussion on this list about the
objectives and approach of the working group. I'd like to add some
thoughts to that discussion.
I think it's important to keep the experience of the end user - the
person who receives the mail - foremost in our minds in this working
group. You're probably aware that recent studies by the Pew Internet &
American Life Project
(http://www.pewinternet.org/reports/pdfs/PIP_Data_Memo_on_Spam.pdf)
point to a distressing trend; increasing numbers of email users are
becoming less confident and more uncomfortable using email because of
spam. Fully 29% have reduced their use of Internet email because of
spam. Whatever we do must help restore and sustain end users' confidence
in email.
With respect to the charter of this working group, in my opinion this
means we must focus our efforts at the From line of the message. That's
what the end user sees, so that must be our base case. End users don't
know there's a distinction between RFC2821 MAIL FROM values and RFC2822
From headers, nor should they. All they see is the From line. Users
don't know HELO or EHLO even exists, nor should they. They just see the
From line. Some clients will display two names on the From line in "sent
on behalf of" cases, and that's great. But for the vast majority of mail
received by the vast majority of users, there's one name on the From
line. As far as the user believes, that's who sent the message. And they
are entitled to that belief!
Let me repeat: the user is entitled to believe the name on the From line
is the person who sent the message.
That's the base case, and our work should therefore focus on providing
the greatest possible assurance to the user that the name they see on
the From line is in fact sender of the message. This doesn't preclude us
looking at other things. To be sure, there are times when the address on
the From line isn't the *real* sender. Yes, there are many special
cases. But let's start with the base case - one address on the From line
- and work our way from there.
To me, this implies two requirements for whatever proposal this working
group comes up with:
1. Whenever possible, we must validate the domain used on the From line
of the message, the RFC2822 From header to be precise. Because that's
what the user sees.
2. If we can't validate the domain of the From header, then we must
inform the user that we validated something else. The precise mechanism
for informing the user is probably outside the scope of our charter.
However, we have to make it *possible* to inform the user.
If we don't achieve these two things, then we will not succeed in
restoring users' confidence in email.
--
Harry Katz
Microsoft Corp.