I learned that both the FROM address and the TO address is repeated in a hidden element called the “envelope”, and then repeated again in the “body”.
- Why isn’t the envelope data copied into the “header”?
- Why does this duplication exist, why couldn’t the necessary features be embedded into the message itself?
- Do all (non-SMTP) message transports do this?
- What alternatives to SMTP are there? (so I can better understand the reasoning)
The addresses in an email message header serve different purposes than the envelope sender and recipient (which really aren’t hidden per se, they just aren’t part of the message).
The envelope sender and recipient, which you never see in a message, are part of the SMTP protocol, and specify delivery instructions, that is, to which mailbox the mail server is expected to deliver the message, or where to return it in case of some failure. Neither address is required to have any relation to the semantic content of the message. These are explained in detail in RFC 5321 sections 184.108.40.206 and 220.127.116.11.
Logically these are analogous to the addresses printed on the envelope of a piece of postal mail.
The originator and destination addresses which appear in the message itself indicate semantic meanings, rather than explicit delivery instructions. These are explained in detail in RFC 5322 section 3.6.3 and RFC 6854 section 2.1 (which obsoletes RFC 5322 section 3.6.2).
In brief, From: in the message indicates the mailbox of whoever wrote the message, Sender: indicates the entity which sent a message on behalf of someone else, and To: and Cc: indicate the intended recipient mailbox. The RFCs define other header fields you may be interested in, as well.
Logically these are analogous to the addresses printed on the correspondence inside a piece of postal mail.
Often, the envelope sender and recipient are the same as to the From: and To: addresses. But it is common for them to have no correspondence at all, for instance, in the case of mailing lists.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.