Sender authentication part 32: TMA Explained

  • Article

As I said earlier, I needed to come up with an authentication mechanism that protected the From: or Sender: address in the message headers.  But, I did not want to replace SPF with SenderID.

So, I came up with another solution which I call TMA.  I would implement a "lite" version of SenderID.  At first I called it sort-of-SenderID.  Here is how it works:

  1. When a message comes in, do an SPF check.  If it returns a Hard Fail, Soft Fail, or Pass, continue filtering without doing a TMA check.
  2. If SPF returns a None, Neutral, Error or Unknown, do an SPF check on the domain in the Sender: address, if it exists.  Use the return codes the same way we do for traditional SPF.
  3. If the Sender: address does not exist, do an SPF check on the domain in the From: address.  Use the return codes the same way we do for traditional spam filtering.

There are some intricacies involved in this:

  1. This scheme is optional.  Customers have to opt-in to this program and actually choose to have this enabled.
  2. Check either the From: or Sender: address, but not both.  Sender: takes priority over From:.
  3. Like SenderID, this protects against spoofing the email address that the user actually sees.
  4. Unlike SenderID, we offer no support for SenderID-specific syntax.
  5. But like many SenderID implementations, we treat SPF version 1 records like SenderID pra/mfrom records.  This is how the RFC says to treat SPF records in a default implementation of SenderID (but is discouraged on OpenSPF).
  6. But unlike SenderID, we do not check the Resent-From or Resent-Sender headers.  That was a design decision I made.

So there we go.  It's a fairly simple scheme.  It protects against spoofing the message headers, it is customer-optional so they know that they are taking a risk if they choose to use it (it's all the same problems with email forwarding that SenderID has), it only doubles the number of SPF DNS queries that it has to do, and it built on our existing infrastructure (of doing SPF checks).

This also satisfied my requirement to avoid replacing SPF with SenderID.  This scheme supplements SPF with SenderID, if customers want it.  And it only executes if the SPF return code is indecisive.

I held off talking about this for several months because the feature was not implemented.  But we finally deployed it to our mailhosts yesterday (but not our admin center, so customers cannot actually use it).  I'm not sure what the performance of this rule will be; I do know that it will definitely help some of our bigger customers with spoofing, but I also believe that there will be false positives.  I admit that, but again, it's optional for the customer and they will need to decide if the false positive issue is worth it against catching spoofs.

Let the great TMA experiment begin.

BTW, if you can come up with a better acronym, feel free.  BUT!  It has to have the letter T in it, so I can name it after myself.