When it comes to SSL/TLS configuration, the focus tends to be on web servers rather than on mail servers. But mail servers should also benefit from a strong SSL/TLS configuration with valid certificates. Mail servers that have been configured completely incorrectly quickly become apparent in IMAP and POP3 protocols, but insufficient standards are often set in server-to-server communication. Frequently, invalid certificates are accepted or no certificates at all are required because a connection is more important than security!
The following is an excerpt from the Postfix Main Configuration, which may however change at any time. Very important options are smtpd_tls_security_level and smtp_tls_security_level, which are set to "none" by default. This means that the server will never use TLS. Therefore, these options should always be set to may or encrypt. ```
tls_high_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!MEDIUM:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_medium_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_low_cipherlist = !aNULL:ALL:!EXPORT:!DES:!3DES:!MD5:!RC4:@STRENGTH
smtpd_tls_cert_file = /etc/postfix/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/postfix/ssl-cert-snakeoil.key
smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_ciphers = medium
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/postfix/dh4096.pem
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtpd_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtp_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
### SSL/TLS configuration for Dovecot
This is an excerpt from the [Dovecot](https://dovecot.org/) configuration and shows a possible configuration of the SSL/TLS parameters for Dovecot. ```
# DH parameters length to use.
ssl_dh_parameters_length = 4096
``` ```
# SSL protocols to use.
ssl_protocols = !SSLv2 !SSLv3
``` ```
# SSL ciphers to use
ssl_cipher_list = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
``` ```
# Prefer the server's order of ciphers over client's.
ssl_prefer_server_ciphers = yes
With the help of SPF (RFC 7208), it is possible to validate if a server which wants to deliver an email is actually authorized to send emails from the corresponding domain. For example, the server smtp.send.example.com establishes a connection to the server smtp.recv.example.com and tries to deliver an email to it from [email protected]. On the basis of SPF, the server smtp.recv.example.com can verify if the server smtp.send.example.com is a valid email server for the domain mail.example.com. The corresponding SPF record exists in the DNS system and can look similar to the following: ``` mail.example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::1 a ~all"
That means that the email is accepted if one of the following conditions is met: - the IP address of the server smtp.send.example.com lies within `192.0.2.0/24` or `2001:db8::1`
- the DNS A record mail.example.com matches the IP address of the server smtp.send.example.com
In all other cases the email must undergo further checks (which can be defined by the user).
## DomainKeys Identified Mail (DKIM) Signatures
The idea behind [DomainKeys Identified Mail](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail) (DKIM, [RFC 6376](https://tools.ietf.org/html/rfc6376)) is to check that an email was not changed during transit. To ensure this, the header, the content and the attachments of an email message are signed. However, the signature is not applied to the entire header, as certain fields can change during transmission of an email. The RFC proposes to sign the following values: - From (REQUIRED)
- Reply-To
- Subject
- Date
- To, Cc
- Resent-Date, Resent-From, Resent-To, Resent-Cc
- In-Reply-To, References
- List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive
DKIM signatures are stored in the header of an email message, the field is called `DKIM-Signature`. The value of this field includes multiple key/value pairs. The most important are: - v: DKIM version
- a: algorithm (e.g. `rsa-sha256`)
- d: signing domain (origin Domain)
- s: selector
A receiving mail server can request the current domain key via DNS, based on the domain and the selector. The DNS entry looks similar to the following: ```
selector._domainkey.example.com IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB" )
If an email with the header ``` DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.org; s=mail; t=1498137281; bh=ClzbA4T6yvpEouOct2aSAnFWcEUHTr6SDxrQizAy6ao=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=QTY/4jFXMH2piHJ478mtyQ6heutdCLw/VCrD3XcDVugITPSXnrEqiV07+N9YNQcTraCmyxT49upd8uz9fqRLz0VTZWoPF3+9eT9X2jdQU/1WpVtalFrQuBoXfzy4KZJdxp/DjwAB89CkmvRvv5aYSw0XrJsry1uMoVJx6NDCskA=
is received, the corresponding TXT DNS record which refers to the key is `mail._domainkey.example.org`.
## Domain-based Message Authentication, Reporting and Conformance (DMARC)
[Domain-based Message Authentication, Reporting and Conformance](https://en.wikipedia.org/wiki/DMARC) (DMARC, [RFC 7489](https://tools.ietf.org/html/rfc7489)) expands the two mechanisms DKIM and SPF. If a DKIM header is not present or a SPF record is not found, these two procedures do not trigger any actions and the email is treated as standard. DMARC offers the option to specify how to treat an email which is missing one or both procedures. DMARC is also a little stricter where DKIM handling is concerned, e.g. the From address field must match the domain in the DKIM signature field. Another point facilitated by DMARC is the reporting of incorrectly sent emails. Reports can be requested from receiving mail servers. In the same way as DKIM, DMARC is published in the DNS. A possible entry looks similar to the following: ```
_dmarc.example.com
IN TXT
"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:[email protected]"
Where the individual values have the following meaning: - v: Version
Manual tests can be carried out with openssl. These are only basic commands, which represent the contents of the server certificate in text form. Cipher suites can also be tested, but since this involves long and numerous commands, it is recommended that existing services (e.g. Hardenize) are used for this purpose. If this is not desirable or is not possible from a technical perspective, SSL decoder can also be installed locally, because the software is Open Source and available on Github. - SMTP
$ openssl s_client -connect example.com:25 -starttls smtp 2>/dev/null /dev/null
We use cookies to ensure you get the best experience on our website. By using our site, you agree to our cookie policy.