Response to Trust-based messages

In my other post in a Q&A excerpt with Dave Crocker by Investor's Business Daily, I'd like to now respond to some of my selected quotes.


Crocker: You have to create what I call a trust overlay to the existing e-mail system. Existing senders and receivers can continue to use e-mail as before... All we're doing is adding a mechanism that lets them trust who mail is from and (determine) whether that sender is trustworthy.


I agree with this.  The email filtering industry is starting to converge on reputation as a mechanism of determining delivery eligibility.  By examining what the sender has done historically, we can get a pretty good idea for what the current content of the message is likely to be.

Incidentally, this carries over to stock trading.  Stocks that have a strong relative strength compared to the rest of the market (over the past 6-12 months, at least) tend to do better over the next several months as well.


Crocker: Existing "reputation" based e-mail screening systems are based on very low-level addressing numbers that say where a server is attached to the Internet, rather than what organization is sending the message. DKIM will identify the sender.


It is true that these reputation based systems are tied to IP addresses.  In fact, some reputation systems use only an IP's historical sending record as a mechanism of determining legitimacy - that's essentially what blacklists are.

However, DKIM is not alone in identification of the sender.  SPF and SenderID both tie the sending IP address to the sending domain or organization.  Where DKIM differs is that it ties the sending organization to the content of the message, irrespective of the message's origin.  This makes it more flexible than SenderID and SPF because message forwarding can break both of those two authentication schemes.


IBD: Can you give an example of how DKIM prevents the delivery of unwanted spam?

Crocker: A classic example of spam abuse involves eBay's online payment system PayPal. Pay-Pal e-mail is often forged by hackers or other bad actors. They might send it as "paypa1.com," a so-called "cousin" domain that looks like the real one but is intended to confuse.

IBD: How does DKIM help?

Crocker: If I have a DKIM signature that's signed (with the string for) PayPal.com then it was really signed by PayPal.com and should be received.


This is where I part ways with Crocker.  IBD asked how DKIM prevented delivery of unwanted spam, and the response was how Paypal could use DKIM to get their mail delivered to the end user.  The question wasn't about how DKIM helps get good mail delivered, it was about how it could stop spam.

I will get to this in more detail in a future post when I discuss DKIM and Sender Signing Practices (SSP).


Crocker: First-time senders wouldn't have their messages erroneously blocked. E-mail would also be marked as "definitely good" rather than "possible spam."


This is actually a good idea but there are some problems because this isn't defined as clearly as I would like.

  1. The sender is a first-time sender relative to whom?  

    Let's say you and I have never spoken before, and I send you a message.  I haven't sent you a message before but I have sent your friends and my friends plenty of messages.   I have a good reputation with them.  My reputation should carry over to you (friends-of-friends) but then you have to check my reputation that someone else is managing.  This means you have to use someone else's reputation management infrastructure.

    An example of this is our Frontbridge olden days when we used to use Senderbase's IP reputation portal.  It was good at the time, but then we built our own internal one.  We've pretty much abandoned Senderbase now because we trust our own reputation database rather than someone else's.

  2. What if the sender is a real first time sender?

    If I have never spoken to anyone before, ever, then I wouldn't have a reputation.  I may sign my messages with DKIM, but without a reputation built up there is no guarantee that my messages would be marked "definitely good" rather than "possible spam."

    At least, in my opinion, they shouldn't be marked definitely good without an existing reputation simply because they are authenticated with DKIM...