Subject: [ietf-smtp] Who should set the Sender: header field?

From: Alessandro Vesely <[email-masked]>
Date: Mon, 13 Dec 2021 10:24:44 +0100

Hi all,

using Thunderbird, for one, it is easy to modify the From: field of the message 
being edited, possibly setting multiple mailboxes.  However, that software 
omits to add a Sender: field, which is required in such cases.  Where's the 
bug?  Options are:

* The MUA should prompt for a Sender:, or

* the submission server adds Sender according to the logged-in identity.

I realize that both might take care of that, but where should I file a bug first?

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2021 14:24:52 -0500

>* The MUA should prompt for a Sender:, or

How very annoying for the 99% of cases where the sender would be
redundant with the from.

>* the submission server adds Sender according to the logged-in identity.

Sorry, but submission servers are not the source of truth for someone's "real"
email address, much less their identity.  I have hundreds of e-mail addresses.
All of them are me, and I would not appreciate some piece of software picking
one arbitrarily and adding a sender header to my mail.  

On my system, the submission server puts the submission account, which
is not necessarily an email address, in the Received header in case
there is some need to figure out where a message came from.

>I realize that both might take care of that, but where should I file a bug first?

Nowhere, please.  If for some reason you want to add a sender header, there are
plugins like Header Tools which let you do so.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Dec 2021 10:27:20 +0100

> How very annoying for the 99% of cases where the sender would be

Of course, I meant only in case the user added multiple mailboxes to From:. 
RFC 5322 requires that a Sender: field be there in such cases.

> one arbitrarily and adding a sender header to my mail.

Agreed.  Perhaps there should be a per-user configuration option to tell the 
preferred Sender: to be set when it's missing and required.  Otherwise, picking 
the first compatible mailbox of From: could be a good default.

> there is some need to figure out where a message came from.

On mine, I obscure the Received:'s AUTH token to prevent leaking such info.

> plugins like Header Tools which let you do so.

So you point to the client...

However, I only found a "Header Tools Lite" for Thunderbird, which seems to be 
designed to change the header of /received/ messages, not outgoing ones.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 14 Dec 2021 09:29:42 -0500

> RFC 5322 requires that a Sender: field be there in such cases.

But we know that nobody uses multiple mailboxes, and if they tried, in 
most cases it would be rejected or discarded by the recipient mail system.

Can we please not waste any more time on this.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Wed, 15 Dec 2021 00:15:50 -0500

> RFC 5322 requires that a Sender: field be there in such cases.

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.

No, I'm not thrilled by this situation, but here we are anyhow.

Which gets me wondering - what *other* "still officially legal but not usable
except in small private conclaves" features are still out there? I know
that nmh/exmh dropped message/partial support because nobody seems
to be using it in the wild...

---

From: "John R Levine" <[email-masked]>
Date: 15 Dec 2021 10:14:30 -0500

> 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.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Dec 2021 11:34:15 -0500

--On Wednesday, December 15, 2021 10:14 -0500 John R Levine
<[email-masked]> 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

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 16 Dec 2021 10:30:26 +0100

On Wed 15/Dec/2021 17:34:15 +0100 John C Klensin wrote:
> what they are doing and just imitate it".

Back to the subject topic, based on what one of those 800 pound G. wrote, it 
turns out that rejecting mail where multiple authorship is expressed by 
multiple From: mailboxes was introduced as a requirement to implement RFC 7489. 
  I didn't notice it until a few days ago.

These days, both RFC 7489 and RFC 5322 are being rewritten.  Yet, the sentiment 
of the community who rewrites them seems to be that since that feature is 
seldom used, it is a waste of time to consider it.  Such a schizophrenic stance 
leads to inconsistent standards.

Best
Ale
--

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 16 Dec 2021 14:11:20 +0100

On Thursday 16 December 2021 10:30:26 CET, Alessandro Vesely wrote:
> These days, both RFC 7489 and RFC 5322 are being rewritten.  
> Yet, the sentiment of the community who rewrites them seems to 
> be that since that feature is seldom used, it is a waste of time 
> to consider it.  Such a schizophrenic stance leads to 
> inconsistent standards.

The people who wrote RFC 7489 in 2015 think it's not used, the people who 
wrote RFC 822 in 1982 thought it was used, the people who updated 822 
didn't see enough reason to break compatbility. None of that is well 
described as schizophrenic. Please drop the hyperbole.

The hyperbole makes it difficult to see a real argument, if there is any.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Dec 2021 20:57:42 -0500

--On Thursday, December 16, 2021 10:30 +0100 Alessandro Vesely
<[email-masked]> wrote:

>> 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".
> 
> 
> Back to the subject topic, based on what one of those 800
> pound G. wrote, it turns out that rejecting mail where
> multiple authorship is expressed by multiple From: mailboxes
> was introduced as a requirement to implement RFC 7489.   I
> didn't notice it until a few days ago.

