Web admin

Considering that e-mail is the killer application of the Internet, this question seems rather unexpected. After all, every time we click the send button, things seem to work. After reading this article you'll be amazed at the journey your e-mail goes through and even more amazed that it sometimes makes its way to the intended recipient at all.

Part of the problem is that the underlying infrastructure of e-mail is almost 25 years old and broken. The famous Sendmail program of Unix was written in 1981, and very little has been done to update it. Other programs, such as qmail and Postfix, have improved on the basic Sendmail, but the work has mainly focused on removing the bugs and making the administration a little bit more tolerable. Considering that 70% of worldwide e-mail is sent using Sendmail, it's actually quite amazing that anything gets delivered.

The first issue is performance. Today, billions of e-mail messages are being sent on a daily basis; the volumes are incredible. Now consider that the average Sendmail implementation can only handle about 7,000 messages an hour. Not that you are going to send that many messages, but just think of a company with 10,000 employees and you can see how quickly the e-mail server can be overloaded on the outbound. Add the inbound flow and you can see how quickly you can get into trouble.

As the people increasingly feel more comfortable with the Internet and conduct more and more business on it, it's not uncommon to see e-commerce Web sites that enjoy 250,000 transactions a day. Each of these transactions involve some sort of an e-mail with a notification or confirmation of the transaction. Assuming that you have resolved the performance issues, probably using brute force and adding more e-mail servers, you still have to contend with another issue, the visibility into the delivery.

Suppose you send a message and it bounces, say because the quota was exceeded at the receiver's end (mailbox full). You read the bounce message and probably make a note to try later. However, if the sender is an application, chances are that the bounced message is lost in the ether of your systems and nothing is being done with it. This is cause for concern as it can negatively affect your business, for example, if the customer purchased a license of your software on your Web site. Suppose the process is that you send a confirmation message with the license key so that the customer can activate the software that was downloaded. Now consider what happens when that confirmation e-mail is not delivered. For one, you cannot recognize the revenues of that transaction, but you don't even know that. After a few days, the customer calls your support center to clear up the matter. That call, which could have been avoided, will cost you at least $20, and a lot more if your support rep cannot locate the e-mail in question. This touches on archiving e-mail messages for legal purposes or just customer support issues, but that is a subject for another article.

The issue of visibility into the delivery sounds simple, but it is rather complicated. When an e-mail server establishes a connection with another server, two things can happen: the message is either accepted or rejected. This rejection is called a synchronous bounce, and can be something as simple as a "user unknown" or "account closed." But even if you don't get this reject notice, you still can't assume successful delivery of your message. The reason is that you can get what is known as an asynchronous bounce, up to four days after your message was supposedly accepted. This bounce can be caused by any number of things, for example, because the recipient's mailbox was full.

You would expect that your e-mail server would take care of this, but the truth of the matter is that most e-mail servers don't give you the required visibility into the delivery of your e-mail. Most e-mail servers don't process the asynchronous bounces and, when they do, the reports aren't combined with your synchronous bounces and don't provide the granularity you require to make an informed decision over the final disposition of the message. For example, an "out of the office" message will be categorized as a soft bounce, when in reality it is not.

To complicate matters a bit more, every bounce has an associated code; however, every domain uses them in a different way, creating their own explanations as the associated text messages for a bounce code. So you are left having to read the actual error message that comes back. While this can be made to work for applications with some fancy programming, it's a moving target, since many domains constantly revise and update their reasons for rejecting messages.

Things will get really ugly when you start resending those messages without actually analyzing why they were rejected in the first place, an unfortunate but understandable mistake under the circumstances. Soon enough the ISPs will consider you a spammer because of your high incidence of "bad" e-mail. Soon thereafter, you will find that the IP address you use for your e-mail server has been blacklisted, with all the negative implications that brings, especially since e-mail is critical to your online business.

