I'd now like to post something about the inspiration for this whole series on authentication.  I'm not done with DomainKeys, I still have to post a little bit on DKIM and one other authentication mechanism, and then this series will be done.  But I need to boast about one of my achievements.

Back in June, a customer called us up and complained that spoofs were getting through.  They were getting messages "from" the organization that were actually from spammers.  The SPF check was failing, said the caller.

It turns out, what the spammers were doing was spoofing a MAIL FROM header with a domain that doesn't do SPF (such as Yahoo) and then putting the organization's domain in the From: address in the message headers.  So, what was happening is that the SPF check was returning SPF None and the message was tricking their users into thinking that they were receiving mail from the inside, when in fact it was a spammer trick.

We didn't have much defense for this accusation.  SPF doesn't cover the From: address, but it was the one that needed to be protected.  The customer complained that they had SPF records set up but spammers were evading our authentication mechanism and that they were unhappy about this.  I had nothing to say, they were right.  What do we do?

I looked into SenderID (at the time I didn't understand DomainKeys or DKIM).  SenderID protected against spoofing the From: and Sender: address, depending on one's implementation.  But, I resisted actually implementing SenderID.  For one thing, I think that our entire platform is going to move to Exchange Edge in the future, so we get SenderID for free (that is, it is built into Exchange).  I didn't want to duplicate the effort.  For another thing, I wasn't sure I wanted to move off of SPF onto SenderID.  I understood the performance and risks, as well as the limitations, of SPF.  I didn't know the risks so well with SenderID.  I wasn't sure I wanted to substitute one for the other.

That night, and for the next few days, I went home and poured over the documentation for SPF and SenderID.  That is when I started doing this blog series.  I then came up with a solution that internally we have dubbed From Address Authentication.  In writing this post, I think I need a better name because the acronym for the original name is FAA, which collides with the government namespace.  Since I invented our solution, I am going to call it Terry's Message Authentication, or TMA.

In my next post, I will go into the design.