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

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: , , , , , , ,

0 Comments :

Post a Comment

Subscribe to Post Comments [Atom]



<< Home