Replies below, prefixes with HKATZ:.
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of wayne
Sent: Tuesday, April 06, 2004 10:59 AM
To: IETF MXCOMP
Subject: Re: User experience
In <9156B81DAA29204989AD43E88688FAAB01373697(_at_)df-lassie(_dot_)dogfood>
"Harry
Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
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.
There was, in my opinion, a very producive discussion about which
identities to deal with yesterday on the marid jabbers session. I found
it somewhat ironic that MicroSoft's position had to be presented by Meng
Weng Wong.
If you have not had a chance to review it, please take a look at:
http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org/2004-04-05.html
HKATZ: Thanks for forwarding the link. Sorry I missed this chat. I'll
do my best to participate in the next one. Meng, I appreciate the
honorable mentions.
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.
I strongly disagree. The charter is open as to what parts of the
message to focus on and how to do it. That is what we have been
discussing for the last month or so.
HKATZ: Understood. I'm just stating my opinion that the focus or
priority ought to be on the From line. Reading through yesterday's
Jabber log it seems the participants wanted to tackle identities in this
order: HELO/EHLO, RFC2821 MAIL FROM, RFC2822 headers. IMHO this is
exactly backwards. I agree there may be some merit in validating the
MTA by checking its HELO/EHLO domain as Dave Crocker is proposing.
However, I'm not convinced this provides sufficient additional value to
be worth the effort. I'm highly dubious about the utility of checking
the MAIL FROM especially in isolation of the 2822 headers. And as I've
said earlier, I think we need to keep the experience of the end user as
a core focus of our work.
Let me repeat: the user is entitled to believe the name on the From
line is the person who sent the message.
I think few will dispute this, nor do I think that many will dispute
that the RFC2822 From:/Sender: headers are very important.
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.
I am very concerned with, as you say, the many special cases of dealing
with the RFC2822 data. While working code is not required at this stage
of RFC development, it is certainly very helpful in trying to get a
grasp on the whole problem and learning about subtle, but critical
details.
Do you have any working code that validates the RFC2822 that we can look
at, test, analyze and collect data with? I realize that the C-ID doc on
the microsoft website has an algorithm outline, but that would require a
lot of work to turn into working code.
If you can't provide working code, can you provide data and your own
analysis of the situation?
HKATZ: We're working on the code. The analysis is in section 3.2 of the
Caller ID spec.
-wayne