Toll Free: 1-888-883-9462
User LOGIN
| Privacy Policy
| Site map
  Email Marketing Tips Newsletter: 

Tuesday, June 30, 2009

Authenticate Your Email - Cryptographic Solutions

Earlier, I described authentication of email messages. I stated the objective of email authentication was to facilitate getting legitimate email delivered to the Inbox, while not delivering unwanted email (i.e., spam).

I also said there were two categories of solutions: those that deal with sender address forgery and cryptographic solutions.

Since most abusive email messages carry fake sender addresses, it makes sense to try and detect forgeries and then drop that email. Last time I discussed the four protocols that deal with sender address forgery:
  • Sender Policy Framework (SPF) - Open Source, 2003, historical status.
  • Sender ID - From Microsoft, 2004, historical status.
  • Sender ID Framework - Combination of Sender ID & SPF, 2004, historical status.
  • Vouch by Reference (VBR) - In April of 2009, a new standards track proposal was submitted to the Internet Engineering Task Force (IETF), called Vouch by Reference (VBR). It will be valid for six months.

There are also three cryptographic solutions, but I will only discuss the third, since it represents a combination of the first two and is an industry-wide effort that is currently on an Internet standards track:

  • DomainKeys - from Yahoo
  • Internet Identified Mail (IIM) - from Cisco
  • DomainKeys Identified Mail (DKIM) - Combination of DomainKeys & IIM

So, What Is DKIM Anyway?
DKIM defines a way for an organization to take responsibility for its email ... to provide a way for the recipient to verify that it came from that organization. The receiver can then decide what to do with the email.

DKIM provides a great deal of flexibility for the organization that signs the message: The organization can be the author's, the originating sending site, an intermediary, or one of their agents.

There is also flexibility in the signatures: A message can contain a single or multiple signatures, from the same or different organizations involved with the message and its transport.

Once the sender has been identified, Sender Reputation then comes into play, since this is what can then ensure delivery of the organization's email ... Or, just the reverse - the email could be dropped!

DKIM uses public-key cryptography and a domain-level digital signature. This differs from most cryptographic solutions, in that it uses a key-centric public key management approach, whereas most schemes use a certificate. With DKIM, the owner of the SDID asserts the validity of the key; with a certificate-based scheme, a trusted third-party asserts the validity of the key.

The Domain Name Service/System (DNS) acts as the key server, thus reducing the need for new infrastructure. Both the integrity of the message contents and the responsible organization can be verified.

DKIM also includes an option to publish details about an organization's email signing practices. So, for example, it could be stated that ALL email from an organization will be signed. If an unsigned message is received from the organization, the recipient could look up the organization and thus learn the unsigned message is not legitimate.

Verifying an Identity and What It Means
A given person or organization (an entity) is distinguished from all others via a set of characteristics. There are also one or more "identifiers" or names associated with an entity. DKIM uses a domain name as an identifier and calls the identifier the Signing Domain Identifier (SDID). The SDID will appear in the DKIM Signature header fields, indicated by the "d=" tag. The signing entity (the owner of the SDID) is stating they will be responsible for the message.

DKIM is intended to be a value-added feature of email ... NOT a basic function. DKIM will interoperate with unsigned email, which will be treated the same as always - it will be subjected to standard analysis and filtering.

DKIM also supports anonymous email. The author of the message can remain anonymous, while the identity of the organization is verified.

An important thing to remember about DKIM is that the only semantics inherent to a DKIM signature are that the signer is saying: "I will take responsibility for this message!"

Sender reputation then finishes the job.

Next time, I'll talk a bit more about DKIM, including its design objectives and how it is used.

Labels: , , ,

Tuesday, June 16, 2009

Authenticate Part II - Is the Sender Address Real?

Some ISPs now insist on authentication ... if you're not willing to authenticate your identity, they won't even deliver your email. Eventually all ISPs will likely want authentication. Since even spammers can authenticate their email, it isn't a complete solution. But, it's a good start - why make it easy for the spammers?

