Re: Who should set the Sender: header field?

--On Wednesday, December 15, 2021 10:14 -0500 John R Levine
<[email protected]> wrote:

>> I wonder how many of the 800 pound gorillas in the email
>> world still allow multiple addresses in the From: field - any
>> proposal for weird headers that get rejected by either Google
>> or Microsoft (rather than silently ignored and passed along)
>> is de facto DOA, no matter what the de jure status is.
> 
> Our forty year old mail systems have lots of ancient cruft
> that might have made sense on the tiny Internet where everyone
> knew each other, but not any more.  Just yesterday I was
> looking at the 251 and 551 SMTP codes which mean "this person
> has moved, here's the new address."
> 
> I can't get very upset that these ancient unused warts don't
> work any more.  Over in emailcore we are updating the specs
> and I think we should explicitly deprecate stuff that no
> longer (if ever) interoperates in practice.

Or at least clearly identify and, when appropriate, discourage.
For things that indeed used to interoperate/work in practice and
that were considered good practices, it is not clear to me that
it is worthwhile to encourage arguments about whether an
implementation that offers support for them --even if that
capability is configurable and off by default-- is actually
broken/buggy.   That would take us back into "if you don't like
it, call the protocol police" territory. 

I am also, fwiw, rather unsympathetic to arguments about what we
should do based on the 800 pound gorilla model.  If one accepts
the "anything they won't do is DOA", there is no point having
standards, or at least any standard rather than  "write down
what they are doing and just imitate it".  It discourages
innovation by anyone else, encourages concentration because
Gorilla1-Gorilla1 mail will often work better than other things,
even then Gorilla1-Gorilla2 mail, and would make us part of the
problem as regulators look at competitiveness and antitrust
issues.  

I agree with not getting upset (even a little) about this sort
of thing and with deprecating things that never really worked
from day one and/or that have become actively dangerous.   But,
for others, a clear warning that one should not be surprised if
they don't work and an accompanying explanation feels like the
better strategy.

best,
   john