It truly is time for a Challenge / Response system to be widely used. Most criticisms of this system generally fall into 3 categories.

1. That unless the person using Challenge /Response automatically puts the email address into a white list as they send it, they and their recipients may never see the emails if both use the system. Well, make that an automatic feature, and in fact, I haven’t found 1 system that doesn’t do that.

2. It’s a hassle for the sender to do the 1 time confirmation. Big deal! If you’re writing me an email, you intend for me to see it, right? So why won’t you take an extra 10 seconds, 1 time, to make sure I do?

3. That spammers will figure out a workaround. Maybe they will, but since they generally use bogus addresses, this is not likely as they will never receive the challenge response. If they start using their real addresses, it’s easier to shut them down.

If I don’t know you, I don’t want your email. I’ve never received an email from a stranger that I couldn’t do without.

People need to have more respect for themselves and their own email box. I’m not so lonely that I need emails from strangers. I don’t have time even to respond to all from those I know!

Sending me an email is a privilege, and one that needs to be earned. If I don’t know you, don’t knock on my door, don’t call me on the phone, don’t send me an email. If I know you, than you will be welcomed with open arms.

Lastly, for those choosing C&R services, I recommend using one that automatically authorizes addresses from outgoing mail. That way, when you email tech support for help, their reply won’t be challenged. Problem solved.

Over in the other responses you showed some lack of knowledge of the significance of the difference between bounce emails and SMTP rejections, which result in “returned mail” notices to the sender. Both should turn up in the mailbox of a legitimate sender but the difference between the two is great.

The bounce messages go to the from or reply-to address. Which is usually forged in spam, so the bounce goes to the wrong place and annoys an innocent.

The 550 can’t deliver responses go to the sending mail server, which can’t be forged.

So the 550s have a minimal chance of harassing innocents while the bounce messages will do so most of the time.

I want to thank the folks here for a good discussion, which led me to write the above. It’s been fun.

Joe VIP logs into an airport Internet kiosk and sends you an
email that says “We need to talk. It’s urgent, but I’m on the road today. I’m getting on a plane in 20 minutes. My cell number is 555-123-5555. Please give me a call at 9 PM your time.” Joe sends the message, but doesn’t hang out at the kiosk long enough to get the challenge message. He doesn’t find the challenge message until he logs in from his hotel room at the end of a long day flying. You never got his message. You’re not going to call him. You’re not in the office any more, so even if answers the challenge right away, you’re not going to get the message until tomorrow morning. Conversation doesn’t happen. Big deal doesn’t happen. Value of email as a tool for critical business communications goes down the tubes.

-rich

mailsnare.net, which gives their users the option to use TMDA

bluebottle.com

This way you can avoid using mailblocks.com, which as you say “annoyingly has a pop-up to warn people away from any browser except Microsoft�s, and which even more annoyingly is enforcing patent protection against other challenge response systems.”

Good luck,
Nancy
maintainer of a massive page about IMAP and IMAP Service Providers

Nick and Dave: Having talked up TMDA for a couple of days, I feel compelled to talk about the bad parts now.

• It’s a server side thing like SpamAssassin, but there are features to make it useful to a client machine (a CGI to examine the pending queue, and a proxy SMTP server for outgoing mail).
• It’s been under active development with frequent changes. That having been said, it’s always been very stable for me, and it’s nearing a 1.0 release (the author has done a last call for new features).
• My experience configuring it was a bear, but a lot of that was probably due to me using an out of date Debian package while reading up to date documentation. Still, there seems to be a lot of details to pay attention to.
• I’ve heard reports that some users find the challenges confusing (thinking they’re bounce messages). Knowing that, I rewrote the challenge text.
• I sometimes worry that the challenges themselves are being filtered out as spam before reaching legitimate senders, but I have no proof one way or the other.

Having gotten that off my chest, I feel good repeating that TMDA made a huge difference to my email. I think it’s a great piece of software.

Thanks for reading.

It was supposed to sound like a challenge-response system. I wrote it as I did because I knew that you like them.:) What I described is practical for Windows users who don’t have TMDA available, since it only requires some mail rules and a spam identification and tagging tool.

I wouldn’t recommend expiring a password the day after issuing it. Better to change it in advance and allow a week or more of overlap. If you do need to expire it, you’ll annoy the human by sending them a reply with a new password in it.

There are many ways of doing it but it appears that we may have some agreement on the desired properties:

1. Don’t bother to challenge for mail which is from an IP address or otherwise indicates that it’s almost certainly spam. That protects most innocents named in From addresses.

2. Extensive whitelisting for people you know, as automatic as possible.

3. A convenient way for humans to ensure that their first email gets through, with a magic word of some sort. Anything which can’t be harvested easily. I use quite a lot of magic words: product names and such. Mention one in the subject or body of an email to me and you get through the spam filter.

4. If you get a significant false positive rate, challenge the middle ground to give them a chance of getting through.

Is that an acurate summary? Any desirable features I’ve missed?

There are some really nice features in the TMDA outgoing message featue set (expiring addresses and such). I’ll point the lead SpamPal developer to that and suggest adding some of them to the outging SMTP side of SpamPal. Thanks for mentioning this aspect of it.

I’m with Nick. TMDA sounds and reads better than anything I’ve read about any other challenge-response system.

I also appreciate your respectful tone. We could all use more of it.

[email protected]

I really like the proposed anti-spam system you describe. However, I can’t help but notice that it’s a lot like a challenge-response system!

Make a few changes to the system I use now:

1. Conservative filters at the front which drop what they find. (Say, SpamAssassin with the threshhold set high.)
2. Let especially low scoring emails through without challenge.
3. In the challenge email include an expring address that anyone can send to and reach me without challenge.

This works just like your proposed system (give or take how many messages fall into the “challenge zone”) except:

• I can’t post a password to a web page. Darn.
• A challenged user is whitelisted forever and never faces a challenge again (instead of whenever I change passwords).
• A challenged user who wants to email me from a different account still can (using the expring address instead of a password), and for as long a time as I choose for the expiration.
• Users never get a six-month-old password that will change tomorrow.
• Only challenges sent at the same second would have the same expiring address, so I can close off one that was abused and still leave the others open.

Come to think of it, I can implement the password in the subject in this too without too much trouble. That takes care of the one drawback.

How do we guard against a spammer forging an innocent’s address and flooding them with password-filled challenges from a middlin’ spammy email? I guess we can’t; the goal really was just to cut that down a little.