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.
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.
PingBack from http://msdnrss.thecoderblogs.com/2007/12/29/response-to-trust-based-messages/