When first exploring email authentication, even people with a technical background find that there’s a lot of niche terminology that has to be picked up. This post will try to explain the different terms used for addresses that are associated with email messages.
How Is An Email Message Like A Postal Letter?
When your postman delivers a physical letter, it’s usually easy to locate the sender’s address. There are addresses on the envelope that handle the routing of the letter. There are also addresses on the letter itself, providing more formal contact information or in case the envelope is discarded after the letter is delivered. In fact the address on the letterhead inside might be a corporate headquarters while a different address is used for the return address on the envelope, so that undeliverable letters get handled specially when they’re returned.
Continuing with the letter itself the sender and recipient addresses, the date, and similar information can be found in the stationary letterhead or above the greeting (“Dear Mr. Watson”). The general content of the message is what the author has written following the greeting. These all have parallels in email messages, if you don’t stretch the analogy too far.
The format of the letter is a convention or standard that’s evolved over the past few centuries of business use. The format of the envelope is generally a more formal specification from the local postal service, which coordinates with international bodies like the ITU.
Comparing The Standards
The Internet Engineering Task Force (IETF) creates the standards used on the Internet, called a Request For Comment (RFC) for historical reasons. These standards can cover the format of documents like email messages, or the details of how those messages are transmitted between one computer and another. And in fact RFC5321 covers the computer-to-computer transmission protocol for email, while RFC5322 covers the format of email messages.
Returning to our comparison, the handling and formatting of the letter’s envelope are analogous to the computer-to-computer transmission protocol, or RFC5321. Likewise the layout and formatting of the business letter inside the envelope is analogous to the email message format, or RFC5322.
Email messages usually have a sharper distinction between the formal bits, the message headers, and the main content the author wrote, or the message body. You may not think about it, but you see them presented separately every time you read your email:
You should know that there are many more message headers in a typical email message than your email program normally shows you. Some of these record the history of how the message reached you. Others include information about how to verify the source of the message, like a DKIM signature. For now it’s enough to know that there are a lot of them, serving many purposes.
Let’s take the next step into the terminology. An email message’s headers and envelope information can be identified very precisely by using the RFC that defines it and the name of the item under that RFC. This table identifies the most commonly discussed items.
| Postal Letter | Email Part | Precise Term |
|---|---|---|
| Sender on envelope | Message Envelope | RFC5321.MailFrom |
| Addressee on envelope | Message Envelope | RFC5321.RcptTo |
| Date on letter | Message Header | RFC5322.Date |
| Author on letter | Message Header | RFC5322.From |
| What it’s about | Message Header | RFC5322.Subject: |
Hopefully some of the industry shorthand that you may already have encountered is a little clearer. The return address on the outside of the envelope, or it’s equivalent for Internet email messages, is referred to as the RFC5321.MailFrom address. But the author’s address that is always included on the first page of the letter inside the envelope is referred to as the RFC5322.From address.
The following diagram may help make the difference between the transfer protocol (RFC5321) and the message format (RFC5322) clearer. The text above the line between the computers represents the protocol, or commands and information being exchanged – this is described by RFC5321. The page below that line represents the contents of the email message, which is governed by RFC5322.
Return Paths And Bounce Addresses
There are two other names in common use that refer to the RFC5321.MailFrom address.
In the 1980s and 1990s, email messages were transmitted between computers a bit differently. It was frequently the case that messages had to be transmitted from one network of computers to another through special gateways, and maybe a third or fourth time before they reached their destination. And you couldn’t count on Internet services like the Domain Name Service (DNS) to know about all the machines between you and your destination, so you couldn’t just address your message to user@example.com and rely on the computers to figure out how to get it there.
These paths between networks were not always publicized and since it was not always possible to rediscover them on-the-fly, the path a message took was recorded in a special message header called the Return-Path: that could be used when you wanted to reply. As the Internet evolved the practice developed of storing what we now call the RFC5321.MailFrom address in the Return-Path: header. And so today, some people will refer to the Return Path when they mean the RFC5321.MailFrom address – and this is perfectly valid since that’s the official name of the RFC5322 header that captures that address.
When a message is being sent and for some reason can’t be delivered – because the address is incorrect, or the addressee’s mailbox is full, to name just two possibilities – an error or “bounce” message will be sent to the RFC5321.MailFrom address, as a courtesy to let the message author know that their message couldn’t be delivered. Hence the term Bounce Address is sometimes used to refer to the RFC5321.MailFrom address.
This use of the RFC5321.MailFrom as the Bounce Address is very important. Companies will set the RFC5321.MailFrom to a special address to make sure they know that those recipients didn’t receive their message. In many cases this is critical. Take the example of a bank sending a customer time-sensitive information – they may need to know that message hasn’t been delivered so they can have a representative contact the customer by other means before the deadline passes. This is just like the example earlier where the return address on the postal letter’s envelope might be different from the sending address on the letter inside.
Summary
It may take another reading or two, but hopefully this post helps clarify the following terms:
- Envelope From: Address
- Header From: Address
- RFC5322.From: Address
- RFC5321.MailFrom: Address
- Return Path
- Bounce Address
A clear understanding of this terminology will be important to discussing DKIM, DMARC, and SPF and which parts of the message they each work with.