Saw another legitimate email bounced as spam today:
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: email@example.com (generated from firstname.lastname@example.org) SMTP error from remote mail server after RCPT TO:<email@example.com>: host mx.service-myfriendsdomain-uses.com [18.104.22.168]: 554 5.7.1 Service unavailable; Client host [22.214.171.124] blocked using hostkarma.junkemailfilter.com=127.0.0.2; Black listed at hostkarma http://ipadmin.junkemailfilter.com/remove.php?ip=126.96.36.199
In other words, a completely legitimate mail was bounced because people who use the same mail server as the recipient (or for that matter, the sender) receive too much spam.
Sound surprising? Here’s the scenario:
- Sender firstname.lastname@example.org sends bad (even virus-laden) email to email@example.com.
- The innocentvictim@ account is configured to forward automatically to innocentvictim’s real email address, like firstname.lastname@example.org or email@example.com or whatever.
- The recipient domain (gmail or somepersonaldomain) is protected by a spam-filter (in gmail’s case, their own custom filter, in the latter case, a filter like junkemailfilter.com’s service).
- The spam filter simply sees spammy mail coming from the shared server.
- The shared server gets docked points for sending spam!
- Lather. Rinse. Repeat.
- After a while, legitimate people get bounced for sending legitimate mail to firstname.lastname@example.org, because the filtering service that protects the recipient’s final account treats all the forwards as spam, without unpacking them.
- Furthermore, mail from email@example.com starts getting auto-rejected by some recepients, because those recipients use the same filtering services as innocentvictim and, as we already know, innocentvictim’s mail server is being docked points because of all the spammy mail innocentvictim receives and auto-forwards.
In other words, a server from which many people forward mail tends to get blacklisted not because that server originates any spam, but because addresses there receive spam. And who doesn’t receive spam? Right. You begin to see the problem :-). Furthermore, it’s very hard for the filtering service to do better: if the spam-filtering service were not to dock points in that scenario, then the spammers would get clever and structure their original mails to just look like forwarded mails. They don’t care. In fact, they already do that sometimes.
So as far as I can tell, blacklists are kind of inherently broken. I’ve personally had to deal with this problem many times. What I did in this case was go to the URL mentioned in the bounce message and removed our shared server’s IP from the blacklist, using the procedure offered by junkemailfilter.com. But they’ll just re-add us soon, because the source of the problem isn’t going away.
One solution would be for the forwarding source address to insert a special header (containing a unique code) into the mail before it passes the mail along to the final destination. Then on the junkemailfilter.com side, that person would configure their filtering to allow mails with that code through — never treat them as spam. However, that would be a lot of work for most email users, due to the heterogeneity of mail delivery software; I don’t see it as a generally applicable solution.
Another solution would be an interface at junkemailfilter.com whereby users could tell it “I’m auto-forwarding mail to you from domain-on-shared-server.com. Please keep that in mind when deciding whether domain-on-shared-server.com is an originating source for spam.”
Any other ideas?