Mail relays - Part 2 | Problems with forwarded mail?

This blog follows Part 1, where we covered how to authenticate outgoing mail. If you haven’t set that up yet, we suggest you start there!

Fun with forwarding.

Many services allow their customers to forward their email to an arbitrary address without any checking whatsoever. Even more of them do this with no spam filtering whatsoever. This leads to the mail relay service getting listed for spam. Certain mail software, mentioning no names, is particularly good at causing this.

How does this happen?

Due to the lack of sanity checking of the entered address, the customer typos his or her email address and sends all their mail to a spamtrap. Including all the spam. However, it gets better! Suppose the customer actually can type their email correctly and it is one of the above mentioned big receivers. Now the mail relay is forwarding spam to a place that takes a very dim view of that and starts rejecting the spam.

Spammers often forge sender addresses because they don't want to be caught, and more often than not, those are spamtrap domains too. Resulting in the non-delivery notification from the relay turning into spam too.

Take control

To avoid these problems with forwarded mail altogether, it is better to replace the envelope sender address with an address you control. The Sender Rewriting Scheme (SRS) is a popular way to do this. Another solution is to use the mailbox of the forwarding user as the sender address. Both of these methods allow you to keep track of the number of bounces, so you can take action whenever there are too many of those. It also means the message can be authenticated using Sender Policy Framework (SPF) - preferably using the domain of your customer.

Sometimes, it isn't actually the forwarding that is the problem, we often see that the lack of spam filtering causes mailboxes to run into quota limits. Then the mail is rejected, but the sender was forged. This is where modern Mail Transfer Agents (MTAs) that can reject at SMTP transaction time can help. And when you do want to send a bounce (NDR, non-delivery report), make sure the original message had a positive SPF check or at most a neutral SPF check. Otherwise, you are better off simply dropping the message entirely.

This usually ends up with the mail servers being regular guests in the Spamhaus Combined Spam Source (CSS) Blocklist.

How can I avoid this forwarding nightmare scenario?

Robust spam filtering at the SMTP transaction, before accepting the message for delivery. After it has been accepted is too late, that might result in sending non-delivery notifications and that is undesirable. Not filtering spam, perhaps out of crippling fear of customers making claims, is usually rewarded in ways that cost even more time.

Closing the loop on forwarding. Before entering the destination address into the forwarding database, a validation mail should be sent. One that explains why they are getting this mail and requiring them to visit a URL and type in the right token to approve it. Some forwarding services already do this and as a result, Spamhaus does not see them causing problems like the ones above. While without spam filtering this is inadequate it is at least a step in the right direction.

Monitoring the mail server logs pro-actively is recommended. It is far better than finding out something bad has happened long after the fact.

Finally, consider adding a DKIM signature if the message doesn’t already have one. Be sure to use your customer’s domain for the signature (see our previous blog on authenticated mail for more details). Sending DKIM signed mails will help protect your IP reputation, making it less likely to get blocked if a customer accidentally starts forwarding spam.