Spam, viruses and fraudulent email have put a massive stress on email infrastructure. The root cause behind this scourge lies in the email protocol itself, SMTP. SMTP was developed in the late 1980’s when the Internet was primarily a tool used for technical people, such as university professors, to collaborate and share information over unreliable data links. To facilitate this, SMTP has provisions that allow an email message to be forwarded from one machine to another, hopping its way to a final destination. At the time this was a trusted network, there was never reason to believe that a message wasn’t actually being sent from the person it purports to be from. As a result, the protocol has no capability to validate a sender. So when a message arrives at a mail server at a company and says that it is from george.bush@whitehouse.gov, there is no way for that receiving mail server to know if it really is or isn’t from whitehouse.gov. This core weakness is what allows spam to come from a seemingly legitimate sender, or viruses appear to come from someone an end user knows, or fraudulent email to appear from a trusted bank or trading site.
Plugging this hole in the email protocol SMTP will go a long way towards attacking spam and viruses at their core. But it turns out that adding authentication into the email protocol is a relatively complex undertaking, mostly because there are more than 20 million email servers active on the Internet. The approach that the Internet community has been taking is to create an overlay protocol that sits on top of SMTP. The two leading proposals are called “Sender ID” and “DomainKeys”. These two proposals are very different and largely complimentary. But they are fundamentally changing the way email works. Sender ID uses a “path based” approach, were the sender publishes a list of all IP addresses that are allowed to send mail on their behalf. This approach has the advantage of being light weight and easy to implement. At a bare minimum, a corporation should publish the IP addresses of its outbound mail servers as Sender ID records. If the corporation uses an email service bureau, the IP addresses of this entity should be included as well. Receiving mail servers will scan incoming messages and go back to the purported sender to see if the Sender ID record includes the IP address of the server that actually delivered the message. So for example, if whitehouse.gov published a Sender ID record of 1.2.3.4, the receiving mail server that just got a message from george.bush@whitehouse.gov can verify that the server that delivered the message was actually 1.2.3.4. The big challenge with Sender ID is known as “the forwarding problem”. Many people maintain permanent email addresses at their universities or other institutions. So if George Bush was sending an email to joe@university.edu, but that message got forwarded to joe@acme.com, acme.com would see a message from george.bush@whitehouse.gov but it would not be delivered by IP address 1.2.3.4—the server identified in whitehouse.gov’s Sender ID record. The forwarding problem prevents the receiving mail server from taking definitive action when incoming mail does not match a Sender ID record. However, as Sender ID is gaining in acceptance, an intelligent receiving mail server will view a positive Sender ID authentication as a very good thing and weight the message towards “not spam”. Sender ID failure does not mean for sure a message is spam—but it will be a mark against the message as the receiving mail server looks at a variety of factors and scores the message as either spam or not.
The other emerging standard is known as DomainKeys or DK for short. DK uses a cryptographic stamp embedded in the message header. Invisible to the end user, this stamp allows the receiving mail server to definitively authenticate
a message. The stamp is applied by the sending mail server which uses a “private key” to make the stamp. When a receiving mail server sees the stamp, it goes back to the purported sender and gets the public key. If the stamp decrypts properly, the message is known to be legitimate. If the stamp doesn’t decrypt properly, the message is known to be fraudulent.
DK solves the forwarding problem because the message can be forwarded many times and the stamp travels along with it. The main challenge to DK is that it requires a fairly significant change to both the sending and receiving mail servers. IronPort appliances make it simple to start applying DK stamps to outgoing mail. Major ISPs such as
Yahoo! are now looking for DK stamps. When they see a DK stamp that authenticates properly, they expose an icon to the end user stating “this sender is trusted”. A user can see the DK stamp system in action if they have a Yahoo! mail account and get messages from Amazon.com. Amazon is using IronPort appliances to do DK stamping, and Yahoo! decrypts this messages and displays the trust icon.
The important thing for companies to realize is that spam, viruses, and fraud are forcing the Internet community to change the way email works. These new authentication technologies will take years to implement globally.
However, as consumers and mail users begin to become aware of the trusted aspects of authenticated mail, the absence of authentication will become more and more suspicious. Consider this analogy: Email authentication is like having a driver’s license. An individual does not have to have a license to get on an airplane. But the lack of a license and the unwillingness to authenticate makes an individual suspicious, and they may be subject to searches, delays and disruptions. Similarly, as the adoption of email authentication grows, the unwillingness of a corporate mail server to authenticate will make it increasingly suspicious and subject the sender to delays and disruptions in their mail flow. IronPort Systems has made it easy for busy IT staffs to implement authenticated email, and make sure their email infrastructure will keep working—today and tomorrow.
No comments:
Post a Comment