Wandering Thoughts archives

Segregating your outgoing email to get blocked as little as possible

Like many places with a lively and long email history, we generate a number of different sorts of outgoing email. These sorts of email have different characteristics and thus different chances of being seen as spam email or bulk email by outside places.

So here's a rough list of the different sorts of email that our system winds up sending out:

• direct email from users; the least likely to be considered spam, since the users are typing it themselves.

• users forwarding email to outside places; often winds up forwarding spam that got sent to the user.

• bounces from when users forward their email to somewhere that refuses spam at SMTP time; potentially triggers 'trying to email too many bad addresses' logic at email providers.

  (Various providers at least claim to have such logic in their SMTP error messages.)

• autoreplies from users (vacation messages and so on); potentially bulk and may also trigger the same 'too many bad addresses' issue as bounces.

• user-run mailing lists with outside subscribers; potentially seen as bulk email, and may be spam if spammers hit the mailing list address.

• departmental mail shots of various sorts of information (eg, departmental newsletters); quite possibly seen as bulk email, but probably not as spam.

These different types of email are also of very different importance to our users, with the most crucial sort being direct email from users (bounces are probably the least important).

Since outside places may have much more violent reactions to some of these than others, sending all of them out from the same machines risks having all of your email to somewhere get blocked if that somewhere decides it doesn't like one type. Thus, it makes a great deal of sense to arrange things so that various different sorts of email are sent from different machines, or at least from different IP addresses; this way if some destination reacts badly to some sort of email, at least only some of your email gets blocked.

(You can also segregate on other characteristics of the mail, such as what your anti-spam system feels about it.)

Why it is hard to decommission a DNS blocklist

Every so often some ex-DNSBL makes the geek news because its ex-operators have gotten tired of people still trying to use it years after it was taken out of service, and to fix this they make their ex-DNSBL return positive answers for every query, thereby blacklisting the world and insuring that email systems that still use the ex-DNSBL will bounce everything until they are fixed. Which should happen fast, because people generally notice when they are not getting email.

(Not always, though.)

When this happens, people invariably fume that the ex-operators should have decommissioned things in a more graceful manner. Unfortunately, there isn't really a more graceful way that deals with the underlying problem, namely that the ex-operator's DNS servers are still getting pummeled by DNSBL lookups done by all those systems that are still using the DNSBL.

(And of course the ex-operators probably no longer have all that infrastructure of volunteer secondary DNS servers to distribute the load that they had when the DNSBL was live.)

You can't get rid of these DNS queries by removing the DNSBL subzone; that just changes the load from A record lookups in your DNSBL zone to NS record lookups as systems try to find the nameservers for the zone. If you're willing to be evil you can try answering with bogus NS records with very long TTLs, but I'm not sure that this will always work (plus, you are being evil so people may howl anyway).

(Also, you can't do this if you have an informative web page that needs to show up at root of the DNSBL subzone, as was common at one point; then you still need to answer some queries for the subzone.)

You can probably spend money to make this someone else's problem, by paying your domain registrar or a DNS service providers to handle your domain's DNS for you. But I suspect that many ex-DNSBL-operators do not feel too enthused about spending their money so that other people can continue to not fix their problem (among other reasons not to cede control of your domain's DNS to a third party).