Hacking for Christ

Have you seen "Challenge-Response Anti-Spam Systems Considered Harmful" at http://kmself.home.netcom.com/Rants/challenge-response.html ?

Any automatic merger of whitelists will fail in the long run. If a spamming company has the service, it could whitelist some spamming addresses, and pretty quickly no one can tell where they came from. And believe me, they have incentives for doing that.

I believe in a junk classification system that is more flexible than binary, though. Being friend of a friend would increase an e-mail's trust points, so that it gets marked as "possibly real". Giving the computer only two choices increases the damage when it chooses wrong.

Tiago said: Any automatic merger of whitelists will fail in the long run. If a spamming company has the service, it could whitelist some spamming addresses, and pretty quickly no one can tell where they came from. And believe me, they have incentives for doing that.

You think I didn't think of that? :-) Read again about how I suggested it works. In order for the spamming company's address to be on your personal whitelist, you need to have sent mail to that address. And why would you have done that?

Trust rings can work - just look at http://www.getoutfoxed.com/

You can trust 2 hops away, but not 3 hops - it prevents spammers from getting very far. Plus, once you realize that someone is a spammer you just kill them from your trust and the problem is solved.

But how do you determine who a message if "from"? From headers are completely untrustable and SMTP envelope senders are not much better. It is not unusual for spam to come "from" someone you know.

Another way to do the trust-ring thing is to use LOAF, which is GPL'd and available at http://loaf.cantbedone.org/ -- one of the LOAF co-authors has become rather famous lately...

Stuart: If outgoing mail (from which this information is being calculated) is being sent via authenticated SMTP through the Challenge-Response company's servers, then only the company's users can log in and send it. The company can check that the From: header being used matches the account that has been used for the SMTP login, and not create a trust relationship if it doesn't.

I say compagnies should all implement domainkeys. This means an auth smtp server, a ptr entry in the compagny's DNS. And then you are sure the sender can be trusted (except on mailing lists because they change the header portions of the emails) - from being from the said compagny. I'm wondering if mofo/moco does implement domainkeys on it's servers.

Then another auth solution is something like enigmail - but this is far too geeky.

1) joe@choicemail sends email to gerv@mozilla
2) gerv@mozilla reply to joe@choicemail message goes through

-- this is what you are suggesting in your 2nd paragraph, right?

3) Now, random spammer sends email forged as gerv@mozilla.org to joe@choicemail and the message goes right through!

BTW, PC Magazine recently reviewed a C/R system that uses subjects (> 14 char) to automatically accept replies.

http://www.pcmag.com/article2/0,1895,1963154,00.asp

Stuart: How is that problem specific to the idea of combining whitelists? The fact that spammers can forge email from people on your whitelist is a problem with all CR systems; my suggested improvement doesn't really change much.

Gerv

My reference was to your suggestion of automatic whitelisting based on outgoing email. I suppose you are right, though. If you are whitelisting based on outgoing mail from the user or web clicks from the recipient, either way, whitelisting is fundamentally broken (without spf, etc.).

In any case, I agree, C/R sucks!

I was a happy MailBlocks customer and they absolutely implemented auto-whitelisting. The majority of my friends & contacts never had to deal with self-authentication because I had written to them first. Alas, Mailblocks was bought & killed by AOL.