Remember that there are several protocols being used for email authentication and that the protocols fall into two categories: those that deal with sender address forgery, the topic for this blog, and cryptographic solutions, which will be discussed next time.

ICANN and IANA
Let me first clarify my earlier statement that address and domain name registrations derive from the global Internet administrative authority, ICANN. ICANN stands for the Internet Corporation for Assigned Names and Numbers. It was created on September 18, 1998, as part of the move to make the Internet a global resource, rather than a US-controlled resource.

Among other things, ICANN became responsible for functions of the Internet Assigned Numbers Authority (IANA). IANA is the entity that oversees global IP address allocation and root zone management for the Domain Name System (DNS).

ICANN authorizes various domain name registrars, to register Internet domain names. ICANN sets global policy for domain names and the domain registries then manage each top-level domain.

In the case of country-code domains, ICANN assigns a trustee for each top-level country-code domain. Administration and control is then delegated to that trustee, which is responsible for the policies and operation of the domain.

So, when I say that address and domain name registrations derive from the global Internet administrative authority, ICANN, I mean that authentication can determine if a particular domain name has been properly registered, through the authorized channels.

The registries have widely varying policies regarding accuracy of information. For example, the German and Canadian domains require a physical presence or other connection to the domain, whereas other registrations are completely open. This variation somewhat diminishes the value of authenticating a domain.

Determining If a Sender Address Is a Forgery
Since most abusive email messages carry fake sender addresses, it makes sense to try and detect sender address forgery. Let's look at the three primary protocols that were proposed for this function in the past.

Sender Policy Framework (SPF) - Open Source
This open-source protocol was written mostly by Weng Wong, who combined two existing sender authentication protocols in 2003, to create Sender Permitted From, which was later renamed Sender Policy Framework (SPF).

Caller ID for Email - From Microsoft
In February, 2004, Microsoft published a draft entitled: Caller ID for E-Mail - The Next Step to Deterring Spam. I have also seen it referred to as Sender ID, as has the Sender ID Framework, discussed next. Regardless, it didn't last very long (see below), so I won't take up any more space discussing it.

Sender ID Framework (SIDF) - Combination of Sender ID & SPF
Later in 2004, Caller ID for Email was merged with SPF, to create the Sender ID Framework (SIDF). Microsoft included Sender ID framework in Hotmail, Exchange, and Outlook in 2005. It is used primarily with Microsoft products.

Standardizing the Protocols
In 2006, a total of four proposals documenting two approaches for authenticating the sender ID were submitted to the Internet Engineering Task Force (IETF) as Experimental Protocols. The community was invited to observe and comment on the success or failure of the approaches during the two years following publication. The objective was to build a consensus as to the best approach for a single Internet standard.

In February of 2009, all four were relegated to Historic Status, since consensus could never be reached on a final standard, largely due to licensing issues.

What this really means is that email service companies are forced to support multiple protocols, if they want to be all-inclusive.

Vouch by Reference (VBR) - The New Guy on the Block
In April of 2009 a new standards track proposal was submitted, called Vouch by Reference (VBR). Perhaps this one will succeed where the others have failed and become the Internet standard.

How Do You Authenticate the Sender?
Though the objective in all cases is to determine if a sending address is a forgery, the protocols each work a bit differently.

As an example, SIDF checks the IP address of the server that sent the email against a list of servers, which are authorized by the domain owner to send email.

VBR, on the other hand, permits independent third parties to certify the owner of a domain name that is associated with received mail. The certification can happen either within the email handling service or by end-user software.

VBR is a two-part protocol:
  • First, the sender adds VBR information to the email message. This info includes a list of domain certification services that will vouch for the email traffic.
  • Secondly, the receiver will query one or more of the certification services for information about the identity associated with the message. DNS is used to distribute the certification information.

Next time, we'll talk about the cryptographic solutions, most notably Domain Keys Identified Mail (DKIM), which combines some of the features of two other proposals, from Yahoo and Cisco Systems. DKIM is currently undergoing standardization, by the Internet Engineering Task Force (IETF).

Labels: , , , , , , ,

Thursday, June 4, 2009

