1

Being able to compare the envelope values against the header field values is potentially useful for detecting fraudulent (e.g. spoofed) mail.

However, email servers, when receiving mail over SMTP, are not required to record the SMTP envelope values in a way that makes them available for retrieval by email clients. Email clients are therefore typically only able to retrieve each email's headers and body, and perhaps - depending upon the mailbox format (mbox vs mh vs maildir...) and the method by which the client is accessing the mailbox (POP3; IMAP4; directly on the server...) - some additional metadata like whether the mail has been read yet. But the email client will typically not have any direct access to the envelope.

Some email servers may, of course, be configured to add envelope information to the headers of emails before delivering them to the user; but this does not seem to be required by any standards documents of which I am aware.

In the physical world, by contrast, mail recipients typically do have access to the envelope. (The exception might be if, say, an executive makes their assistant routinely shuck incoming mail from its envelopes before handing it over.)

If I am correct about this, then my question is: was this decision (i.e. to hamper email clients' access to envelope fields and thereby to hamper their fraud-detection capabilities) the result of an explicit, on the record discussion at the IETF or any other body concerned with setting standards for email infrastructure? If so, which discussion, and when? Links to relevant mailing list posts would be appreciated.

Alternatively, if I am incorrect about this: then in what way?

sampablokuper
  • 1,961
  • 1
  • 19
  • 33
  • 1
    An interesting question, although I think in the physical world the envelope is more akin to the SMTP header - it merely contains MAIL FROM in the upper left, RCPT TO in the center and the printed bar codes, and some minor Received: information in the upper right corner. It doesn't even record intermediate Recieved: hops. – gowenfawr Dec 05 '18 at 14:07
  • @gowenfawr, thanks for your comment. I'm puzzled by your use of "although" :) Did my question not make it clear that I view the SMTP envelope as being comparable to a physical envelope; and that I was asking why, despite this similarity, email systems typically remove the envelope before the recipient sees the message, whereas snail mail systems typically do not? If you think I should clarify my question somehow, I would welcome your suggestion. Also, I assume that by "SMTP header", you meant "SMTP envelope"; again, please let me know if I misunderstood. Thanks again. – sampablokuper Dec 05 '18 at 14:43

2 Answers2

3

Alternatively, if I am incorrect about this: then in what way?

You are comparing apples to oranges.

The email Header is most closely equivalent to the physical mail Envelope - even better, the email Header represents routing information that is not accessible to the recipient in physical mail. So it's not correct to say that email client's access to "envelope information" is hampered. In fact, by design, the important aspects of "envelope information" are injected into the Header, ensuring that email Headers contain routing information greatly in excess of what any physical mail recipient could obtain.

Some definitions (assuming US mail for simplicity):

email Envelope: The values transmitted using the SMTP HELO/EHLO, MAIL FROM, and RCPT TO commands. Any of these may legitimately change from one hop to the next.

email Header: The text transmitted after the SMTP DATA command, up until the first blank line, after which the email Body begins. This likely includes a From: (which may or may not agree with the Envelope MAIL FROM) and a To: (which may or may not agree with the Envelope RCPT TO) header. This email Header grows as each intermediate mail server prepends Received information, as required by RFC 5321 §3.7.2. In addition the recipient mail servers may record the Envelope RCPT TO by injecting a header such as Apparently-To, Delivered-To, X-Envelope-To, X-Original-To, etc. (but see footnote below).

physical Envelope: The From address (optional, upper left hand corner), the To address (center), originating postmark (upper right, over the stamp). There may be additional encodings of the recipient information such as the IM Barcode and the orange barcode, but those are both effectively more-or-less lossy representations of the To address.

Note that RFC 5321 §3.6.3 suggests that SMTP relay servers should never modify anything in the header and body except to prepend the required Received line. In practice, other headers get prepended, especially with intermediate anti-SPAM/malware relays.

Here's how the email Header incorporates necessary Envelope information

The SMTP Received header is prepended by each SMTP server and describes the Envelope information about itself and the previous server. Consider this entry:

Received: from mail2.example.com (mail2.example.com [192.168.3.4])
    by lix-xx.members.linode.com (Postfix) with ESMTPS id 838CD4AE0
    for <gowenfawr@mymail.test>; Fri,  4 May 2012 12:45:26 -0400 (EDT)

This includes the EHLO/HELO hostname (the first mail2.example.com), the actual IP (192.168.3.4) of that system, and the DNS name that resolves via PTR (the second mail2.example.com). This information is useful for detecting fraudulent email.

More envelope information may be logged, as seen in this example:

Received: from NAM01-SN1-obe.outbound.protection.outlook.com
    (mail-oln040092002074.outbound.protection.outlook.com [40.92.2.74])
    by smtp21.example.org (Postfix) with ESMTP id AF320401EE
    for <open@lists.example.org>;
    Wed,  5 Dec 2018 15:28:59 +0000 (UTC)

Here the envelope RCPT TO was encoded using the FOR clause of the Received line. (Note that per RFC 5321 §4.4 only one entry is permitted, even when there are multiple RCPT TO commands.)

What's not preserved

The MAIL FROM and RCPT TO addresses are either not logged, or may be incompletely logged, into the header. This may be part of your "tampering" detection concern. It is a side effect of the fact that SMTP was designed to transport encapsulated messages that may have their own rich addressing and routing information before and after the SMTP phase of the connection. It's also something with no physical analog.

This design consideration may also reflect that SMTP was not designed to be trusted, simply to work. As soon as trust considerations arose, they were offloaded to other layers of the connection (PGP, SPF, DKIM, all of these occur "outside" the SMTP protocol).

Let's not forget

Any part of the header or body can be tampered with by a malicious relay. The more effort you put into making relays log security information, the more you're potentially relying on bad information. That's why each Received line reflects upon the previous relay, and not the one that's prepending it.

In other words, there's limited value to trying to load more trust into the relays.

As to logging Envelope RCPT TO in the Header, RFC 5321 §7.2 states:

There is no inherent relationship between either "reverse" (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the header section. Receiving systems SHOULD NOT attempt to deduce such elationships and use them to alter the header section of the message for delivery. The popular "Apparently-to" header field is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used.

The market has largely ignored this recommendation.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • Thank you for the interesting answer, which I have upvoted. You prompted me to reread RFC 5321 much more closely, which in turn informed my own answer. However, I disagree with your point that, "The email Header is most closely equivalent to the physical mail Envelope". It isn't: like the headers on a letter, it contains arbitrary information that may not ever actually have been used for routing the piece of mail. By contrast, both in the physical and electronic worlds, the envelope is used for routing the message contained within. Anyhow, thanks again. – sampablokuper Dec 06 '18 at 02:08
0

Alternatively, if I am incorrect about this: then in what way?

This part of the question was partially incorrect:

[Email] servers, when receiving mail over SMTP, are not required to record the SMTP envelope values in a way that makes them available for retrieval by email clients. [E.g. adding] envelope information to the headers of emails before delivering them to the user ... does not seem to be required by any standards documents...

The SMTP envelope has two values (I'm using "value" synonymously with "field" here):

  1. the MAIL FROM field, also known as the "reverse-path" argument to the SMTP MAIL command;
  2. the RCPT-TO field.

RFC 5321 §4.4 mandates copying the MAIL FROM value into an email header:

When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. This use of return-path is required; mail systems MUST support it. The return-path line preserves the information in the <reverse-path> from the MAIL command. Here, final delivery means the message has left the SMTP environment. Normally, this would mean it had been delivered to the destination user or an associated mail drop, but in some cases it may be further processed and transmitted by another mail system.

RFC 5321 §4.4 allows copying the RCPT-TO value into an email header:

When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content...

... and one of the pieces of information that may legitimately be included in the "Received" header is the relevant "path" (email address, essentially) from the envelope's RCPT-TO value.*

And of course, the email headers are available for retrieval by email clients.

* (Other paths, if present in the RCPT-TO field, should not be included, per RFC 5321 §7.2: "Especially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of [BCC or mailing list] mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the header section, either as part of trace header fields or as informational or private-extension header fields.")

Community
  • 1
sampablokuper
  • 1,961
  • 1
  • 19
  • 33