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 "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.
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.
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.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...