Thursday, February 03, 2005
Got less junk email lately? Thought not
The CAN-SPAM act has been with us for a year now, but my inbox seems just as full of Cialis and other body-part-enhancing offers as it ever was.
CAN-SPAM gave legislators teeth to prosecute spammers once caught, but there was the rub. A lot of spammers bounced messages through several hosts and obfuscated the trail back to themselves, so while a few less careful individuals have been caught, many more have continued to spam with impunity.
Microsoft had an interesting idea, which was to introduce a "tax" for sending email - the tax being that sending email would require some kind of computationally intensive activity that would not affect you much sending email from your desk, but would limit the output of a spam house (because it might take several seconds to compute some value needed to be able to send the message, so you'd need a lot of computers to send the same number of messages, and computers cost money).
What I find most interesting about this is that a technique for enforcing it already exists in the form of digital signatures. When you take a message and digitally sign it, your email client uses a certificate containing your public and private key and uses it to calculate a large (typically 2048-bit) number called a hash code from the content of the email.
Once the signature has been computed, it is attached to the email message (just like any other attachment) and the message goes out. The receiving mail client sees there is a signature. The signature includes information about the sender along with the sender's public key that is used to verify the hash code. At that point we can say that the message came who it says it did.
You can immediately see that this has an added side benefit in cutting down on phishing scams - those emails that say they come from PayPal or eBay and ask you to enter your username and password (and heaven help you if you give it to them!)
Of course, there is a downside to this. If you have ever received a signed email you will know there is a lot more in the signature than just the public key. A lot of the metadata held in the sender's certificate is sent too, such as their name and email, and information on who issued the certificate to them. This last part is necessary to build a "chain of trust" that means you couldn't just make a certificate on your PC and use it and have people trust you - to be trusted the certificate needs to come from a signing authority such as Verisign or Thawte.
The issue with this is that all this information adds bulk to the message. That might not be a bad thing if you're trying to slow a spammer down but it also means your inbox will rapidly fill your hard disk.
I have an alternative suggestion that I called sign by reference. Instead of attaching the whole signature complete with sender certificate info, just send the signature itself (the computed hash code) and a url pointer to where the public certificate information is found. I would suggest this pointer be a domain name only, with the certificate living in a well known location just like the P3P (Platform for Privacy Preferences) XML file must be at
Because we're only sending a hash and a url (domain name) we could now get away with just storing them in the SMTP message header instead of as attachments, so the full message might look like this:
The mail client would go load the certificate from http://www.senderisp.com/w3c/email.cer and verify the signature, just as if the whole signature had been attached.
There are a raft of other things you could do with this:
At the end of the day, if there was an easy solution to the junk email problem you would have seen it by now, but I think with this proposal you can see a raft of coverage:
Post a Comment
CAN-SPAM gave legislators teeth to prosecute spammers once caught, but there was the rub. A lot of spammers bounced messages through several hosts and obfuscated the trail back to themselves, so while a few less careful individuals have been caught, many more have continued to spam with impunity.
Microsoft had an interesting idea, which was to introduce a "tax" for sending email - the tax being that sending email would require some kind of computationally intensive activity that would not affect you much sending email from your desk, but would limit the output of a spam house (because it might take several seconds to compute some value needed to be able to send the message, so you'd need a lot of computers to send the same number of messages, and computers cost money).
What I find most interesting about this is that a technique for enforcing it already exists in the form of digital signatures. When you take a message and digitally sign it, your email client uses a certificate containing your public and private key and uses it to calculate a large (typically 2048-bit) number called a hash code from the content of the email.
Once the signature has been computed, it is attached to the email message (just like any other attachment) and the message goes out. The receiving mail client sees there is a signature. The signature includes information about the sender along with the sender's public key that is used to verify the hash code. At that point we can say that the message came who it says it did.
You can immediately see that this has an added side benefit in cutting down on phishing scams - those emails that say they come from PayPal or eBay and ask you to enter your username and password (and heaven help you if you give it to them!)
Of course, there is a downside to this. If you have ever received a signed email you will know there is a lot more in the signature than just the public key. A lot of the metadata held in the sender's certificate is sent too, such as their name and email, and information on who issued the certificate to them. This last part is necessary to build a "chain of trust" that means you couldn't just make a certificate on your PC and use it and have people trust you - to be trusted the certificate needs to come from a signing authority such as Verisign or Thawte.
The issue with this is that all this information adds bulk to the message. That might not be a bad thing if you're trying to slow a spammer down but it also means your inbox will rapidly fill your hard disk.
I have an alternative suggestion that I called sign by reference. Instead of attaching the whole signature complete with sender certificate info, just send the signature itself (the computed hash code) and a url pointer to where the public certificate information is found. I would suggest this pointer be a domain name only, with the certificate living in a well known location just like the P3P (Platform for Privacy Preferences) XML file must be at
/w3c/p3p.xml. When you receive an email signed by reference, your client would check to see if it already had a valid certificate from the sending domain. If not it would request (and store) the certificate and verify the signature. For the sake of this discussion lets say the location is: /w3c/email.cerBecause we're only sending a hash and a url (domain name) we could now get away with just storing them in the SMTP message header instead of as attachments, so the full message might look like this:
Received: from unknown (HELO mail.senderisp.com) (aa.bb.cc.dd) by mail.yourisp.com with ESMTP; 13 Sep 2004 22:10:40 -0500To: Steve Saxon Message-Id: From: John Doe Subject: Sign by referenceDate: Mon, 13 Sep 2004 22:10:32 -0500X-Mailer: Senders Mail Client (1.0)Return-Path: johndoe@senderisp.comX-SignHash: rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9Hf8HHGTrfvh JhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF40GhIGfHfQbnj756YT64VX-SignOrigin: www.senderisp.comThis is the signed message bodyThe mail client would go load the certificate from http://www.senderisp.com/w3c/email.cer and verify the signature, just as if the whole signature had been attached.
There are a raft of other things you could do with this:
- You would want to verify that the signing original and sender's email were in the same base domain (senderisp.com in my example above).
- You could require the certificate's well known location to be secure (using SSL), adding another layer of computing tax to the sender. And of course, you would want to verify the SSL certificate against the sender's base domain too.
At the end of the day, if there was an easy solution to the junk email problem you would have seen it by now, but I think with this proposal you can see a raft of coverage:
- A sender can be trusted if they are in your address book (most email clients can handle this)
- A digitally signed message tells you the person that sent the message is who they say they are, which in theory at least gives the authorities someone to go after in a spam case. But there is a cost in terms of space taken on your hard disk.
- Having email clients support sign by reference would mean less weight in your inbox, while still verifying the sender
- Customer's get peace of mind of knowing the email really did come from who it says it did.
- Online shopping sites such as Amazon.com would need to sign their emails, but at least they don't have to attach the whole certificate, so their bandwidth costs don't go up much.
3 Comments:
|
Bloke, | ||
|
By Anonymous, at 2/04/2005 5:44 PM |
||
 | ||
|
While I think everyone would agree that SMTP is flawed, it is sadly ubiquitous and is not likely to go away any time soon because of the sheer number of applications using it (by which I mean not only personal client such as Outlook, but also companies that send email legitimately) | ||
|
By xmlguy, at 2/05/2005 6:09 AM |
||
| ||
|
Computational tax is interesting idea, but it would impact not only spammers but also web-mail service providers. Huge ones like MS and Google will survive it w/o problem, but there are a lot of small ones. Also different sorts of notifications would be harder to send to sites's customers. | ||
|
By Anonymous, at 2/10/2005 3:13 AM |
||
| ||
