A majority of systems around the world use Internet blacklists as lists of IP addresses that are most likely compromised -- by bots -- and used by these systems to block or otherwise filter email. However, these lists can sometimes be used beyond the blacklist's design intent for increased security, but only after careful consideration.

By filtering with a blacklist, millions of email servers worldwide manage to stay operational. At the same time, email remains a viable communication medium in spite of the load spam emails put on the infrastructure.

There's never a good time to discover you can't use email, especially while flying around the world on business. This recently happened to me: I was unable to send email, and the error message baffled me. It claimed my IP address was listed in a certain blacklist.

Blacklisting is supposed to be enabled only for other servers trying to connect to mine, so why was the server blocking me, a user, when I authenticated and tried to email?

Turns out the problem was due to a configuration error. But I liked it -- the bug became a feature. One that can be dangerous, though. Find out the acceptable use policy of the blacklist provider for non-standard use like this, and comply with all requirements. For example, the CBL's terms of use are here: http://cbl.abuseat.org/tandc.html.

Because I'm among very few users using this server, the inconvenience was negligible. If I am willing to not email while connecting via insecure networks, then I gain an extra layer of security.

Millions of bot-infected computers are far less likely to be successful in compromising the server because they can't access much of its functionality. Given that most Internet attacks are performed via bots, I feel this raises the security level of the server at the price of being inconvenienced when on the road.

I cannot IP filter an SMTP server to be available only from certain locations -- as if I even wanted to limit myself in such a way. By its very nature as a public service, it needs to be available to the world if I am to receive email from others. And this extra security helps increase my assurance level.

This solution won't work for everybody. Perhaps you are not willing to inconvenience yourself, or perhaps you use a busier server and can't decide on such a measure for the other users. Indeed, for a busy server such as a service provider's, it will simply cause too much problems. But it works for me.

Of course, there are many varied solutions for secure email, from authentication and encryption to using VPN. This only complements them for me under my specific condition of being almost the sole user of this server.

Naturally, this cannot, nor should it, be implemented on email servers with more than just a few users, and existing solutions are more than enough for most. Be careful not to implement it lightly, as it can cause many misconfigurations down the road.

For a view on this from the perspective of a DNSBL operator, see http://cbl.abuseat.org/wrong.html.
For further reading on email security, I'd like to direct you to MAAWG's Managing Port25 document.

Follow Gadi Evron on Twitter: http://twitter.com/gadievron

Gadi Evron is an independent security strategist based in Israel. Special to Dark Reading.