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.

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 "," 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) then it was really signed by and should be

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.

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

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...
Comments (3)

  1. matbaa says:

    more open about this in one place would not thank us.

Skip to main content