A daily occurrence at $JOB is “customer didn’t receive an email” and I have to go find it in the logs where hotmail or gmail or $ISP accepted the email in question. Then it’s the customer’s issue with the ISP, not us.

Another common problem that it causes is getting your server blacklisted for forwarding spam. As far as the destination server is concerned, it’s your server that is sending the spam.

You also have the problem with SPF. If the destination server does SPF checking, and the original sender has strict SPF records on their domain, then SPF will fail. As the recipient mail server will see an email coming from a host which it’s not allowed to. The solution for this one is rewriting the sender envelope to an address on your own domain when forwarding on.

Whether my reasoning is correct, though, would you agree that forwarding email to gmail, as opposed to using the alternatives outlined in the last paragraph of my post, is probably not a great idea? Especially given that google gives you those options?

Again, thanks for the input. I’ll probably write a followup post in the next few days.

Obviously you shouldn’t accept the mail and later bounce it either (note: bounces do *not* go to the address in the Reply-To: header, as you strangely seem to think; they go to the reverse-path given in SMTP).

You should reject at SMTP time instead, just as Gmail and everyone else does. That is not only ‘industry best practice’ as Graeme points out, it is the *only* acceptable practice.

If you drop silently, then *genuine* senders don’t get informed when their message doesn’t get through, whether it’s because they typoed the recipient address or their mail suffered a false positive in your spam filtering. By dropping mail silently you are making the system unreliable — effectively throwing the baby out with the bathwater.

If you want to forward mail, it’s up to you to ensure that you don’t accept messages which the recipient is going to reject as spam. Make sure your own spam filtering is at least as good as the filtering of the final destination.

Postini, MXlogic, Barracuda, Roaring Penguin, Symantec, SpamAssassin with Sendmail/Exim/Postfix etc etc, Rogers, Sympatico, Worldcom, Yahoo!… the list of software or networks which reject is almost endless. Reject, don’t accept, because that makes the sending MTA have the liability of generating the NDR – and this is your problem.

You’re accepting stuff and forwarding it; if the recipient rejects it then that’s your problem because you already determined in some way that the message was “good” (for some value of “good”) and accepted it.

There’s another way to look at this: your network, your rules. Which translates to my network, my rules; their network, their rules. If they reject, that’s because they think the message is spam, and you have to deal with that,

Trust me (well, you don’t have to): send something to Yahoo or Hotmail/Live enough times to get in the spam can, and you’ll find yourself being deferred. Do it $enough_times++, and you’ll get blacklisted temporarily. The problem is that from outside, you’ll never know where the threshold is.

AOL’s spam filter rejects with a 5xx during SMTP. Pipex and Webfusion used to and I assume still do. Most UK Universities seem to. I could come up with thousands of examples.

Again, though, I’m not aware of any major email provider that has as a policy to reject at the SMTP level spam *other than* gmail. I have just tried with both hotmail and yahoo, sending a message who’s subject and body consisted mostly of variations of viagra, cialis, and vacation, along with a few $s. Both hotmail and yahoo immediately accepted the mail and put it in the spam folder. This does not bode well for considering smtp rejection of spam as ‘standard industry practice’.

I’d be curious to know what servers you know of or administer that do something similar to gmail. I would still argue that any reply indicating that a message was rejected *for being spam* plays into the hands of spammers, as I can’t figure any sane policy to treat *this* error as one that should not bounce while treating ‘real’ errors (mailbox full, user does not exist) as ones that should be bounced. If you can come up with a reasonable policy to achieve that goal, I’d be happy to hear it.

I’ve never seen anybody recommend silently dropping mail as a good thing and have seen it described as bad behaviour countless times. Spam filtering at the edge, during SMTP and providing 5xx rejection errors is the correct behaviour. If you just silently drop mail, neither the sender, nor the recipient knows that there was a problem.

Also, in the case of spam, silently dropping mail is considered *good practice*. If you discover mail is spam (very common) after it has been accepted by SMTP and do *not* silently drop it, that means sending a bounce. Sending a bounce is how backscatter got started to begin with.

My mail server is a multi-user mail server, and as such I don’t have direct control over how my users want to use their email. I definitely intend to advise them to use either POP-pull or google apps (as, you might note, I specifically said in the blog post at the end), and if they don’t I will have to disable their forwarding. Hence the title, “Never forward to gmail.”

Rejecting with a 5xx code is the correct response when you don’t want to accept a message. It is your server that is generating the backscatter by accepting the message and then ultimately bouncing it.

Email forwarding is just generally not very good. If you can avoid it, do so. Perhaps you could use Google Apps for your Domain?