Authenticate! Don't Make Everyone Wonder If It's Really You!

According to an article published by the New York Times in March of 2009, 94 % of all email sent is spam!!! Barracuda Networks has estimated that in 2008, spam accounted for between 90 and 95 percent of the total email. They also expect it to increase slightly in 2009. Protecting subscribers from spam is an ongoing challenge that continually changes - it is a true "moving target".

Early attempts at controlling spam focused on filtering out bad email. Unfortunately, every improvement on the anti-spam side resulted in a new approach on the spammer side. Filtering out spam has never been more than partially successful. It results in both false negatives and false positives. So, some spam still gets delivered and some good email gets dropped!

Currently, a two-pronged effort is evolving: authentication and reputation. Authentication identifies the author of the email and reputation provides a means of assessing their trustworthiness.

In an earlier blog, we talked about how important sender reputation is, in getting your email to the Inbox. We discussed some of things that can hurt or help your sender reputation, such as the number of complaints or the number of times your email is opened and scrolled through.

For the next few blogs, we will focus on email authentication and on the different approaches to accomplishing it. Authenticating or signing an email can (almost) prove you are who you say you are. It can also improve your sender reputation.

The objective of email authentication is to help prevent spam from reaching the Inbox, while at the same time allowing desirable email to get there. It's analogous to a router's access control list: drop unwanted traffic, while allowing desirable traffic.

What Is Email Authentication?
In this and the next two or three blogs, the term authentication uses the definition put forth by the Messaging Anti-Abuse Working Group (MAAWG) in March 2008. The document was entitled, Trust in Email Begins with Authentication.

Authentication is a technology for determining any of the following:
  • That an identifier is being employed by, and for, the organization (the identity) that it belongs to.
  • That a specific IP Address is being used by the organization it is assigned to.
  • That a domain name is being used by the organization that registered it.
  • That address and domain name registrations derive from the global Internet administrative authority, ICANN.
Authentication can prove who you are ... but, it can't say anything about what you are: Mainly ... are you trustworthy? This part takes an outside authority. In this case, sender reputation serves as the outside authority.

Why Does Outside Authority Matter?
As an example, if you were to print a drivers license for whatever state you happened to be in ... and a police officer pulled you over for speeding, you would probably go to jail, when he saw your fake drivers license. If, however, the license were actually issued and printed by the DMV of the state, then you would likely just get a ticket ... or maybe just a warning.

The difference is the backing authority: It says you have the required driving skills, an address where you can be found ... it implies that you are likely trustworthy, where the self-issued drivers license does NOT!

This is what authentication, when combined with a good sender reputation, implies to the ISPs who must deliver bulk commercial email, while at the same time NOT deliver spam. This is a difficult road to walk ... one the spammers are constantly digging up!

Establishing Standards
Whenever there is a networking problem to solve, everyone benefits if a common solution can be found ... a standard, if you will, for everyone to follow. There are standards organizations that exist to develop, document and publish such standards. Once a standard is finally complete, things get much easier. Customers can select products from different manufacturers and, if the standard was followed, the products will all work together properly. This is a good thing!

Unfortunately, there have almost always been competing solutions ... competing standards being developed. It doesn't matter what aspect of networking or the Internet we are talking about, there are often multiple "standards" being developed by (typically) competing companies. Clearly, there is a market share advantage to developing a protocol that is later adopted as THE Internet Standard!

Often, when various competing proposals are presented to a standards board, the final standard adopted is a blend of hopefully the best parts of the different proposals.

Today, there are several protocols being used for email authentication.

Most abusive email messages carry fake sender addresses. There are three protocols that deal with sender address forgery:
  • Sender Policy Framework (SPF) - Open Source
  • Sender ID - From Microsoft
  • Sender ID Framework - Combination of Sender ID & SPF
There are also three cryptographic solutions:
  • DomainKeys - from Yahoo
  • Internet Identified Mail (IIM) - from Cisco
  • DomainKeys Identified Mail (DKIM) - Combination of DomainKeys & IIM
Next time, we'll start talking about how these protocols work.

Labels: , , , ,