While doing some mail server testing, I happened to notice that port 25 outbound on my run-of-the-mill, consumer grade, non-static Shaw connection is open. I wonder if this is a mistake, or if they’ve abandoned the practice.
Block outbound email to a specific domain with qmail
With Sendmail, I can block all email from (a sending domain to the server in question) and to a (foreign) domain using the /etc/mail/access file. However, apparently, it’s not so simple with qmail. Further complicating my need to prevent all users on one of my systems (which uses qmail) from sending email to certain domains is the fact that the system also uses Plesk, so I didn’t really want to start messing around with patching qmail and risk breaking something to do with Plesk.
After a fair bit of research I settled on a workaround using /var/qmail/control/smtproutes to artificially direct email sent to those domains from my qmail system to another mail server under my control, where the emails are rejected during the SMTP dialogue (because they’re not configured on that mail server, of course), thereby being bounced immediately to the sender.
If /var/qmail/control/smtproutes doesn’t exist on your server (it shouldn’t by default) you can create it with the following contents, or add the following contents to an existing file:
bad-domain.com:mx.your-other-domain.com
The file should be owned by the same user and group as most of the other configuration files in the “control” directory.
In this example you want to stop users from sending email to bad-domain.com email addresses, and you control an external mail server at mx.your-other-domain.com. When a user tries to send email to a bad-domain.com address, the sending mail server will not look up the MX record for bad-domain.com, instead routing the email to mx.your-other-domain.com. Because mx.your-other-domain.com is not configured to accept or relay email for bad-domain.com, it will reject it.
Caution: DO NOT route email to a mail server that is not yours. This will likely be considered spam by that mail server’s administrator, and the IP address of your mail server will then likely be blocked and perhaps added to more widely-distributed blacklists. If you don’t control another mail server you could route the forbidden email to a non-existent domain, such as no-such.domain or dev.null or bogus.invalid. To make the bounce message a little more helpful to the receiver (i.e., the original sender), perhaps make up a bogus domain like “Sending-to-that-domain-is.prohibited” which, on some systems, will return a bounce message that might include text like this:
Sorry, I couldn’t find any host named Sending-to-that-domain-is.prohibited.
Do not use a non-existent domain on a real top-level domain (e.g., v539bq59vb45.com, or some other string of randomly-typed characters followed by a real TLD), because there is no guarantee that domain won’t be registered and used in the future. Avoid using even your own real domain that you’re not using (unless you set up some unique but descriptive sub-domain such as “this-is-a-bogus-mx-vb49w4.example.com”), as you may use it in the future and forget that you’re directing email to it. That could result in mail loops if you end up hosting the domain on the same mail server, or being blacklisted if you host it with a third party or allow it to expire and it’s registered and used by someone else.
Anyway, having another mail server to use, I’m sticking with using that to cause the messages to bounce back.
Some assistance in coming up with this idea came from this thread at boardreader.com.
Have a comment or a better idea? Let me know in the comments.
BlackBerry/RIM. Going, going, gone?
A couple of years ago my company had a major server outage on a primary server that brought down websites and email for almost two and a half hours. Such outages are rare, but they happen, and they happen to small hosting companies like NinerNet as well as the giants. After that outage I wrote about the lessons learnt and, without trying to deflect attention or criticism away from us, I pointed out an extensive list of major service outages experienced by the likes of Google, Amazon, YouTube, Barclays Bank, MySpace, Facebook, PayPal, Microsoft, eBay, and so on.
Also in that list was BlackBerry/RIM, and this is what I wrote at the time on them in particular:
Have a Blackberry? Do you realise that all Blackberry emails in the whole world go through one data centre in central Canada, and if that data centre has a problem, you can still use your Blackberry for a paperweight? Nobody is immune; nobody gets away unscathed.
I’m under the impression that, since then, RIM expanded that single point of failure to create multiple points of failure (often under threat of sanctions by governments who want access to their citizens’ communications), and fail they have — worldwide — in the last few days. And for several days, not just a couple of hours.
Without wanting to gloat over a mortally-wounded about-to-be corpse, RIM’s problems weren’t that difficult to predict. Unfortunately for them they are, at this time, the victim of a perfect storm that includes (among other things) poor sales and share performance, product failures, the almost simultaneous (to their technical troubles) launch of a new messaging system on the iPhone to rival BlackBerry Messenger, and these latest technical troubles. But this perfect storm is of RIM’s own making, and their problems go deeper than that anyway; they go to the heart of their core philosophies.
Now, I’m no Apple fanboi (and in the wake of the death of Steve Jobs I commend to you What Everyone Is Too Polite to Say About Steve Jobs), but at least an iPhone more resembles a “proper” computer like the one you have on your desk than the toaster in your kitchen that can only do the one or two things its manufacturer decided in its infinite wisdom it needs to do. Mobile computers (aka “smartphones”) like the iPhone and those running on the Android operating system rely on open standards when it comes to things like email. In short, open standards and systems win. (That said, Apple is not the poster child for open standards and systems, and needs to change that.) There is no central super-server somewhere handling all email for all iPhone or Android users worldwide, just waiting to fail. With BlackBerry there is … or was. End of story.
If you swallowed RIM’s mantra about their system being de rigueur for business and the iPhone being “not for business”, you’re paying for that today.
Sorry for that.
Update, 30 May 2012: Seven months later and Roger Cheng at CNET finally comes to much the same conclusion.