The Spamhaus Project

best-practice

Mail relays - Part 2 | Problems with forwarded mail?

Forwarded mail can be more trouble than it’s worth - especially when it’s done without checks, validation, or spam filtering. Typos, unintended recipients, and forged senders can quickly snowball into blocklistings and delivery failures. In part two of this quick series on mail relays, we dive into the mess forwarding can cause, and what you can do to avoid it.

by The Spamhaus TeamMay 28, 20254 minutes reading time

Jump to

Introduction

Introduction

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. Many also do this without any spam filtering either. This can lead to a steep degradation of the reputation of the mail relay service, up to getting listed as a spam source.

If that describes your setup, you might unwittingly be helping the spammers, sometimes a lot.

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 the wrong recipient. Including all the spam. However, it gets better! Suppose the customer actually can type their email correctly and it is one of the big receivers mentioned in Part 1. Now the mail relay is forwarding spam to a place that takes a very dim view of that and starts rejecting the spam. This can easily lead to your IP address being blocked.

Spammers often forge sender addresses because they don't want to be caught. This results in the bounce message from the relay turning into spam too. Meaning that both the original spam and the bounce message can cause you problems.

It gets worse

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. If you are delivering to a local address, then all modern MTAs are capable of rejecting the message at SMTP transaction time. So you are rejecting the message before even accepting it. But when forwarding, you cannot do that. When the forwarded message is rejected, you are left with a choice - do you send a bounce message or not? In the case where it’s spam, the sender address is almost always fake, so sending the bounce is like sending spam.

And to top it all, sometimes spammers gain control of end-user accounts that enable forwarding, without any checking. The spammer simply inserts their list of targets in the “forward to” field, sometimes making lists of hundreds or thousands of recipients. The spammer then sends one single mail to the compromised recipient, and boom - you are doing all of the spamming for them.

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 enter a 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. While you do that, make sure there are sensible limits to the number of addresses that can be put in as forwarders.

Rewrite the sender address. When forwarding mail, 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. It also means the message can be authenticated using SPF - preferably using the domain of your customer.

Avoid sending bounces. Reject mails during the SMTP transaction where possible. If you do want to send a bounce message: make sure the original message has a positive SPF check or at most a neutral SPF check. Otherwise, it is better to drop the message entirely.

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.