IamCraig.com Rotating Header Image

email

Do you load the embedded images in email messages you receive?

In my daily emails I invariably receive HTML messages with embedded images that are remotely hosted. I’m not talking about attached images that may or may not be displayed in-line, I’m referring to images that are hosted elsewhere and are pulled in over an Internet connection.

Every email client I’ve ever used — which is only two, Eudora and Evolution (I miss Eudora!), not counting the few I have tried temporarily — has given me the option to display these automatically or not. I always choose not to display them. Why? Because invariably one or all of the images are intended to track whether or not the person at my email address has opened the message and (presumably) read, understood and agreed to it. No thanks. There’s no benefit in that to me the receiver, so why would I do that?

Example of poorly designed HTML email message displayed in Evolution.

Example of poorly designed HTML email message displayed in Evolution

Where I really notice this is in marketing messages, of course. One in particular that I receive daily (at left) lists a number of products in which I might be interested. There are six of them on the page, and it used to be that three of them displayed above the fold — i.e., where the screen ended before I am forced to scroll. I didn’t see the images due to the default settings in my email clients that do not display the images, but there were textual descriptions that were enough to make me decide whether or not to click to go to the website for more details. Sometimes I would click, but often not. The point is though that some months ago they changed the layout of the messages, and now there are none above the fold, and no visible text descriptions without scrolling. As a result, I don’t even remember the last time I clicked for more information.

And then there are messages where the header image seems to take up so much space that you have to scroll down fourteen screens to see any text! I’m not sure which is worse; that, or messages where the whole message is contained in one embedded image!

There are even companies that provide a service where you place an image bug in normal, everyday emails, usually in your email signature. These companies must be on the decline though, as I haven’t seen any in a while. When I do come across them I block their domains using my machine’s “hosts” file, so that they never achieve their purpose, even if I do load the images in the email.

To answer my own question, I almost never load the images. It’s an immediate turn-off if you can’t explain what you’re communicating about without pictures.

Port 25 open on Shaw connection

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 [archived]), 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 (archived).