26

When sending an e-mail, is there anything in the sending/receiving protocols that guarantees, or is supposed to guarantee, that anyone receiving the e-mail will see the lists of recipients in the To and Cc fields in the same order as how the sender inputs them? This is quite a simple and basic question, really, but seemingly impossible to find an answer to on Google, which only wants to lecture me on the workplace etiquette of the order in which you should CC your bosses.

This old question mentions that the same e-mail can show recipients in different orders on different clients, which could indicate that there is nothing in the various e-mail protocols meant to guarantee that the original ordering is maintained everywhere (and, thus, that it doesn’t matter what order you CC your bosses, because you can’t control what order they see it anyway) – or it could just be a software bug in an e-mail client.

So what do the actual protocols and standards say (in reasonably human-friendly terms, please)? Are mail clients free to present recipients (as well as CC-recipients) in any order they fancy, or are they supposed to take the order the sender types them in as law and stick to that?

 

 

Update

As Tonny and R.. Github point out in their answers, the actual SMTP protocol is of course just that – a protocol to transfer information. As such, it doesn’t really care about the contents of the data it transfers, just like HTTP doesn’t care about the HTML contents it’s transferring. So the answer to whether the actual protocol itself guarantees anything is clearly no.

In the parallel(ish) case of HTTP and HTML, there is another layer to the whole transfer, separate from the HTTP protocol itself: W3C standards that dictate how a user agent (= browser) must present the actual contents to the user; UAs not conforming to these are non-compliant. Even in these standards, though, some things are left entirely up to UAs, and there is no guarantee that a particular something is presented in a particular way.

When referring to ‘protocols’ above, my intention was to also include standards like these – anything that governs what happens between the sender hitting ‘Send’ in their MUA and a recipient seeing the e-mail in their MUA.

As anyone who’s ever dabbled with HTML e-mail knows, such standards clearly do not exist for e-mail message body content (or if they do, they are utterly flouted by MUAs). But recipients are not part of the actual body of the message, so their presentation to the user could well be governed by entirely different standards.

So beyond just the actual SMTP protocol itself, what I am really wondering is whether there are any standards/stipulations at all that govern how recipients are treated and presented by MUAs to the user. That is:

  • Is the sending MUA free to reorder the content shown in the To: and CC: fields in the UI before generating headers and initiating the SMTP connection?
  • Is the receiving MUA free to generate the list of (CC-)recipients for the UI any way it pleases, and order it any way it wants to?
  • Or is there some sort of ‘law’ that stipulates that MUAs are not free to do this in order to maintain compliance?
Janus Bahs Jacquet
  • 464
  • 5
  • 16
  • 3
    Point of order: no one will see the BCC line so there is no order to be preserved. – Darren Oct 06 '21 at 06:28
  • @Darren Good point! – Janus Bahs Jacquet Oct 06 '21 at 07:16
  • @Darren I seem to recall that theoretically, each person in BCC was meant to get their own copy of the email, in which they can see their own name only. In practice, you're right, and I'm not aware if any MUA or MTA implements what I seem to recall reading was the original intention. – gerrit Oct 06 '21 at 09:28
  • I believe MUAs can alter headers. I think Microsoft Exchange can change the From: header from an SMTP alias to the primary SMTP address of the user, if they are doing authenticated SMTP relay. I don't know whether other headers can be affected. – Neil Oct 06 '21 at 11:55
  • MUA displays are not standardised. So there is no guarantee what the MUA will display. – Ben Oct 06 '21 at 17:52
  • Some MUA let you see the "original" email without rendering, which should show the Headers exactly as they were sent. But this is not the default view for any client I've used, and so shouldn't be relied on in practice. – Tiberia Oct 07 '21 at 15:40

4 Answers4

29

Yes, unless some party involved in the delivery is doing fishy things.

The original content of the header fields in an email message comes from the sender's MUA (mail user agent, i.e. mail software). It's technically possible for an intermediary system handling the mail to modify them, but that's against expectations if not against formal protocol standards, and further, if DKIM is involved, doing it at any stage after the outgoing site's mail system has signed the headers with the DKIM keys would make the signature mismatch. Normally, intermediary systems handling forwarding of your message will prepend headers (Received:, DKIM signatures, spam likelihood scores, etc.) to the message, not modify the existing ones.