In a way, that is the point I was trying to make. I hope the
revision efforts will sort out at least some of the issues, but,
when a small cluster of large providers can announce that there
is a new way of doing things that they are going to use and to
which everyone else just needs to adjust, there is a problem.
When that new way of doing things will break the multiple From
option, mess up mailing lists (although people are welcome to
use their various group and social network services instead),
create privacy problems because individual replies to group
postings more or less have to go back through the servers of
whomever is maintaining a mailing list, etc., the problem is
magnified.   Well, I hope I'm not the only one who finds that
troubling.

At the same time, if we are going to continue to think about
Internet email in terms of standards, I think we need to push
ahead, try to figure out what The Right Thing is, and do/
specify it. I hope that members of the gorilla family will
participate in that process in good faith and under the
assumption that the results of a collaborative and open process
will, in the long run, be better for the Internet and for them.
One corollary to that is that, in trying to define standards,
"the gorillas are doing it therefore we have to go along" should
probably not carry much weight.

best,
   john

> be that since that feature is seldom used, it is a waste of
> time to consider it.  Such a schizophrenic stance leads to
> inconsistent standards.

---

From: "John R Levine" <[email-masked]>
Date: 16 Dec 2021 21:30:37 -0500

On Thu, 16 Dec 2021, John C Klensin wrote:
> use their various group and social network services instead), ...

I'm with you on mailing lists, but the support for multiple From is spotty 
even outside of gorilla land.  I sent myself a message with a two-address 
>From header and found that the mail app on my Samsung phone and Apples 
iPad mail showed only the first address, Apple mail and Thunderbird on a 
Mac showed both.

I'm not sure what to say about it but we are doing people no favors by 
suggesting that mail with multiple from address is likely to work.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Dec 2021 22:10:43 -0500

--On Thursday, December 16, 2021 21:30 -0500 John R Levine
<[email-masked]> wrote:

>> ...
> I'm with you on mailing lists, but the support for multiple
> From is spotty even outside of gorilla land.  I sent myself a
> message with a two-address From header and found that the mail
> app on my Samsung phone and Apples iPad mail showed only the
> first address, Apple mail and Thunderbird on a Mac showed both.
> 
> I'm not sure what to say about it but we are doing people no
> favors by suggesting that mail with multiple from address is
> likely to work.

I would favor a statement in the proposed A/S about this (or any
similar feature) warning people that the feature is not widely
supported, that it cannot be expected to work universally in an
interoperable way, may result in mail being bounced and/or lost,
and hence should probably be avoided unless the sender knows it
will be handled properly at the recipient end.  I'd be hesitant
about removing the construction from 5322bis entirely, but could
be convinced.

The _only_ thing is would object to is arguing that the standard
must be changed because one or several perceived large Gorillas
have decided to not support it.

  best,
   john

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 17 Dec 2021 13:18:50 +0100

On Fri 17/Dec/2021 04:10:43 +0100 John C Klensin wrote:
> --On Thursday, December 16, 2021 21:30 -0500 John R Levine wrote:
>> From is spotty even outside of gorilla land.
>> 
> The _only_ thing I would object to is arguing that the standard

Since G say they banned multi-mailbox From: after DMARC (with no statement 
about how/if it worked before), perhaps if we rewrite DMARC so as to not 
preclude the authentication of that kind of messages, they might eventually 
restore the functionality.  Authenticating the sender of a multi-mailbox From: 
message does not suggest that its end-to-end flow is likely to work, but 
neither denies it.

Best
Ale
--

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 Dec 2021 09:17:21 -0500

--On Friday, December 17, 2021 13:18 +0100 Alessandro Vesely
<[email-masked]> wrote:

>> I would favor a statement in the proposed A/S about this (or
>> any similar feature) warning people that the feature is not
>> widely supported, that it cannot be expected to work
>> universally in an interoperable way, may result in mail being
>> bounced and/or lost, and hence should probably be avoided
>> unless the sender knows it will be handled properly at the
>> recipient end.  I'd be hesitant about removing the
>> construction from 5322bis entirely, but could be convinced.
>...

> Since G say they banned multi-mailbox From: after DMARC (with
> no statement about how/if it worked before), perhaps if we
> rewrite DMARC so as to not preclude the authentication of that
> kind of messages, they might eventually restore the
> functionality.  Authenticating the sender of a multi-mailbox
> From: message does not suggest that its end-to-end flow is
> likely to work, but neither denies it.

Please take that comment/ suggestion to the DMARC WG [1].  At
least IMO, discussion on this list is not likely to be helpful
in shaping DMARC/ARC.

    john

[1] https://datatracker.ietf.org/wg/dmarc/

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Dec 2021 18:01:46 -0500

On 12/15/21 10:14 AM, John R Levine wrote:

> Over in emailcore we are updating the specs and I think we should 

Except for cases where interoperability is infeasible, I emphatically 
disagree.  The 800-lb gorillas have made email into a disaster in 
numerous ways, and should not be presumed to be the source of truth or 
rightness for email.

Keith