Simple Mail Transfer Protocol (SMTP) TLS Reporting

SMTP is a communication protocol for electronic mail transmission and the SMTP TLS reporting is the mechanism to detect potential misconfigurations. Let’s go step by step to describe the SMTP (Simple Mail Transfer Protocol) working process and TLS reporting mechanism.

The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. Transport Layer Security (TLS) adds more security and encryption to the protocol.

Mail Transfer Agent (MTA)

1. Receives email from the client MUA
2. Uses SMTP to route email between SERVERS!
3. Passes email to the MDA for final delivery

[ED:text-important]For two e-mail servers to talk – MUST run SMTP and MTA in order to transfer mail between the 2 servers!
SMTP is used to forward email, POP is used to deliver email.

Mail Delivery Agent (MDA)

MDA Receives messages from MUA or from the MTA to sorts and deliver the email to the recipient’s mailbox. Any program that actually handles a message for delivery to the point where it can be read by an email client application can be considered an MDA. For this reason, some MTAs (such as Sendmail and Postfix) can fill the role of an MDA when they append new email messages to a local user

SMTP Encrypted Channels

The original SMTP protocol supported only unauthenticated unencrypted communication. It is vulnerable to Man in the Middle attacks, spoofing, and spamming, and requiring to encode any binary data before transmission.

A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including

• STARTTLS

STARTTLS is a protocol command, that is issued by an email client. It indicates, that the client wants to upgrade existing, insecure connection to a secure connection using SSL/TLS cryptographic protocol. STARTTLS command name is used by SMTP and IMAP protocols, whereas POP3 protocol uses STLS as the command name.

• DNS-Based Authentication of Named Entities (DANE) TLSA

DNS-Based Authentication of Named Entities called “DANE” – allows you to securely specify exactly which TLS/SSL certificate an application or service should use to connect to your domain.

• MTA Strict Transport Security (MTA-STS)

SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. Domain owners can use SMTP TLS reporting information to both detect potential attacks and diagnose unintentional misconfigurations.

SMTP TLS Reporting defines a reporting mechanism that covers failures in routing, DNS resolution, and STARTTLS negotiation, policy validation errors for both DANE and MTA-STS. A standard TXT record can be used to indicate where reports in this format should be sent. The report can also serve as a heartbeat to indicate that systems are successfully negotiating TLS during sessions as expected.

MTA-STS Policy is a mechanism by which system administrators or domain owners can specify the expected TLS availability, presented identity, and desired actions for a given email recipient domain.

SMTP TLS Reporting Policy

A domain publishes a record to its DNS indicating that it wishes to receive reports. These SMTP TLSRPT policies are distributed via DNS from the Policy Domain’s zone as TXT records like DMARC policies under the name “_smtp._tls“.

For example, for the Policy Domain “easydmarc.com”, the recipient’s TLSRPT policy can be retrieved from
“_smtp._tls.easydmarc.com“.

“v=TLSRPTv1; rua=mailto:[email protected]”

• “v”: Version of TLSRPT, for which this value MUST be equal to “TLSRPTv1”.
• “rua”: A URI specifying the endpoint to which aggregate information about policy validation results should be sent.

Note: In the case of “mailto”, reports should be submitted to the specified email address. When sending failure reports via SMTP, Sending MTAs MUST deliver reports despite any TLS-related failures and SHOULD NOT include this SMTP session in the next report. This may mean that the reports are delivered unencrypted. Reports sent via SMTP MUST contain a valid DomainKeys Identified Mail (DKIM) signature by the reporting domain. Reports lacking such a signature MUST be ignored by the recipient. DKIM signatures MUST NOT use the “l=” attribute to limit the body length used in the signature. This ensures attackers cannot append extraneous or misleading data to a report without breaking the signature. The DKIM TXT record SHOULD contain the appropriate service type declaration, “s=tlsrpt”. If not present, the receiving system MAY ignore reports lacking that service type.

SMTP TLS Reporting Schema

The report is composed as a plaintext file encoded in the Internet JSON (I-JSON) format.

Aggregate reports contain the following fields:

Report metadata:

• The organization responsible for the report
• Contact information for one or more responsible parties for the contents of the report
• A unique identifier for the report
• The reporting date range for the report

Policy, consisting of:

1 . One of the following policy types:

• the MTA-STS Policy applied (as a string)
• the DANE TLSA record applied (as a string, with each RR entry of the RRset listed and separated by a semicolon)
• the literal string “no-policy-found”, if neither a DANE nor MTA-STS Policy could be found

