Must mail relays always indicate the use of encryption in the “Received:” header field?

Question

When an email message is sent with transport encryption, you can tell it from the “Received:” field the receiving mail relay adds to the message header.

> Received: from [...].google.com ([...]) by
> [...].mail.protection.outlook.com ([...]) with Microsoft
> SMTP Server (TLS) id [...] via Frontend Transport; [...] +0000

I’m wondering if this is always the case (e.g., because it is required by some sort of standard).

Here’s an excerpt from the header of a message I got recently from a customer support service.

> Received: from freshdesk.com (ec2-[...].compute-1.amazonaws.com [...])
>         by ismtpd[...]iad1.sendgrid.net (SG) with ESMTP id [...]
>         for <[...]>; [...] +0000 (UTC)

And here’s another, perhaps more worrying, from ACM’s email forwarder.

> Received: from in-007.lax.mailroute.net
>        by acmsmtp01.acm.org (ACM Email Forwarding Service) with ESMTP id [...]
>        for <[...]>; [...] -0500

Can I be certain in these cases that the messages were transmitted in clear text?

Answer 1

I’m wondering if this is always the case (e.g., because it is required by some sort of standard).

Not really. The most recent RFC for SMTP RFC 5321 describes the format of the received header but this includes no such information, probably also because STARTTLS for SMTP is an extra standard. This standard is described in RFC 3207 and provides no information about what should be added to the Received header either.

Generally the information are stored inside comment parts of the Received header (which can be inserted almost anywhere) and seem to adhere to not a single specific format. Thus it is mostly up to the mail server if and how this is included in the Received header and different mail servers handle it differently.

Apart from that it is no proof that the message was really transmitted with TLS even if you find this header. This header is just inserted by the server which can put anything inside it. It could also be modified or removed by other mail servers further in the path. None if the information there can be trusted fully, because they are not protected against deletion, spoofing or modification in any way.

Answer 2

Yes

rfc5321 section 3.7.2 says:

The gateway SHOULD indicate the environment and protocol in the "via" clauses of Received header field(s) that it supplies

so, a mail server may not provide the "with clause" (this is even more clear in the ANTLR of section 4.4, see Opt-info), in which case you have no data

…but if it specifies that the transport was ESMTP, then yes, I would affirm it was transmitted in clear text. Otherwise, they should have used the ESMTPS protocol type (see IANA registry). I know of no MTA which supports ESMPTS but logs it as ESMTP in the received header.

OTOH you may find a transport logged, but with a keyword for which you have to guess whether it was securely transported or not. Your first excerpt is a good example. Yahoo also uses a custom transport internally.

Answer 3

You cannot be certain of anything from "Received" headers. They can be altered or entirely be forged easily.