Note that the To: and Cc: headers in an email message are purely informative; they are not part of the mechanism for how the mail gets delivered to the correct party. Rather, when your MUA submits the mail via SMTP to your mail provider's submission port, the RCPT TO command(s) specify the addresses it should be delivered to. The MUA normally derives these from the headers, but doesn't have to (and in the case of Bcc:, the header they're derived from was stripped before being sent).

To address the Update to the question: I'm not aware of any "laws" governing what MUAs must do, and even if there were, the extent to which many popular existing ones violate normal expectations/etiquette (for example, hiding email addresses and only showing unauthenticated names, badly reflowing text, etc.) leads me to say you couldn't trust them to follow such "laws" anyway. If you want to know if a particular sender's MUA may have ordered the recipients differently from how the sender wrote/selected them, or if a particular recipient's MUA may have presented them different from their order in the message, you really need to know what particular software they're using and examine that software's behavior.

For what it's worth, I don't recall ever having seen such reordering, but I've only used/observed a very small number of MUAs out of all the ones out there, so it's possible that some so reorder things.

R.. GitHub STOP HELPING ICE
  • 1,901
  • 1
  • 16
  • 25
  • 2
    I was about to answer mentioning DKIM requiring all headers to remain unchanged +1 – coagmano Oct 06 '21 at 04:47
  • 3
    Good answer: Most people don't realise that the To/CC/BCC fields are just content and not part of SMTP. – Oscar Bravo Oct 06 '21 at 06:46
  • 3
    I suppose my question then is whether there’s any standard that stipulates that the receiving MUA must display recipients and CC recipients in the reader’s UI in the same order they appear in the headers (or wherever else it’s taking them from)? They must do all kinds of processing on them anyway, to separate them into neat little UI boxes, add names if the address is in the user’s contact list, etc., so reordering them wouldn’t seem an impossible thing. Or, I suppose, even the sending MUA when doing the reverse and turning the input list into headers and whatnot. – Janus Bahs Jacquet Oct 06 '21 at 07:22
  • @JanusBahsJacquet: How the receiving user's MUA presents data is purely a presentation matter, so it could show them in a different order if it wants. I have not seen this done but there are far more MUAs than I've looked at, so it's plausible that at least one does so. You might want to ask about a particular one. Also, any decent MUA should have an option to look at the raw mail including headers in case a user wants to bypass such presentation layer confusion. – R.. GitHub STOP HELPING ICE Oct 06 '21 at 12:37
  • @R..GitHubSTOPHELPINGICE It’s not really a matter of which MUAs actually do it, but more whether there’s any part of the e-mail transaction that specifies that they _shouldn’t_. The question sprang from someone tweeting that they’d been chewed out at work for not ordering CC recipients in an office e-mail in decreasing order of seniority, and I wondered whether anyone can really be sure they’re seeing the same order as she had when composing the e-mail. – Janus Bahs Jacquet Oct 06 '21 at 14:01
  • 4
    @JanusBahsJacquet There's no specification of how email is displayed at all. – Barmar Oct 06 '21 at 14:51
  • 1
    @JanusBahsJacquet: In that case you just need to know what email software they're using (probably Exchange) and whether it does anything weird. Even if there were ~rules~, there's no reason particular software couldn't be breaking them. – R.. GitHub STOP HELPING ICE Oct 06 '21 at 15:50
  • @R..GitHubSTOPHELPINGICE If you add an extra section to your answer addressing this aspect (the bit in the _Update_ edited into the question after your answer was first made), I’ll accept this as the correct answer. – Janus Bahs Jacquet Oct 07 '21 at 08:07
  • @JanusBahsJacquet: How is the latest edit? – R.. GitHub STOP HELPING ICE Oct 07 '21 at 12:17
  • @R..GitHubSTOPHELPINGICE Perfect – answer accepted! The upshot is then pretty much what I figured it would be: there’s nothing specific to prevent recipients from appearing in a different order from how they were entered by the sender, but there’s also no reason for it, so all things being equal, they will _probably_ appear in their original order. – Janus Bahs Jacquet Oct 07 '21 at 20:01
  • 1
    Time to write an email client that shuffles the to/cc addresses. – Ellesedil Oct 07 '21 at 21:03
  • @Ellesedil I think a client that *sorts* them would be more realistic. – Medinoc Oct 08 '21 at 12:18
6

It has been a few years that I went through the SMTP protocol specification, but as far as I can remember there is NOTHING in there that prescribes maintaining that order.
To my knowledge the SMTP protocol ONLY prescribes the message format and mandatory and optional fields within that format. It does give some guidance on the order in which mandatory fields are to be send, but for fields with multiple values (like the recipients) it only says how those fields should be formatted. It doesn't say that the order of multiple values within that field is important or should be preserved.

And any mail-server/relay that receives and forwards an email is free to temporary store that email before sending it on in whatever format it pleases and reconstruct the SMTP message as needed when transmitting it further.
If it does any sort of sorting on the list of recipients that may change the order. And the sending and receiving mail-clients may deal with this however tehy like as well.
The sending client can re-order what you typed before creating the SMTP message and the receiving mail-client can re-arrange on receival before showing it to you.

The send/receive protocol has nothing to do with all that.
It is just concerned with a properly formatted SMTP mesage.
It isn't the protocols job to care about what the application layer above it does with the message.

Bob
  • 60,938
  • 25
  • 191
  • 216
Tonny
  • 29,601
  • 7
  • 52
  • 84
  • Thanks for that – I suspected there likely wouldn’t be. Makes sense that of course the protocol itself doesn’t care about order as long as the headers and message are all well-formatted. (I take it you mean _prescribe_ rather than _proscribe_.) – Janus Bahs Jacquet Oct 05 '21 at 22:26
  • 2
    I think you mean "prescribes" (="says you must") rather than "proscribes" (="forbids")? – psmears Oct 06 '21 at 09:28
  • Oopsy. Prescribe of course :-) I'm not a native speaker and that shows sometimes. occasion. – Tonny Oct 06 '21 at 13:51
  • Any mail-server/relay that "reconstructs" the headers without preserving them exactly is essentially unusable on modern internet due to header signing at the origin, and thus the whole thing is semi-moot in modern practice. In practice, mail transport agents must preserve existing headers unchanged whenever the header integrity is being enforced. MUAs can always do whatever they want, unfortunately. – Kuba hasn't forgotten Monica Oct 07 '21 at 16:45
