--- Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
Sender is so widely misused in practice that you really need to define a
new field for this, or better yet, just define a new one that has
So let me get this right. Because the semantics of From:, Sender:,
Resent-From:, Reply-To: 2821.MailFrom, List-ID: overlap, are ill-defined, and
often ill-implemented, your solution is to introduce yet another field that
will magically clear the whole mess up even though all previous attempts in
this direction seem to have failed?
It strikes me that the "let's introduce another identity field" brigade has had
plenty of time to prove its merits and the outcome over the last decade or so,
is less than stellar. The confusion over Sender: is a perfect example of that.
How about the alternative of deprecating fields that have resulted in this
misuse you allude to? After all, a lot of these fields were invented in a
relative vacuum compared to actual usage, so what's the harm in saying "we
guessed these header variations might be useful, but maybe we got it wrong"?
ietf-dkim mailing list