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:
There are some intricacies involved in this:
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.
PingBack from http://spamsoftware.womensdiscountperfume.net/?p=21
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.
DQ
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.
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 Example.com for The-original-From-comment", where Example.com is the domain part of the Return-Path (note that the actual From mailbox address is left intact in this example.)