When running a mail server, some basic rules have to be followed, e.g. ensuring that the server does not operate as an open relay. These rules are nowadays well known and the default configuration provided with MTA software typically avoids these “big no-nos”. Still, there are many pitfalls when configuring a mail server. In this post I want to share some of those pitfalls that I stumbled across in the last years myself.
Our setup consists of servers running postfix as mail transfer agent (MTA), dovecot as local delivery agent (LDA) and roundcube as a webmail interface for our users. Solutions or workarounds are therefore only given for this software stack. In principal, the issues mentioned in this post may apply to different software stacks as well.
1. Backscatter caused by Delivered-To header
One of the “big no-nos” is to accept incoming mails and afterwards figure out that they cannot be delivered. In that case a delivery status notification (bounce) has to be sent to the sender and since spammers can set whatever sender address they want, your mail server becomes a spam source itself. This is called backscatter and is typically avoided by only accepting mails for which a mailbox exists. Unfortunately, there are corner cases that can cause backscatter nonetheless.
The Delivered-To header can be set by mail servers to mark mails that have been delivered. If an incoming mail to joe@example.org contains the header line “Delivered-To: joe@example.org”, this mail is most likely trapped in a forwarding loop and should not be delivered a second time. In a postfix/dovecot setup, this leads to a bounce when the mail is handed over to dovecot:
mail forwarding loop for joe@example.org
Spammers can utilize this by sending a mail to joe@example.org in which they set the Delivered-To header to the same address, and your mail server will happily send bounces to whoever is listed as sender. Your server generates backscatter.
An optimal solution for this issue would be to let postfix reject the message if it has—according to the Delivered-To header—been delivered to a local account before. I am not aware of an easy way to implement this. As a workaround, you can enable soft bounces for local delivery problems and clean up the accumulating bounces manually. For the postfix/dovecot setup, this can be done by adding the following line to the dovecot definition in postix’s master.cf:
dovecot unix - n n - - pipe -o soft_bounce=yes ...
I mainly observed this kind of spam between April 2014 and November 2014, but several further mails with a preset Delivered-To header came in since then. There are different mentions of this issue online, mainly written during 2014.
2. Backscatter caused by DSN
Delivery status notification (DSN), widely known as bounces, inform the sender about emails that could not be delivered or are stuck in the mail queue. In RFC 3464 DSNs have been extended in that the sender can now request information about the delivery of their mails, including successful delivery. While this may be a nice idea, it makes generating backscatter trivial. Spammers only need to send an email to a valid user of your mail server, set a certain sender address and request a DSN. Your server will happily send a confirmation to that sender address. Your server generates backscatter.
To avoid this, DSN should not be offered to foreign users/servers. The fact that the email was received by your server should be sufficient information for the sender requesting DSN. Methods shown in the postfix documentation are to disable DSN altogether by setting
smtpd_discard_ehlo_keywords = silent-discard, dsn
in main.cf or only allowing DSN for certain addresses using smtpd_discard_ehlo_keyword_address_maps. But you may want to allow your own (authenticated) users to still use DSN. To achieve this, the option can be restricted to mails received via port 25 by not adding it to main.cf but master.cf instead:
smtp inet n - - - - smtpd -o smtpd_discard_ehlo_keywords=silent-discard,dsn
This way, submission and smtps ports—where authentication is mandatory—are not affected. Of course, you may have to teach your users not to use port 25 for mail submission.
3. Not restricting sender identities
Faking the sender identity of an email is trivial. Techniques like SPF and DKIM try to stem this problem by checking if a server is authorized to send mails for a certain domain. Your mail server, e.g. responsible for the domain example.org, of course has to make sure that its own users do not impersonate each other. If jane@example.org can send emails with sender address joe@example.org over your server, recipients would likely think the sender identity is legit. In postfix, there are two directives needed in main.cf in order to deny authenticated users to set arbitrary sender addresses:
smtpd_sender_login_maps = ... smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch
smtpd_sender_login_maps expects a mapping from sender addresses to authorized user login, as described in man postconf(5).
4. Not providing the original recipient to your LDA
This one is less of a security-related issue but still worth knowing. MTAs such as postfix allow defining address aliases, e.g. joe@example.org is delivered to joe.average@example.org, and using extensions such as joe+whatever@example.org. When these mails are handed over to your LDA, you should make sure that information about the original recipient address is handed over as well. This allows users to use the address as a criterion in server-side filters (sieve). In a postfix/dovecot setup, this is done by adding the -a argument to the corresponding line in master.cf, as described in the dovecot wiki:
dovecot unix - n n - - pipe
-o soft_bounce=yes
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -a ${original_recipient} -d ${user}@${nexthop}
5. Webmail bypassing all rules
Having implemented certain rules in your MTA, such as the restriction of sender identities, you want to make sure that these cannot be circumvented using the webmail interface. Webmail software can often be configured to use sendmail or PHP’s mail() function to send out mails. Instead it should connect to your MTA and authenticate as the corresponding user. In roundcube this is done by setting $config[‘smtp_server’] to a non-empty value.
Under point 2, I recommended to disable DSN on port 25. To still allow webmail users to utilize DSN, the webmail software should connect to either the submission or the (deprecated) smtps port:
$rcmail_config['smtp_server'] = 'tls://localhost'; $rcmail_config['smtp_port'] = 587;
$rcmail_config['smtp_server'] = 'ssl://localhost'; $rcmail_config['smtp_port'] = 465;