As you may know, email is thirty years old and its underlying infrastructure was never built with security and accountability in mind. No one ever thought that email would become as widely used as it is today, that the Internet itself would be subject to so much abuse.

The original email and Internet systems that we know today weren't invented by Al Gore, but by our own government missile defense system group called the Advanced Research Projects Agency (ARPA), whose primary job was to handle research for all space and strategic missile research. NASA was then formed, and the activities of ARPA moved away from aeronautics and focused mainly on computer science and information processing.

One of ARPA's goals was to connect mainframe computers at different universities around the country so that they would be able to communicate using a common language and a common protocol. Thus the ARPAnet -- the world's first multiple-site computer network -- was created in 1969. In order to have an account on these systems you simply asked for one and they just gave it to you almost without ANY questions, completely overlooking security and accountability.

Well, obviously, as time went by and the systems got larger and more interconnected, some people figured out the vulnerabilities and started to send out the first of many billions of unsolicited messages now known as SPAM. The question now comes down to how we can possibly patch a hole this big. Email authentication technologies like DKIM (DomainKeys Identified Mail) are a start.

DKIM is a signature/cryptography-based sender authentication protocol developed in order to address the problem of forged email messages (missing security and accountability) and to allow an organization or individual to take reasonability for the message it sends, which has given rise to the concept of email reputation. Now, I won't bore you with the details of email reputation and authentication, but I do want to focus on why we got involved in this early on.

Email is now about as mainstream as any technology can be, yet the viability of email is continually being threatened by viruses, spam, spoofing, and phishing. All of these threats are shaking the confidence in email as a viable tool for communications and conducting business, and StrongMail is committed to help protect it. We have been participating in the DKIM standard since day-one, and we are proud to have our own employees acknowledged for their hard work in the standard.

StrongMail was the first technology provider to integrate support for all emerging authentication protocols into its outbound email products to simplify compliance with whatever standards are mandated. DKIM has since gained a lot of traction, and AOL, GMAIL, and Yahoo! now use it successfully in production.

Unless you're a member of the CIA, a Matrix super fan, or a cryptographic expert, signature-based authentication can be difficult to understand. In StrongMail, you don't have to think about any of that stuff, since we make it as easy as 1-2-3 with our step-by-step interface, which will either create, upload, or use the existing keys needed to properly sign and verify any email.

In fact, StrongMail is specifically designed to make it easy to work in the complex and ever-changing world of email standards. You even have the ability to apply authentication to certain email streams or campaigns based on your needs. Our offering is so simple that anybody with a mouse, keyboard, and monitor can institute email authentication.

Overall, DKIM brings accountability to the sender, establishes a reputation and confirms whether they should be sending email from a certain domain. By doing this, receivers can better separate mail streams from those who are good and those who are bad, which enables better anti-spam technologies and reduces false positives.

I read an article the other day that referenced StrongMail, and the topic was around sending speed. While it is true that you can send over 1 million messages per hour with StrongMail, you also have to realize that with great speed comes great responsibility. I’ll get to this last point in a second.

First, I agree with many of the points in the article. It is very important to have an email platform in place that is capable of not only sending but generating millions of dynamic and personalized messages for rapid-response situations such as alerts, quotes, notifications, reminders, ecommerce, etc. For those applications, you need to have a system that will allow rapid and dynamic scale when needed without having to add a lot of extra iron in the data center.

On the other hand, if you’re sending millions of messages really fast, you need to understand that your delivery is largely (if not solely) based on your sender reputation and how the ISPs view you at the time of send. This is why it is critical to have a Message Transfer Agent (or MTA) that gives you the ability to adhere to the sending rules the ISP’s have in place at any given moment in time.

When we built the StrongMail platform, we knew that in addition to speed, we needed to build in the control to follow best practices and send email in the way ISPs like to receive it. Offering both together allowed us to provide companies with the flexibility, control and visibility they need to see in real-time what is happening to their email streams and act accordingly.

Let’s face it; the reason companies send email is because, when done properly, it is a very effective and immediate communications medium that can create valuable customer relationships. However, when done improperly, email can cause brand degradation and reduce customer loyalty.

