{ claus.conrad }

MTA-STS

Purpose

The primary purpose of MTA-STS is to address vulnerabilities in the traditional [SMTP](…/Simple Mail Transfer Protocol/) (Simple Mail Transfer Protocol) email delivery process, specifically:

  1. Preventing Downgrade Attacks: Historically, while TLS was introduced to encrypt [SMTP](…/Simple Mail Transfer Protocol/) communications (often initiated with the STARTTLS command), it was optional. An attacker could strip out the STARTTLS command, forcing the email to be sent in plain text, making it vulnerable to interception and reading. MTA-STS prevents this by mandating TLS encryption.
  2. Mitigating Man-in-the-Middle (MITM) Attacks: In a MITM attack, an attacker intercepts communication between two mail servers, potentially altering the email or redirecting it to a malicious server. MTA-STS helps prevent this by ensuring that the sending server verifies the identity of the receiving server using valid TLS certificates and only sends mail over authenticated, encrypted connections.
  3. Enforcing TLS Usage: It provides a mechanism for domain owners to declare that their mail servers require TLS encryption for all incoming mail, and to specify what should happen if a secure connection cannot be established (e.g., refuse delivery).
  4. Improving Email Privacy: By enforcing encryption, MTA-STS helps protect the confidentiality of email content during transit, which is crucial for sensitive information.
  5. Building Trust and Compliance: Implementing MTA-STS signals a commitment to email security, which can enhance trust with senders and help organizations comply with data protection and privacy regulations.

How it works

MTA-STS works through a combination of [DNS](…/Domain Name System/) records and a policy file hosted on a [web](…/Web development/) server:

  1. Policy Publication:
    • MTA-STS Policy File: The domain owner creates a plain-text policy file named mta-sts.txt. This file defines the rules for incoming email, including:
      • version: STSv1: The version of the MTA-STS protocol.
      • mode:: The enforcement mode, which can be:
        • testing: Sending servers will report any issues with TLS connections but will still deliver mail even if a secure connection cannot be established. This is recommended for initial deployment to identify and fix problems without disrupting mail flow.
        • enforce: Sending servers that support MTA-STS must use TLS and verify the certificate. If a secure connection cannot be established, they will refuse to deliver the mail.
        • none: Disables MTA-STS.
      • mx:: A list of the domain’s legitimate MX (Mail eXchanger) servers (mail server hostnames) that are authorized to receive mail. Wildcards can be used.
      • max_age:: The maximum time (in seconds) that sending servers should cache this policy. A common value is 604800 seconds (7 days).
    • Policy File Location: This mta-sts.txt file must be hosted over HTTPS at a specific, well-known URL: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The web server hosting this file must have a valid, publicly trusted SSL/TLS certificate.
    • MTA-STS [DNS](…/Domain Name System/) TXT Record: The domain owner publishes a [DNS](…/Domain Name System/) TXT record at _mta-sts.yourdomain.com. This record indicates that the domain supports MTA-STS and contains an id field. The id value should be updated whenever the policy file is changed, signaling to sending servers that a new policy is available.
      • Example TXT record: _mta-sts.example.com. IN TXT "v=STSv1; id=20240724120000Z;"
  2. Policy Discovery and Evaluation (by the Sending Server):
    • When an external mail server (the “sending MTA”) wants to send an email to a domain (e.g., recipient@example.com), it first checks for the _mta-sts.example.com [DNS](…/Domain Name System/) TXT record.
    • If the record exists, the sending MTA then fetches the MTA-STS policy file from https://mta-sts.example.com/.well-known/mta-sts.txt. This fetch must be over a secure HTTPS connection, providing an initial layer of trust and preventing [DNS](…/Domain Name System/) spoofing for the policy itself.
    • The sending MTA evaluates the policy, checking the mode, mx records, and max_age.
  3. Secure Connection Establishment:
    • Based on the evaluated policy, the sending MTA attempts to establish a secure TLS connection to one of the authorized MX servers listed in the policy.
    • It verifies that the receiving server presents a valid TLS certificate that matches the domain name in the policy.
    • If the policy mode is enforce and a secure, authenticated connection cannot be established (e.g., TLS isn’t offered, or the certificate is invalid), the sending server will refuse to deliver the email, preventing it from being sent over an insecure connection. If the mode is testing, it will report the failure but still attempt delivery (potentially over an insecure connection if a secure one fails).
  4. TLS Reporting (Optional but Recommended):
    • Domain owners can also publish a _smtp._tls.yourdomain.com [DNS](…/Domain Name System/) TXT record to specify an email address or URL where sending servers can send daily reports about MTA-STS connection attempts (successes and failures). This is known as TLS-RPT (TLS Reporting). These reports provide valuable insights for monitoring and troubleshooting MTA-STS implementation.

Resources