Well, the mystery of DomainKeys is now public.
Email spoofing - the forging of another person's or company's email address to get users to trust and open a message - is one of the biggest challenges facing both the Internet community and anti-spam technologists today. Without sender authentication, verification, and traceability, email providers can never know for certain if a message is legitimate or forged and will therefore have to continually make educated guesses on behalf of their users on what to deliver, what to block, and what to quarantine, in the pursuit of the best possible user experience.
DomainKeys is a technology proposal that can bring black and white back to this decision process by giving email providers a mechanism for verifying both the domain of each email sender and the integrity of the messages sent (i.e,. that they were not altered during transit). And, once the domain can be verified, it can be compared to the domain used by the sender in the From: field of the message to detect forgeries. If it's a forgery, then it's spam or fraud, and it can be dropped without impact to the user. If it's not a forgery, then the domain is known, and a persistent reputation profile can be established for that sending domain that can be tied into anti-spam policy systems, shared between service providers, and even exposed to the user.
It'll be interesting to see how this is received.
I haven't looked closely enough at the proposal yet to pass any sort of opinion. I do know some of the folks involved, so I'm quite hopeful.
Posted by jzawodn at May 18, 2004 03:47 PM
It's something, but how useful is this until it's essentially universally adopted? Seems not very. I see it as quite a while before AOL will adopt this on their outbound mailservers, and then let's assume spammers just send through cheap ISP accounts they keep setting up (which a lot of them do). The domain would be valid. It'd make it slightly easier to shut them down, sure, but it's not terribly difficult right now anyway. Another big chunk of spam comes from cracked machines, so obviously these will also have the legit key... so those will slip by (and conceivably, can never be dropped--once the machine is recovered and secured, it still needs to send legit email.)
I agree the from: header is the most important, but it doesn't seem like a comprehensive solution, and dependent on near-ubiquity before it reaches a significant effectiveness. Not that that's a reason to not try, but this particular scheme seems far from a panacea.
It appears, at face value, to continue to have the same problem I predicted it would have: It doesn't in any way solve the travelling salesman problem.
The travelling salesman can't actually access the "official" MTA (due to, say, prolific tcp/25 packet filtering like most dial-up ISPs do these days).
so, you have to either:
(a) trust the salesman with the "single private key", in which case every time an employee leaves you have to redistribute and set up a new public/private pair, or
(b) you have to maintain a huge database, in DNS, of the various public/private keypairs assigned to each of the travelling salesmen (possibly very very many).
Add to that the fact that you have to accept the DATA payload (and the resulting bandwidth) before you can deal with the message, and it seems like a non-starter.
Derek,
There are other options for the travelling salesman that are far simpler. VPNs are cheap these days, and I would recommend that as option #1. #2: SMTP-Submit on port 587. You can easily add SSL to this for securing your mail. #3: corporate webmail via SSL.
I agree with the criticism about having to accept the message before being able to determine whether it's spam, though. This is certainly not good for bandwidth, but it is good for my inbox in the end.
Scott,
How is "making the user change to add additional layers of complexity to the session" defined as "simpler"... this is some definiton of "simple" I wasn't previously acquainted with. :)
Lots of places use different (read, non-UNIX) mail applications that can't necessarily handle using the MSA port, etc. We've been telling people for years "if you're on $DIAL_UP_ISP, you should be using the mail-server of $DIAL_UP_ISP", and this requires undoing the years of work we've been drilling into peoples' heads in the name of fighting spam.
Like I said... the combination of "not solving that problem" while requiring acceptance of the payload makes it a non-starter to me.
The salesperson had better be using his VPN vlient to send email from his company's servers. That's just a reality of corporate security. As Scott said, there are several ways to do this. There is little valid reason for a user to send email from a different domain. I think you've been away from salemen for too long, D. :)
