Responses below, tagged 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 John
Gardiner Myers
Sent: Tuesday, April 06, 2004 6:33 PM
To: ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: User experience
Harry Katz wrote:
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.
I would disagree. We should focus on what can provide the most benefit
for reasonable cost. As DNS-based authorization of From: breaks list
expansion and since list expansion is important and widespread, the
deployment of DNS-based authorization of From: will be significantly
limited. This limited deployment significantly reduces the overall
benefit.
It may well be possible to address the list expansion issue or it may be
that the overall benefit is high enough despite limited deployment, but
that is not immediately evident.
HKATZ: I'm not suggesting that we focus *exclusively* on the From line.
My purpose here is to highlight that validating the From line ought to
be our base case because that's the identity the end user principally
sees. Yes, list expansion is one of those special cases where the 2822
From can't be validated. In this case, as the Caller ID spec proposes,
the Sender header should be examined. Most mailing list servers add a
Sender header identifying the list owner as the sender. (This list
we're on for example inserts "Sender:
owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org").
2. If we can't validate the domain of the From header, then we must
inform the user that we validated something else.
Again, I would disagree. The end user benefit of validating the
Return-Path is that the user receives significantly fewer bounces from
messages they never sent in the first place. The end user receives this
benefit without needing to be informed that any sort of validation has
taken place.
HKATZ: It is perfectly possible to reject a message at the end of DATA
and not generate a bounce message, exactly the same way you can reject
after MAIL FROM and not generate a bounce. Rejecting at end of DATA has
the benefit of allowing the MTA to examine the 2822 headers to make a
more accurate determination of the identity responsible for sending the
message.