The Mad Philosopher

At Exoweb, our software developers use bogus email addresses of the form *@example.com (where I mean “example.com” literally, not as an example) to test their software’s ability to send email. Since I don’t want our Postfix server to attempt to deliver these messages out on the Internet, I need Postfix to handle these messages and blackhole them (make them disappear, sent to /dev/null). So what follows are instructions on how to blackhole an entire domain in Postfix.

First, we add a virtual_alias_maps entry to /etc/postfix/main.cf so that we can specify example.com as one of our virtual domains:

virtual_alias_maps = hash:/etc/postfix/virtual_alias

Inside /etc/postfix/virtual_alias, add a catchall address:

@example.com      blackhole@localhost

We have to use blackhole@localhost here and not /dev/null/ because virtual_alias_maps cannot run commands—it can only forward to real addresses. So we put an entry inside /etc/aliases to handle the blackhole:

blackhole:      /dev/null

This assumes that one of your mydestination domains in main.cf is localhost so that Postfix will actually consult the aliases file.

In order to make these changes take affect, you have to rebuild the aliases database, build the virtual_alias database, and reload your Postfix configuration. Respectively:

# newaliases
# postmap /etc/postfix/virtual_alias
# postfix reload

Now, any emails you send to blackhole@localhost will disappear, and so will any emails addressed to anyone@example.com (provided they are relayed through your Postfix server).

Footnote: The top-level and second-level domain names that are reserved for testing can be found in RFC 2606.

When you work in a software development shop, spaghetti code is most certainly frowned upon. What about spaghetti wiring?

So this was the remains of the small electrical fire that occurred 15 minutes before I arrived at the office today… the charged main circuit to the room that houses most of our developers, their computers, and the all-important Ice Box.

Do you think this is enough to convince the building management that the building’s wiring needs professional help? No, unfortunately, I think we’ll still have to fight them to get adequate electrical capacity and safety.

Here’s a great opinion piece from the blog of my DNS provider entitled: Want to reduce email spam to your mail server? Stop using backup spooling.

It is with regret that we have come to the following conclusion, but here it is: Offsite backup SMTP spoolers and backup mail exchangers have become worse than useless.

The problem is spam and the software that delivers it exploiting the weak authentication schemes inherent in the SMTP protocol itself. It used to be an annoyance, then it became a concern, it is now an epidemic and has resulted in the death of the offsite backup MX handler.

The author then goes on to explain what the problem is and why you won’t really miss your backup spooling. It’s a very interesting point of view (in a good way) that’s worth considering.