Sender authentication part 32: TMA Explained

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.

Comments (4)
  1. DQ says:

    Why do you exempt SPF pass from this?  My SPF knowledge is a bit rusty, but I believe someone can SPF pass and still have a forged From: header.


  2. tzink says:

    This is true.  But passing an SPF check and then failing a From: check would cause more false positive harm than we would like, in my opinion.  

  3. Ale says:

    According to RFC 2822, the Sender header is only required in case there are multiple From mailboxes (section 3.6.2.) Thus, it is somewhat unreliable to assume that all mailing lists include one. In facts, it is perfectly legal for a server to forward a message replacing just the MAIL FROM with anything referring to its domain, e.g. an SRS-generated mailbox, keeping the From and any Sender mailboxes as they are in the original message, and possibly adding a set of Resent headers (section 3.6.6.)

    Plain human-to-human messages usually have matching From and Return-Path headers. Currently, most of the spam I see follows this trend (although in the past it routinely behaved differently.) Most bots put a matching domain in in From and Return-Path, but some fail to do so. Mailing lists and other forwarders are the relevant exceptions.

    As we are talking about spam that has already been accepted by a server, the only point is to make the forwarding visible to the recipients. Many mailing lists do that by repeating the name of the list in square brackets at the beginning of the subject. In case the Return-Path is not shown that way, a mail delivery agent might add it as a comment in the From header. For example, one might display "forwarded by for The-original-From-comment", where is the domain part of the Return-Path (note that the actual From mailbox address is left intact in this example.)

Comments are closed.

Skip to main content