I'm not suggesting that we focus *exclusively* on the From line.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.
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@xxxxxxxxxxxx").
Again, I would disagree. The end user benefit of validating theHarry Katz wrote:
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.
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.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.