2. The domain for which the policy is applied

3. The MX host

4. Aggregate counts, comprising result type, Sending MTA IP, receiving MTA hostname, session count, and an optional additional information field containing a URI for recipients to review further information on a failure type.

Report Summary

Success Count: “total-successful-session-count”: This field contains an aggregate count of successful connections for the reporting system.

Failure Count: “total-failure-session-count”: This field contains an aggregate count of failed connections.

Result Types

Negotiation Failures

• “starttls-not-supported”: This indicates that the recipient MX did not support STARTTLS
• “certificate-host-mismatch”: This indicates that the certificate presented did not adhere to the constraints specified in the MTA-STS or DANE policy.
• “certificate-expired”: This indicates that the certificate has expired.
• “certificate-not-trusted”: This is a label that covers multiple certificate-related failures.
• “validation-failure”: This indicates a general failure for a reason not matching a category above.

Policy Failures

DANE-Specific Policy Failures

• “tlsa-invalid”: This indicates a validation error in the TLSA record associated with a DANE policy.
• “dnssec-invalid”: This indicates that no valid records were returned from the recursive resolver.
• “dane-required”: This indicates that the sending system is configured to require DANE TLSA records for all the MX hosts of the destination domain, but no DNSSEC-validated TLSA records were present for the MX host that is the subject of the report.

MTA-STS-specific Policy Failures

• “sts-policy-fetch-error”: This indicates a failure to retrieve an MTA-STS policy, for example, because the policy host is unreachable
• “sts-policy-invalid”: This indicates a validation error for the overall MTA-STS Policy
• “sts-webpki-invalid”: This indicates that the MTA-STS Policy could not be authenticated using PKIX validation

JSON Report Schema

Here is the example:

{
   "organization-name": organization-name,
   "date-range": {
     "start-datetime": date-time,
     "end-datetime": date-time
   },
   "contact-info": email-address,
   "report-id": report-id,
   "policies": [{
     "policy": {
       "policy-type": policy-type,
       "policy-string": policy-string,
       "policy-domain": domain,
       "mx-host": mx-host-pattern
     },
     "summary": {
       "total-successful-session-count": total-successful-session-count,
       "total-failure-session-count": total-failure-session-count
     },
     "failure-details": [
       {
         "result-type": result-type,
         "sending-mta-ip": ip-address,
         "receiving-mx-hostname": receiving-mx-hostname,
         "receiving-mx-helo": receiving-mx-helo,
         "receiving-ip": receiving-ip,
         "failed-session-count": failed-session-count,
         "additional-information": additional-info-uri,
         "failure-reason-code": failure-reason-code
         }
       ]
     }
   ]
 }

“organization-name”: The name of the organization responsible for the report. It is provided as a string.

“date-time”: The date-time indicates the start and end times for the report range.

“email-address”: The contact information for the party responsible for the report.

“report-id”: A unique identifier for the report.

“policy-type”: The type of policy that was applied by the sending domain.

“policy-string”: An encoding of the applied policy as a JSON array of strings.

“domain”: The Policy Domain against which the MTA-STS or DANE policy is defined.

“mx-host-pattern”: In the case where “policy-type” is “sts”, it’s the pattern of MX hostnames from the applied policy.

“ip-address”: The IP address of the Sending MTA that attempted the STARTTLS connection.

“receiving-mx-hostname”: The hostname of the receiving MTA MX record with which the Sending MTA attempted to negotiate a STARTTLS connection.

“receiving-mx-helo” (optional): The HELLO (HELO) or Extended HELLO (EHLO) string from the banner announced during the reported session.

“receiving-ip”: The destination IP address that was used when creating the outbound session.

“total-successful-session-count”: The aggregate count of successfully negotiated TLS-enabled connections to the receiving site.

“total-failure-session-count”: The aggregate count of failures to negotiate a TLS-enabled connection to the receiving site.

“failed-session-count”: The number of (attempted) sessions that match the relevant “result-type” for this section.

“additional-info-uri” (optional): A URI that points to additional information around the relevant “result-type”. For
example, this URI might host the complete certificate chain presented during an attempted STARTTLS session.

“failure-reason-code”: A text field to include a TLS-related error code or error message.

SMTP TLS Reporting provides visibility into misconfigurations or attempts to intercept or tamper with mail between hosts who support STARTTLS.