Harry Katz wrote:
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").
Such addition of a Sender: header is not specified in the relevant
standard, RFC 2821 3.10.2. RFC 2821 3.10 has strong requirements
against modifying the header.
But if it is the From: header the user is going to principally see, then
if you verify any other identity in preference to From:, then you've
just created a hole for attackers to exploit.
I wrote:
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.
Harry Katz wrote:
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.
I agree with that statement, but I do not see how it is in any way
relevant or responsive to the previous conversation. I refuted your
claim that "if we can't validate the domain of the From: header, then we
must inform the user that we validated something else" by giving a
counterexample where it is not necessary to inform the user of anything.
When it is possible to do SMTP-level rejection of messages is a non
sequitur.