That’s why when it comes to email, it’s important to act responsibly. Just because you can send a million messages an hour, doesn’t mean you should.

The major issue with email is that it has expanded far beyond personal communication. The systems needed today require a lot of functionality with little to no maintenance and resources to run them. In the beginning, it was important to focus on rapid scale, deployment and ease of use; starting first with the method at which email is delivered.

A majority of the software that existed at the time could always get you started but was traditionally very hard to scale without adding a lot of additional hardware and bodies to run it. The most important part was not only sheer speed but also the flexibility and control needed to build and deploy email applications.

When we started StrongMail, we realized that an ASP model would be impractical to deliver everything customers wanted. So rather than focus on only building a world class MTA, the decision was made to build an application server to allow rapid development and deployment (mind you, this decision was made over time and out of necessity for what we needed to support our customers).

The two main pieces consist of EAS (or the Email Application Server) and the MTA (or the Message Transfer Agent). Traditional terms are closer to a “client/server” model where each can act in unison with one another or with “n” number of systems for scale. Again, only focusing on building an MTA was not the full solution. Sure, the MTA needed to be very fast, but it also needed all the necessary dials and knobs to allow customers to control their email streams according to their business. Email goes far beyond that. It was also vital to give customers full visibility into what was happening with their email and most importantly allow businesses to make decisions in real time to take corrective action.

SPAM, viruses and phishing attempts have greatly changed the way we conduct transactions today, so it's important to have a platform that demystified the problems and allows companies to take control. Email has gone far beyond “batch and blast” methods of the past, and there are very real metrics tied to email communications and delivery. Companies can spend more time focusing on what is core to their business and not building email infrastructure. This is why StrongMail was created. To produce world-class, on-premise infrastructure to allow customers to optimize the way they do business.

It is funny how things progress in life. While attending college in Texas I was the person the IT guys hated. It never failed that whenever I entered a computer facility things usually ended up with smoke and a lot of expletives. I seemed to have the wonderful knack of breaking anything I touched that was computer related. After graduation, I moved to California and started a recruiting business with a few buddies. This is where I learned my first little bit of technology (it was out of necessity and cheapness). Plus it also helped me vet candidates before sending them on interviews. That skill led me to a company I still have a lot of respect for today and responsible for helping me grow the skill set that allowed me to co-found StrongMail. The company was called L90 and the technology we delivered was call adMonitor. This was an advertising and email platform we ran as an ASP and the company did extremely well. We had well over 3000 blue chip customers, a super team, and excellent technology. At our peak we were serving well over 8 billion transactions a month and chomping at the heels of DoubleClick.

When I started with L90 I was doing corporate recruiting to help reduce the amount of fees that they were spending on hiring talent in a very difficult market. After roughly 4 months of doing this and meeting my partner in crime (Frank Addante, who was the CTO and founder of L90, serial entrepreneur and pretty much the most driven guy I have ever met) I feel he quickly saw a skill in me that I wasn’t even sure I had. I started to run IT operations having no prior knowledge in this industry and then within a few months started building out the infrastructure that enabled our billions of transactions. The coolest thing about doing this was the challenge and scale. The entire industry used a system called Keynote to track competitors’ availability. High-scale and redundancy were a must.

So how did this all lead to founding StrongMail you might ask? It’s simple. At L90 we relied on many systems to produce results and they were a nightmare to maintain. I only had a staff of 2 people and we had a ton of gear (close to 800 systems). The challenge we had at L90 was it took many programmers to write custom code to allow our customers the flexibility to do what they desired. It also took a lot of hardware to run open source software (we used Sendmail) and that technology was really intended to run corporate email like Exchange. I love open source and we used it anywhere we could but it just was not designed to meet the needs of the outbound email and delivery. We parlayed the challenges we learned by running a very successful business and realized there was a gap in the market (at least we were hoping there was). Building this stuff is not easy, its takes a lot of time and effort and it is hard to scale. In my next entry I will discuss the problem itself and how we address it at StrongMail.