Forwards to external addresses causes blacklisting and/or backscatter

[kristian]

Hi. We have some sporadic issues with email forwarders to external addresses causing problems with our IP being blacklisted, and when that happens, causing backscatter.

Delivery to our servers go through these steps:

1. The internet sends an email from [email protected] to [email protected]
2. The mail is accepted on our common MX servers for all our domains, that does spam filtering/tagging
3. Our MX servers relays the email to the DA server that is hosting ourdomain.com
4. Exim on the DA server is configured to forward [email protected] to [email protected]

Then one of two paths:

5a: The forward to [email protected] is accepted, but is spam, and thus reported/flagged by the recipient
6b: Our IP is listed on a DNSBL because of the reporting

Or:

5b. The forward to [email protected] is rejected because our IP is listed on a DNSBL
6b. Exim bounces the mail back to [email protected]

(There's a third path as well of course: 5c: The forwarded email is not spam, and all is good. Luckily this happens most of the time.)

I found an old thread discussing this forward-to-external problem (https://forum.directadmin.com/threads/disable-e-mail-forwarding.50866/), but disabling external forwarders alltogether is not really an option, and I'm not sure if the envelope sender is the main issue here?

We're currently not using any spamfiltering on the DA server, since all the deliveries go through external filtering prior to reaching them. Spammy emails are tagged.

I hope someone can suggest something to help with the two bad paths an email can take in our system. For path A perhaps a good option is to not forward something that is tagged as spammy, but for a forward that does not also have an account, I'd have to either bounce it (in step 2), or blackhole it (step 2 or 4). Not sure what's a better choice. For path B I'd prefer to reject the mail already at step 2, but I suspect that's going to be difficult.

For any bad paths, ensuring our MX and DA server can exchange the necessary information to deal with something appropriately seems to be the biggest obstacle perhaps?

 

[sparek]

Using automatic forwarders to off-server/external email addresses is just generally a bad idea.

Most people don't want to hear that - but just because people don't want to hear that, doesn't mean it's not true.

In order for this to be resolved, you're going to be asking mail server administrators that run the mail server for otherdomain.com to change the way they read how messages are sent. They're going to have to be able to detect that the message was not originally sent by your server and that your server is just automatically relaying the message from another source. That other source is the on that needs be punished. But the administrators of otherdomain.com really have no reason to invest time and energy to make that happen. And otherdomain.com in this scenario is basically every mail server that is being operated in the world.

If [email protected] only wants to receive mail at [email protected] then maybe this user needs to consider advertising [email protected] as their email address?

You say you don't want to disable automatic external email forwarders, but the solution to this problem is going to be very, very difficult. Disabling or limiting automatic external email forwarders is a much easier solution.

 

[sparek]

Another solution - and probably the best solution - is to configure otherdomain.com to POP mail from the [email protected] email account and add that mail into the mail for [email protected].

Again, this depends on otherdomain.com being configurable to allow this. Gmail allows this. I do not know what other mail service providers allow this.

This is probably the best solution, because it uses standards already in place. But really as far as I know, Gmail is the only provider that allows this.

 

[mxroute]

You should already be using SRS so that's good, and it helps, but like anything else it's never the final answer. @sparek is on point with all of it, but I'll add what I can.

There are many steps to mitigating this and that's all they are, mitigation. There's no fix. Here's a little bit of what we do:

1. We send all outbound email rotating between a wealth of IP addresses. It shouldn't be so few that it doesn't help reduce rate limiting, but it shouldn't be so many that no recipient service will see any one IP often enough. Each IP needs a good bit of usage under it, else no single IP will build up a good reputation. There's no correct way to do the math on this, it's instinct and trial/error.

2. Filter inbound. This is so absolutely key. If you're getting it, you're forwarding it. if you're not filtering that, game over. I don't care if a user says "I don't want spam filtering on." Tough. They can either have no spam filter or a forwarder, they cannot have both. If they don't like it, send them packing, you have other customers to think about. This is how I force a baseline of filters on my DA boxes: https://github.com/mxroute/rspamd_rules/blob/master/enable_rspamd.sh

3. Filter outbound. You're going to want to filter again on outbound because it's more acceptable to block certain emails on outbound than it is on inbound. For example, Gmail is going to reject almost every email you forward from PayPal/Facebook/eBay so while you wouldn't block their inbound, you're tempting fate by forwarding emails that you know will fail. I can't give instructions for this, my outbound filters are the only thing I keep secret. But I relay all outbound mail to an rspamd/postfix server which has it's own rules different but similarly made to this: https://github.com/mxroute/rspamd_rules. Relaying to another server with DA described here: https://docs.directadmin.com/other-...l-outbound-email-through-a-remote-mail-server

If you're feeling adventurous and capable, when my outbound emails pass that rspamd instance they go out to a server running this: https://github.com/zone-eu/zone-mta

4. And finally, feedback loops. Use it, know it, love it: https://fbl.validity.com. When I get a spam complaint from a recipient, they go directly onto my ZoneMTA suppression list. They get no more email from our users. The only exception, ignore FBL from Fastmail because they're the only ones on the list that send FBL complaints for emails they automatically filter to spam folders (a setting enabled by default for their users), where other mail providers require users to click "Report Spam" or equivalent. If the recipient wanted the email and reported it as spam, tough shit, actions have consequences. This is the same thing done by Postmark, Mandrill, and many other transactional providers.


And that's pretty much the secret of how we guarantee email delivery, including forwarders.

 

[kristian]

Thanks for input! Many things to consider here for sure. Starting with *not* forwarding (externally) emails that we've already tagged as spam would be a good start. And urging users to not forward externally, but not disallowing it. For now.