4

Is the sending MUA free to reorder the content shown in the To: and CC: fields in the UI before generating headers and initiating the SMTP connection?

There is no specification that states the MUA must preserve order. Contrariwise, there are suggestions that the MUA should sort by domain name to make delivery more efficient, similar to how post offices sort mail by postal code before sorting by address. Of course, intelligent implementations of SMTP are likely to do this anyways for efficiency purposes, but early recommendations was to have the MUA do this to "help" the server be more efficient.

Is the receiving MUA free to generate the list of (CC-)recipients for the UI any way it pleases, and order it any way it wants to? Or is there some sort of ‘law’ that stipulates that MUAs are not free to do this in order to maintain compliance?

There's no specification for what a MUA looks like. Of course, with decades of experience, most MUAs are mostly homogenous at this point, so the de facto standard would be to do what everyone else appears to be doing, and that is to not sort To and CC fields. Of course, since there's no specification, there's no reason why a MUA couldn't do something else, either by default, or as a toggle option, such as sorting by domain, by local name, by both, or by the display name, etc.

phyrfox
  • 2,983
  • 19
  • 16
  • 3
    "but early recommendations was to have the MUA do this to "help" the server be more efficient" <-- this is in regards to the order of `RCPT TO` commands in the SMTP transaction, not the headers in the `DATA` payload. – R.. GitHub STOP HELPING ICE Oct 06 '21 at 15:46
  • @R..GitHubSTOPHELPINGICE touche. It's been a while since I've manually sent emails via Telnet. Still, one could imagine that a MUA engineer would sort the TO field to match the RCPT TO field for whatever reason. – phyrfox Oct 06 '21 at 15:59
1

BCC is not part of the transmitted email so its order is not visible to recipients.

To: and CC: are email headers and so are not usually mutable, so they will have the same content (including same addresses, same order, and same names) for the sender and all recipients of the email.

SMTP itself deals with a list of recipients that is entirely separate to CC: and To: but most mail user agent make the list be the union of To: CC: and BCC: (the latter being stripped by the MUA.)

MUAs are free to hide, mangle or obfuscate this information in any way they see fit.

Jasen
  • 1,516
  • 10
  • 10
  • The headers themselves may be immutable, but what MUAs show to the user is not the same as the headers. For one thing, UIs generally only show a recipient’s real-world name if available, hiding the actual e-mail address in a context menu. This goes both for recipients given as `Real Name ` in the headers, but also for people whose e-mail is saved in the user’s contacts. According to Tonny’s answer, MUAs generally don’t even use the headers to generate the list shown to the user. (I added an update to the question to clarify my meaning, and removed references to Bcc.) – Janus Bahs Jacquet Oct 06 '21 at 09:58