Noel's Muses

MTA-STS also helps in mitigating Man-In-The-Middle (MITM) attacks like a downgrade attack, this risk is high if the remote sender is using an outdated insecure protocol that's been configured as not acceptable, which should be every protocol less than TLSv1.2, when TLS fails the servers will negotiate down to plain text which means clear transmission of data allowing for your data to be compromised, especially if using insecure networks like WiFi hotspots etc.

To configure MTA-STS, you'll first need to create a sub-domain in DNS and an SSL virtualhost on your webserver for mta-sts.yourdomain (I recommend acme.sh for cert management, not the often problem plagued certbot). In the webroot for this virtualhost create the .well-known directory and create a file called mta-sts.txt

A basic Apache httpd example would be

<VirtualHost 1.2.3.4:443>
        Header always set Strict-Transport-Security "max-age=31536000; preload"
        ServerName      mta-sts.yourdomain
        ServerAdmin     info@yourdomain
        DocumentRoot    /var/www/hosts/mta-sts/html
        ErrorLog        /var/log/Apache/mta-sts/error_log
        CustomLog    /var/log/Apache/mta-sts/access_log combinedssl
        SSLEngine on
        SSLCertificateFile "/etc/ssl/private/mta-sts.crt"
        SSLCertificateKeyFile "/etc/ssl/private/mta-sts.key"
 </VirtualHost>

In mta-sts.txt we need to create specific options, we declare the version, there is only one, STSv1, then we declare we are testing, and our mail servers - one per line using the mx keyword, and lastly a TTL using max_age, eg -

version: STSv1
mode: testing
mx: mail.yourdomain
mx: mx2.yourdomain
max_age: 86400

After a while when you're happy enough things are good, you can change the mode from testing to enforce

Next we add our DNS record, again, a TXT record, this is really simple as there's only two options, the version, as mentioned above there is only one version v1, and an ID, which you can liken to the serial in a DNS SOA.

_mta-sts    TXT   "v=STSv1; id=2023102801;"

Update your zone's serial, reload, and your done. Oh, please don't get confused by what appears to be different hostnames in my instructions, https://mta-sts... DNS _mta-sts - this is correct, they are not typos, it's how MTA-STS expects them, why? Good questions for the MTA-STS author


Now it's time to set up TLS-RPT to get reports, this is not essential, but I strongly recommend it.

MTA-STS, although declaring there should only be secure TLS transactions (when in enforce mode), does not itself support any reporting, this is where TLS-RPT comes in. The reports sent daily are similar to DMARC reports, they give the domain administrator information about successful and most importantly any failed connections, this is especially important if you use MTA-STS enforce mode, it can alert you to any issues that sending Mail Servers have had trying to send you messages, it can tell you their IP, the IP it tried, and why the TLS connection failed, typically this is from old outdated, long abandoned and insecure protocol, like SSLv3, and if they are running something that ancient, it makes you question their care factor, so it's probably no loss not accepting their mail, in the spirit of privacy it does not include message meta-data, so it includes no sender or recipient email addresses.

Configuring TLS-RPT, like most of the other protocols is declared in a special DNS TXT record, we do this by opening your domains zone file, and adding the special hostname _smtp._tls then declare it's a TXT record and then add the data field, which like MTA-STS contains two entries, the version, again there is only one TLSRPTv1, then the rua which if you recall from DMARC is the email address you want reports sent to, I'd suggest this be different than to DMARC's, an example would be -

_smtp._tls   TXT  "v=TLSRPTv1; rua=mailto:tls-rpts@yourdomain"

Again, don't forget to increase your zone serial and reload (I keep saying this because it's the biggest issue with those who can't get DNS things to work)

Congrats, you're pretty much done... Remember to keep an eye on things for a few weeks before changing MTA-STS to enforce, and again for a week or so after since updates depend on your DNS TTL, which should be one day (set as 1D/24H/86400)

When you start getting your reports, if all goes well, you might find you only get daily reports from Google, this is because they are about the only one who send reports at present, so wont get spammed too much, as getting reports is rather rare, the abilities to generate and send reports seems to be elusive information scarcer than the black plague, destined only for the secret realms of a few. Guess sending reports will make for a part 2 to this article if I ever get it working

An example of a real report (received from Google), saying they've had 702 successful transactions with us...

{
    "organization-name":"Google Inc.",
    "date-range":{
        "start-datetime":"2023-10-28T00:00:00Z",
        "end-datetime":"2023-10-28T23:59:59Z"},
        "contact-info":"smtp-tls-reporting@google.com",
        "report-id":"2023-10-28T00:00:00Z_ausics.net",
        "policies":[{
            "policy":{
                "policy-type":"sts",
                "policy-string":[
                    "version: STSv1",
                    "mode: testing",
                    "mx: mail.ausics.net",
                    "mx: mx2.ausics.net",
                    "max_age: 86400"],
                "policy-domain":
                    "ausics.net",
                    "mx-host":[
                        "mail.ausics.net",
                        "mx2.ausics.net"]},
                "summary":{
                    "total-successful-session-count":702,
                    "total-failure-session-count":0}
                }
        ]
}

If there were any failures the report would also include extra information on a per IP basis and why, unfortunately, or should that be fortunately, I have had no failures, so can't example what they look like