Picture this typical quotidian activity: You reply to an email sent by a colleague in a different company. Your reply makes it clear that you’re expecting a response within a reasonable timeframe. You wait a day… or two… or a week… and there’s no reply. You finally get them by phone and find out that they never received the email.

Granted, this is a worst-case scenario. There’s a sliding scale of issues with email, with the worst of them being that it simply isn’t delivered and you never hear that it wasn’t delivered. What makes the scenario above worse is that you’re replying as part of an existing email thread – it’s not like you’re emailing cold. And yet I’ve had this happen.

There are lots of people who don’t respond to emails. And it’s easy for someone to miss an email in the big ‘ol stack o’ emails that greets them of a morning. But non-delivery has become a big enough issue for me that, if I don’t get a response, I now figure there’s a reasonable chance that it simply got dropped along the way, without the courtesy of a notification.

Other variants along this spectrum of responses might be:

The email is delivered, but it’s quietly stashed away in some spam folder that the recipient may or may not even know exists. This is common in my experience.
You receive a bounce because you’re not whitelisted (but the bounce provides no info on how to get whitelisted).
You receive a bounce because the server your host used has been sending too many emails and, suspected of being a source of spam, that server is blacklisted by other servers. Your email is therefore blocked.
You receive a bounce because one of the forwarding servers somewhere in the serversphere has been blacklisted. At least this can have a possible solution: resend the email on the expectation that, the next time, it will likely go via a different route, avoiding the problem server. That often works.
More recently: it’s just a “we’re creeped out” message: “Received too many messages from a new or untrusted IP.”

Even more frustrating can be a phrase tacked onto some of the bounce messages: “Sorry it didn’t work out.” They might as well say, “I’m not gonna let your little maybe-spam email through. Is this a mistake? I don’t know; I don’t care; not my problem.”

In a time when we all receive lots of emails, not all of which bear responding to (even if they’re not spam), there are lots of legitimate circumstances where your email arrives but doesn’t get a timely response. But I’m finding more and more that emails simply aren’t getting through.

The Scourge of Spam

Let’s be clear about one thing: spam sucks; I don’t know of anyone that’s a fan except for those that send spam. And IT managers have a heck of a job trying to filter spam; I don’t envy them that at all. And, judging by the small amount of spam that gets through to me, they’re doing a pretty good job. I checked to see what percentage of email traffic is spam these days, and, surprisingly, it’s gone down – although it’s still over half.

Not being an IT dude myself, the various techniques used to block spam remain opaque to me. I know there have been lots of ideas about filtering content, looking for patterns, etc. – many of which have been thwarted in a huge cat-and-mouse game.

My first exposure to pro-active anti-spam measures came many years ago with email systems using whitelists – just as some servers do today. The difference then from now is critical: the systems worked by requiring you to send some confirmation in order to be whitelisted. In other words, yeah, your email didn’t get through – but there was something you could do about it to push it through those last few inches.

Nowadays, you get a bounce message that says the equivalent of, “Nope!” Some server somewhere being abused by someone else? Well, if your email needs one of those servers, then you’re simply collateral damage. There’s nothing you can do about it. At best, you might literally have to figure out who’s in charge of a specific server in order to contact them to let you through. Who has the time for that? And, if you’re not tech-savvy, then you probably wouldn’t know the first place to start.

That’s the main problem with this: it’s the powerlessness. You send something and pray that it arrives. There appears to be no rhyme or reason for the failures. Maybe one email will arrive; maybe the next one won’t. Maybe one will get shuffled into a spam folder; another one won’t. Having successfully communicated once with someone doesn’t guarantee that you’ll be able to do it again – even for messages in an existing thread. That last message in the bullet list above is specifically about “you’re emailing us too much and we don’t know you.” (“Too much” being… what, 3 in a day? In one thread?)

Granted, from a technical standpoint, SMTP – the protocol for sending email – isn’t a guaranteed-delivery protocol. So we have never been able to expect perfection. But it’s worked well enough to where, perhaps, we’ve been lulled into expecting perfection.

The Big Ask

To be clear, I have no magic wand that would solve this problem technically, but there are some things that could help, and they relate to those bounce notifications. I see three aspects to friendlier messages:

Any non-delivery – or spam-folder shuffling – should result in a bounce message. Nothing should just happen quietly. You might think this would result in a flurry of new bounce messages clogging the interwebs, but, realistically, most bounces already generate a message, so this wouldn’t be a huge addition.
The bounce messages should explain what happened to the non-delivered message and why, and the explanation should be in lay terms, not in terms that only an IT person would understand.
Most importantly, there should be something the sender can do to punch through the barrier. Is there someone on call to whitelist folks? Is there a captcha-like thing that you can respond to in order to prove that you’re not a spambot? The solution should be clear in the bounce message, not requiring research to complete. Taking this extra confirmation step might be a hassle for an email sender, but at least it’s something they can do.

If Not Email, then What?

If email becomes too unreliable, then we’ll be tempted to turn to something else to replace it. But there are some significant catches there. The obvious alternative to email is to use instant messaging (IM) instead. The good news there is that it should be easier to thwart mass messages by, say, limiting the size of groups.

But here’s the big difference between email and IM: email uses a neutral, unbranded protocol to send emails. Senders and receivers can each pick their preferred sending and reading modes: choice of email client or online system. The sender and receiver can make completely independent choices based on their needs and priorities. It’s a market; the tech behemoths can’t coerce or capture you.

That’s not the case with IM. IM systems are captive, and the sender and receiver both have to have accounts with the same brand in order to communicate. Prefer one brand over another? Too bad, because you might not get to use your preferred brand if the other party doesn’t have an account there. In reality, you’d have to have multiple accounts with multiple different IM services to talk with all of the people you might want to talk with. And hopefully you’d never need to send a group message to a group of people that used different services.

One solution to this would be to follow the email example: standardize on a lower-level IM format and let users choose where they want to send and receive them. On Facebook but not Instagram? Then send your message from Facebook and have it arrive via Instagram. This would, of course, require some sort of universal addressing scheme, so it would take some work.

That said, I’m not expecting that this would happen, since the Facebooks of the world are not about sharing their users with others. It’s all about control.

(Something like this would also be useful for those of us who do a lot of teleconferencing, since we all need to install software from all of the teleconferencing services rather than having one that we prefer and allowing others to choose different ones that interoperate.)

Email to Sign Up

But there’s another ironic issue: when you sign up for these various IM accounts, what do you need? You need an email address. Email is the common denominator for so many systems. Forgot your password? The link comes by email. Suspicious behavior on your account? You’ll be notified by email. If email becomes too unreliable, then the whole thing crumbles.

In fact, many of us have multiple email addresses for multiple uses. And Google requires that you have a gmail account in order to use their other services – even if you never send a message through gmail. Email is structurally essential.

All of which returns me to my previous request of email IT folks: keep up the good fight against spam, but please, let’s give us lowly users some control back. Let us know when there’s a glitch, and, most importantly, give us a way to overcome the glitch. Email seems too fundamental to hobble its usefulness. I have much respect for the spam problem – I know it’s not easy. I’d just like for us users to be part of the solution rather than being excluded by the solution.

As a quick final note, this is my last official feature article on EE Journal. Kevin Morris gave me this opportunity back in 2008, and it’s been a good gig. I’ve learned volumes of stuff both from the EE Journal team and from all of the people I’ve interacted with in the course of writing articles. Thanks to all of them for that. And thanks to you, the readers, for considering me relevant. I’m not disappearing into the void; I’m sure we’ll see each other again.