What is TLS-RPT: Understanding The Reporting Mechanism Which Helps Ensure Encrypted Email Delivery

The Origin of SMTP TLS

The SMTP email protocol did not support encryption during the transport of email, back when it was introduced in the early ’80s. The TLS encryption was added later, which was also known as the RFC3207 standard. Later, SMTP TLS was implemented in the form of the STARTTLS SMTP command.

The Need For SMTP TLS-RPT

The MTA-STS was introduced in the RFC8461, and organizations that choose to implement it can ensure that the emails do not get delivered and are returned to the sender if TLS fails. The SMTP TLS reports notify the domain owner if there are TLS issues during the mail delivery. Other advantages of TLS-RPT include

• It provides mandatory TLS encryption, while MTA-STS protects the domain owner against SMTP downgrade.
• Users receive timely feedback reports, and the user is notified if a message fails to deliver.
• Provides complete visibility of the email channels: The domain owners are aware of each activity on their domain.
• It eliminates the delivery issues: The users can quickly identify the problem’s source and implement measures to fix it at the earliest.

How Does TLS-RPT Work?

• TLS reports are used for supporting the MTA-STS protocol, which ensures the encryption of emails before delivering them. The Mail Transfer Agent (MTA) starts negotiating with the receiving mail server to ascertain if it is supporting the STARTTLS command. In case the receiving server supports it, the sender MTA encrypts the email with TLS and delivers it to the receiving MTA.
• The negotiation between the sending and receiving MTA is a crucial milestone in the journey of an email. Malicious actors try to take advantage of this situation by downgrading the SMTP, which blocks the negotiations. At this moment, the sending server starts thinking that the receiving MTA doesn’t support the STARTTLS command. Hence, it sends the email without encrypting it with TLS, leaving the contents vulnerable for the attackers to see.
• It becomes mandatory for organizations that implement MTA-STS on their domain to encrypt the messages before delivering them. In case there is an attempt to downgrade the SMTP, the email will not get forwarded. Thus, an enterprise with MTA-STS ensures that there is TLS encryption on all their outgoing emails.
• TLS-RPT protocol notifies the domain owner whenever the sent emails from their domain face deliverability issues. In case there is a failure of email delivery because of an SMTP downgrade, the domain owner gets a report, which is in a JSON file format, and contains all the details of the failed emails. It ensures user privacy because these reports do not provide details about the contents of the email.

How to Enable SMTP TLS reporting?

• Users need to add a DNS record of the TXT type into the subdomain _smtp._tls.[domain] if they want to enable TLS-RPT. For example, _smtp._tls.sampledomain.com.
• The MTA supporting SMTP TLS reporting will check if this DNS record exists before sending the email to the receiver’s domain. If the DNS record exists, it will send periodic reports to the domain owner about whether the email was delivered successfully, or if there was a failure to deliver it.
• A typical SMTP TLS-RPT DNS record will look like this:

v=TLSRPTv1; rua=mailto:tlsrpt@in.sampledomain.com

(Please note the similarity of the syntax with the DMARC record.)

• The TLS-RPT record is a key-value string and separates the key and values with an equal (=) character. Additionally, it separates the key-value pairs with a semicolon and ignores any whitespaces. The two derivatives are:
  • “v”- It is the version indicator, and it is the primary key-value pair within the record.
  • 2. “rua”- It defines the address to which the reports need to be delivered. It allows multiple values, separated by a comma.
• The “rua” value specifies the used scheme, which can either be https: or mailto: for TLS-RPT. The https: scheme will require an HTTPS-enabled server possessing a valid certificate for the domain. The mailto: scheme resembles the one used in DMARC and specifies the address which will receive the reports.
• There can be multiple delivery endpoints in the rua value, separated by a comma. A user can choose to use both delivery schemes together. Example of a combined rua scheme:

v=TLSRPTv1; rua=mailto:tlsrpt@in.sampledomain1.com,https://tlsrpt.sampledomain2.com/v1

What Is The Format Of The TLS Report?

The domain owner receives the SMTP TLS reports in the JSON format, and it contains the following information:

• Each report has a unique identifier.
• It contains the date range of the collection of results.
• Name and contact information of the reporting party.
• Various policy results which contain detail of the supported policies, including:
  • SMTP TLS negotiation (STARTTLS)
  • DNS zone signing (DNSSEC, DANE)
  • MTA-STS policy
• While some reports may only contain errors, others may include successful sessions.
• Domain owners may receive multiple reports in a day, which depends on the number of email services that attempted to deliver email and the email traffic volume.
• An aggregator service combines and analyses the reports.

What Are The Different Types Of Failure?

SMTP TLS reporting reports failures for TLS negotiation, MTA-STS, and DNS zone signing.

TLS negotiation failures

• starttls-not-supported: The receiving MTA does not support the STARTTLS command.
• certificate-host-mismatch: The receiving MTA’s certificate is not matching the hostname.
• certificate-not-trusted: The sender does not trust the certificate, which the receiving MTA supplied.
• certificate-expired: The receiving MTA’s certificate is expired.
• validation-failure: Other general validation failures than the ones mentioned above.

MTA-STS related failures

• sts-policy-fetch-error: The sender could not fetch the MTA-STS policy over HTTPS.
• sts-policy-invalid: It indicates a syntax error in the policy, preventing the validation of the MTA-STS policy.
• sts-webpki-invalid: It means the failure to fetch the MTA-STS policy due to PKI validation issues.

DNS related failures

• tlsa-invalid: It indicates a TLSA record validation error.
• dnssec-invalid: It shows the inability of the recursive resolver to return a valid record.
• dane-required: It suggests that the sending domain requires DANE TLSA records of the destination domain (MX hosts), but it could not find any DNSSEC-validated TLSA records.

There are several protocols to establish encrypted channels between the Simple Mail Transfer Protocol (SMTP) MTAs, for example, DANE TLSA, STARTTLS, and MTA-STS. However, these protocols can lead to undelivered messages or delivery through unauthenticated channels due to misconfiguration or a potential attack. The SMTP TLS-RPT is a reporting mechanism that allows the sending systems to share crucial statistics about the possible failures on recipient domains. Thus, the recipients and senders can use this information to diagnose malicious configurations and detect potential attacks.