My thoughts on antispam
02 09 07 - 01:49 Used tags: design, mail, spam
Everyone knows spam today. There are estimations that it makes more than 90% of all email traffic. Judging by my personal spam collection, spam is on constant increase.
I have always filtered spam out of my inbox by hand. I played with almost all antispam technologies out there today and haven't found any to be perfect. They're either too hardware resource intensive (long list of daily updated regex rules) or too users' time intensive (manual training of statistical filter). Two tecnologies that made me think some more were greylisting and one-time email addresses.
The only way to stop spam is to increase the cost to spam, which basically means to decrease its efficiency. I came up with a concept that does this extremely well, while offering end user perfectly transparent and easy-to-get-rid-of-spam mail expirience.
First of all, this concept cannot be implemented everywhere immediately, because MUA has to be able to make modifications to MTA's alias table in a reliable and trustworthy way. The most obvious places to implement would be webmails and I hope the authors of various mail clients will pick it up too. Also, all mail should be treated as spam by default unless it's delivered to a know alias. This means that a maibox protected with this method is useless for giving out on business cards and such :) Effectively it's a "you cannot write me unless I write you first" mailbox.
Here's how it works:
Imagine having an user at example.com with user@example.com mailbox. This user writes a mail to johndoe@company.com. User's MUA notices that user didn't have any previous communication with johndoe, generates a unique string and replaces user's from address with this uniquestring@example.com in user's mail. It also places this uniquestring in MTA alias table, pointing it to user+johndoe_company_com@example.com mailbox. Finally, it creates a (imap or local pop) folder johndoe_company_com in user's mailbox.
When John Doe replies to user's mail, the reply goes to uniquestring@example.com and ends in this folder. Then, when user replies to it, MUA notices that user has already written to johndoe and uses the same uniquestring as from address.
Then when spyware on johndoe's windows machine picks up user's mail address, it picks up uniquestring@example.com. What happens is that all spam starts coming to a folder created for johndoe. User knows two things: that johndoe's computer is infected by spyware (and can tell johndoe about it) and that he can simply get rid of the spam by telling its MUA to forget this alias for johndoe. All the following spam will be dropped either into user's inbox (or even better, trash by default) or bounced by MTA (unknown user), depending on the whole config.
MUA also has to offer an option to generate such uniquestring (and alias table entry and folder) without writing out a mail, when user wants a contact email to put in a web form, for example. Or to start a mail dialogue with a friend who already has such system implemented.
Some thought should be given to how uniquestring should look like. We don't want spammers to sort them out easily from other email. We want them to mix with other legitimate looking mail addresses and clobber spammers' lists, making them slowly less and less useful. Also they should not offer any method of figuring out users root mailbox addres (or posting to that address should be disabled either by MTA or mail storage agent).
I would be very interested in any shortcomings you can spot in this concept. I plan to roll it out (all manual) on one of my mailboxes, just to see how it works in practice.
One comment