MTA-STS for Postfix
MTA-STS is the proposed RFC8461 standard, which came out of draft status and was officially published on September 26, 2018. This standard offers a discovery mechanism to use full TLS between mail servers, with data encryption and server authentication. That is, this standard almost completely protects against interference with mail traffic between servers.
Simply, the essence of the standard is as follows:
There are some good articles ( for example ) about the standard itself and what it is for, comparing MTA-STS with other similar initiatives, and even showing how to create and publish a policy. But finding how to move beyond the first step was not so easy.
')
Before implementing the MTA-STS, it is necessary to put in order certificates of the mail server. Otherwise, mail servers that take into account your STS policy will reject the connection to your server. The following conditions must be met:
You can check the configured server with the certificate with the following command:
where MX.EXAMPLE.COM is the domain name of your MX server. For full compliance with the standard, it is desirable to verify that the desired domain name is present not only in the Common Name of the certificate, but at least in the Subject Alternative Name.
In order to designate your domain as supporting a secure connection with it, you need to publish the MTA-STS policy. To do this, you must perform the following simple steps in the order indicated (examples are given for the example.com domain).
1. Place at
text file:
The file must be given with Content-Type: text / plain. Redirects are not allowed. Line breaks must be either LF or CRLF. Blank lines are not allowed. The last line may be terminated by a newline, or it may not be completed by it - both options are allowed. Empty space in front of the colon and at the beginning of the line is not allowed. Empty space after a colon is allowed in any quantity. Empty space (spaces, tabs, etc.) at the end of each line is ignored.
Field Values:
version : format version. Should always be equal to "STSv1".
mode : policy mode. The options are: none, testing, enforce. The enforce mode corresponds to the normal operation of the standard - to require the correct certificate and persistent TLS connection when connecting to the server. Testing mode requires you to try to use a secure connection, but in case of an error, send mail in any case with the administrator notification through the TLSRPT mechanism. The none mode corresponds to this state of affairs, as if the policy had not been published at all. This mode is useful for properly disabling the policy.
mx : one or more fields containing the names of all allowed MX servers in the domain. As you can see from the example, templates are allowed, but only as a lower level domain.
max_age : time in seconds for which the policy can be cached and for which senders can continue to use it if the policy is no longer available. Because of this standard property, shutting down an STS is faster when publishing a new policy with the none mode.
2. Create a TXT record _mta-sts.example.com with the contents of the form:
Whitespace around a semicolon can be arbitrarily arranged in any quantity. In other places, whitespace characters are not allowed. The last semicolon may or may not be present.
Field Values:
v : format version. It must always be the first field, it must always be equal to STSv1.
id : the unique identifier for the published policy. May be a string of 1-32 characters in length consisting of letters of both registers and numbers. Changing the id value is a signal to senders that the policy has been updated. Therefore, updating the policy should be done first by publishing a new policy file, and then changing the id in the TXT record.
From now on, mail servers that support MTA-STS will send mail to your domain only through a secure connection with certificate authentication. This is where most of the manuals end, but the most interesting thing ahead is to get your own server to comply with the MTA-STS policy when sending mail.
The main difficulty is that this standard is not supported by mail servers, including Postfix. However, this unpleasant trifle should not stop us.
The search for a solution led me to the postfix-users mailing list archive with a discussion of the timing of the implementation of this standard. In one of the messages, Witts Venema, the author of Postfix, points to the preferred direction for implementing this functionality - use an external server to search for TLS policies. It is proposed to use the following configuration directive:
I implemented such a server to get the MTA-STS policy.
→ Source Code
→ Package in PyPI
The application lacks some of the features that RFC8461 prescribes, such as: proactive policy retrieval, reports, and restricting the frequency of policy requests. However, the main function — TLS policy discovery and caching — it performs.
The application requires Python 3.5.3+. Installation and configuration of this daemon can be done through the following steps.
It is enough to execute the command:
An alternative installation method is written here .
If you are satisfied with the default settings, then the command
Otherwise, the configuration can be taken from the example and tailor it to fit your needs.
The most important parameter, in my opinion, is the strict_testing parameter. If it is set to true (the default is false), then the application will return the secure policy even for domains with a policy in testing mode. This behavior is against the standard, but it is advisable for practical reasons: if the domain owner has published an STS policy even in test mode, then he is certainly ready for it. That is, then today, mail to gmail.com will be sent over a secure connection.
In the case of systemd, it suffices to place a simple unit file in /etc/systemd/system/mta-sts-daemon.service
After that, it remains to re-read the systemd configuration, enable the auto-start daemon and run it:
Assuming that the default port is used, the command
should withdraw
Add a line to main.cf:
Reload Postfix:
If everything is done correctly, then for STS connections in the /var/log/mail.info log instead of
records will start to appear
If you have reached this place, it most likely means:
Simply, the essence of the standard is as follows:
- The mail services that support it publish the policy (1 TXT record and 1 HTTPS resource for each domain).
- Mail services when sending mail to other domains detect the policy of the recipient domain.
- Mail services connect to the recipient domain's mail server, applying the restrictions to the TLS set by the detected policy, if one is found.
There are some good articles ( for example ) about the standard itself and what it is for, comparing MTA-STS with other similar initiatives, and even showing how to create and publish a policy. But finding how to move beyond the first step was not so easy.
')
Start over
Before implementing the MTA-STS, it is necessary to put in order certificates of the mail server. Otherwise, mail servers that take into account your STS policy will reject the connection to your server. The following conditions must be met:
- The server certificate is issued by a generally accepted certification authority (Let's Encrypt valid).
- The chain of certificates sent by the server includes all the necessary certificates of intermediate certification authorities.
- The certificate has a Subject Alternative Name field with the DNS name of your MX server.
You can check the configured server with the certificate with the following command:
[ "$(LANG=C openssl s_client -connect MX.EXAMPLE.COM:25 -starttls smtp -verify_hostname MX.EXAMPLE.COM < /dev/null 2>&1 | fgrep 'error')" = "" ] && echo OK || echo FAIL where MX.EXAMPLE.COM is the domain name of your MX server. For full compliance with the standard, it is desirable to verify that the desired domain name is present not only in the Common Name of the certificate, but at least in the Subject Alternative Name.
Policy publication
In order to designate your domain as supporting a secure connection with it, you need to publish the MTA-STS policy. To do this, you must perform the following simple steps in the order indicated (examples are given for the example.com domain).
1. Place at
https://mta-sts.example.com/.well-known/mta-sts.txt
text file:
version: STSv1 mode: enforce mx: mail.example.com mx: * .example.net mx: backupmx.example.com max_age: 604800
The file must be given with Content-Type: text / plain. Redirects are not allowed. Line breaks must be either LF or CRLF. Blank lines are not allowed. The last line may be terminated by a newline, or it may not be completed by it - both options are allowed. Empty space in front of the colon and at the beginning of the line is not allowed. Empty space after a colon is allowed in any quantity. Empty space (spaces, tabs, etc.) at the end of each line is ignored.
Field Values:
version : format version. Should always be equal to "STSv1".
mode : policy mode. The options are: none, testing, enforce. The enforce mode corresponds to the normal operation of the standard - to require the correct certificate and persistent TLS connection when connecting to the server. Testing mode requires you to try to use a secure connection, but in case of an error, send mail in any case with the administrator notification through the TLSRPT mechanism. The none mode corresponds to this state of affairs, as if the policy had not been published at all. This mode is useful for properly disabling the policy.
mx : one or more fields containing the names of all allowed MX servers in the domain. As you can see from the example, templates are allowed, but only as a lower level domain.
max_age : time in seconds for which the policy can be cached and for which senders can continue to use it if the policy is no longer available. Because of this standard property, shutting down an STS is faster when publishing a new policy with the none mode.
2. Create a TXT record _mta-sts.example.com with the contents of the form:
v = STSv1; id = 20160831085700Z;
Whitespace around a semicolon can be arbitrarily arranged in any quantity. In other places, whitespace characters are not allowed. The last semicolon may or may not be present.
Field Values:
v : format version. It must always be the first field, it must always be equal to STSv1.
id : the unique identifier for the published policy. May be a string of 1-32 characters in length consisting of letters of both registers and numbers. Changing the id value is a signal to senders that the policy has been updated. Therefore, updating the policy should be done first by publishing a new policy file, and then changing the id in the TXT record.
From now on, mail servers that support MTA-STS will send mail to your domain only through a secure connection with certificate authentication. This is where most of the manuals end, but the most interesting thing ahead is to get your own server to comply with the MTA-STS policy when sending mail.
The most interesting
The main difficulty is that this standard is not supported by mail servers, including Postfix. However, this unpleasant trifle should not stop us.
The search for a solution led me to the postfix-users mailing list archive with a discussion of the timing of the implementation of this standard. In one of the messages, Witts Venema, the author of Postfix, points to the preferred direction for implementing this functionality - use an external server to search for TLS policies. It is proposed to use the following configuration directive:
smtp_policy_maps = socketmap: inet: host: port: name
I implemented such a server to get the MTA-STS policy.
→ Source Code
→ Package in PyPI
The application lacks some of the features that RFC8461 prescribes, such as: proactive policy retrieval, reports, and restricting the frequency of policy requests. However, the main function — TLS policy discovery and caching — it performs.
The application requires Python 3.5.3+. Installation and configuration of this daemon can be done through the following steps.
Package installation
It is enough to execute the command:
pip3 install postfix-mta-sts-resolver An alternative installation method is written here .
Creating a configuration file
If you are satisfied with the default settings, then the command
touch /etc/postfix/mta-sts-daemon.yml Otherwise, the configuration can be taken from the example and tailor it to fit your needs.
The most important parameter, in my opinion, is the strict_testing parameter. If it is set to true (the default is false), then the application will return the secure policy even for domains with a policy in testing mode. This behavior is against the standard, but it is advisable for practical reasons: if the domain owner has published an STS policy even in test mode, then he is certainly ready for it. That is, then today, mail to gmail.com will be sent over a secure connection.
Startup organization
In the case of systemd, it suffices to place a simple unit file in /etc/systemd/system/mta-sts-daemon.service
After that, it remains to re-read the systemd configuration, enable the auto-start daemon and run it:
systemctl daemon-reload systemctl enable mta-sts-daemon.service systemctl start mta-sts-daemon.service Health check
Assuming that the default port is used, the command
/usr/sbin/postmap -q dismail.de socketmap:inet:127.0.0.1:8461:postfix should withdraw
secure match = mx1.dismail.de
Connect to Postfix
Add a line to main.cf:
smtp_policy_maps = socketmap:inet:127.0.0.1:8461:postfix Reload Postfix:
systemctl reload postfix.service If everything is done correctly, then for STS connections in the /var/log/mail.info log instead of
Trusted TLS connection established
records will start to appear
Verified TLS connection established
Conclusion
If you have reached this place, it most likely means:
- You have read the article without a single picture.
- From day to day, the likelihood of intercepting your domain’s mail will fall as other mail services implement the new standard.
Source: https://habr.com/ru/post/424961/
All Articles