Is your e-mail being delivered? You now start wondering. As if the issues explained earlier were not enough, assuming that your e-mail makes it through the receiving e-mail server, now it has to jump hoops trying to avoid all the anti-spam and anti-phishing filters, which can simply drop your message, quarantine it, or place it in the junk folder of the recipient. In the first two cases, the intended recipient will probably never get your message, while in the last case the likelihood of the message being read is rather low.

This brings us to the issue of spam. While legitimate businesses are sending more e-mail for more reasons, the exponential jump in e-mail traffic every year is due to spam. Because of spam there is a very healthy industry dedicated to the creation and maintenance of filters that try to deter the delivery of these messages. The problem is that your message might also fall into this category without you knowing it. JupiterResearch states that 25% of legitimate e-mail goes undelivered. This might not be a big deal when it's personal e-mail, but when it's critical business messages, it becomes a real issue, especially when many users have lost trust in e-mail.

Thanks to spam, there is a change in the e-mail environment. Not only do you have the deliverability issues we already mentioned, but you also have a tough environment that is getting tougher as legislation and self-regulation impose a greater accountability on e-mail senders. Unfortunately, e-mail was not developed with security and accountability in mind. This accountability is crucial in solving the spam crisis and restoring the trust in e-mail that many have lost.

Accountability can be broken down into three efforts:

1. Authentication: Where the identity of the sender is clearly established. This will deny spammers the ability to hide. There are various authentication standards out there, such as DKIM from Cisco and Yahoo!, and Microsoft's Sender ID, but there is no clear winner yet.
2. Reputation: Which will associate the identity of the senders with their reputation. Today, reputation systems are mainly internal to the ISPs, where they allow their users to mark messages as spam, which creates a spam score per sender.
3. Accreditation: If you don't have a reputation yet, or you have managed to damage yours, you can always go to an accreditation vendor, which will review and implement best practices and then allow you to add a special token to your messages that will tell ISPs that you are not spamming, and they will place your messages in the inbox of the intended recipient.

The problem is that spammers won't be the only ones affected by accountability. You will also be directly affected by this. Admittedly, e-mail accountability is still evolving, but this much is clear: authentication will shortly become mandatory. The ISPs and bigger domains will have different access rules, including authentication protocols. The reputation systems will measure customer satisfaction based on the number of complaints on a sender. Customer satisfaction will hinge on sender practices, and best practices will become required practices.

If your business involves sending e-mail blasts, which can go from a simple newsletter to what is known as permission-based direct marketing, you also have to comply with a few laws. In the United States the main law related to e-mail is known as CAN-SPAM. One of the things you have to include in every message in a blast is the ability for the receiver to unsubscribe. Again, this looks rather simple, but when you get around to fully implementing these functionalities, you will notice that it starts touching a larger amount of your current systems and ease of integration is one of those features you really want.

We all know how much easy integration can help us succeed on a software-related project. The e-commerce Web site has to integrate not only with the inventory and shipping systems, but also with the various financial systems. Each of these systems will, under certain circumstances, generate a confirmation or notification that will be sent via e-mail and has to be delivered. Very likely you will want these messages to be personalized, probably with something more sophisticated than "Dear Jane," so now you are talking about adding a few steps in the composition of the actual message, and soon you will find other things that you will want to add or you will be forced to implement in order to comply with legislation. Thus, ease of integration becomes vital.

By the way, if you think that using an e-mail service provider (ESP) is a solution to all these problems, think twice. They also use the same antiquated infrastructure you do.

So, is your e-mail being delivered? Well, chances are that you don't know and, as things get tougher and tougher in the e-mail environment, chances are that you will not be able to deliver anything unless you take action sooner rather than later. You are looking for not only an e-mail server, but an e-mail platform that can:

• Provide clear visibility and reporting into the delivery of messages
• Provide future proof support for the still-evolving authentication standards
• Flexibility for complying with current and future applicable legislation, reputation standards, and best practices
• Easy to integrate, be it via APIs or Web services
• High performance to grow with your success

With all the wealth of solutions available in that advanced research laboratory called the open source community, it is rather surprising that there is no solution to the initial question: Is your e-mail being delivered? Luckily enough, this kind of product can be found in the market today.