How to make sure you are not bothered by email

by Volker Weber

You forward your perfectly working mail address somewhere else:

From: xxxxxxx@clearframe.com
Date: 17. Juli 2007 18:20:24 MESZ
To: vowe@vowe.net
Subject: Please validate your email address.

Please reply to this message with the following code in the subject line:

E51DEFE6AC3EC56D8525731B0058480F

This will add vowe@vowe.net to xxxxx xxxxxxx's list of approved correspondents and deliver your original message. By responding, you will be permanently added to the approved correspondent list. We appreciate your assistance in reducing SPAM.

xxxxx xxxxxx's email system is being protected by cBlock powered by Clearframe.
Visit http://www.clearframe.com for more information on protecting your email system.

This is not only a tedious process for anybody who wants to send you an email. You also have to make sure that nobody can find your domain on DNS.

Comments

For shame! It was me (hopefully you're OK with me outing myself here :-) )

To defend myself... this solution works best when 1) you're doing reverse-DNS and other anti-spam measures before this "verification" process is reached and 2) you're "white-list" is configured with all of your friends, clients, etc. ;-)

Sadly, right now, we're redoing a few things on the networking end so the reverse-DNS didn't capture that this didn't come from a valid server for said domain (it didn't come from "vowe.net" btw as far as I can tell here - on the road and checking my email, so I'll get you more of a report on that one later - if you want to elaborate on where it came from though, please feel free to!)

As for you not being in my whitelist, I'm pretty sure you are under the vowe.net domain - which would have gone through fine.

And I'll admit, this solution/product isn't for everyone - but it does weed out almost all of the garbage while also giving you a queue for "blocked" email that you can read and make sure that you're not missing anything (which is where I picked up your email from BTW). I happen to have it turned on to block/notify/verify... which is just one of the options.

I don't want to post-jack nor do I want to be one of those "my product was mentioned, let's start a commercial on someone else's site!!!" (see Elgort's ISV discussion and notice that it seems like most every ISV who read his blog post stepped in to tout their wares... but I digress...) so I'm not going to riddle this post with links back to the product site, etc.

I will however, ask for input on what your thoughts etc. are on this process. Is challenge/response verification good for the business world? Our customers love it (when it's implemented properly) but I do worry about the posibility of "adding to the problem".

Thoughts everyone???

Chris Toohey, 2007-07-17

I think it's perfect, if you don't want to be bothered by email. ;-) And go ahead and link wherever you want to.

Volker Weber, 2007-07-17

This method is just great for sites (such as Xing) when people use an email address like that to create an account and then complain violently to tech support that the sign-up process sucks. (Yes, happens a lot.)

Hanno Zulla, 2007-07-17

I don't know what it is... maybe because I worked with a few "snake-oil-salesmen" in my past, but linking about on other blogs just doesn't sit well with me...

Maybe that's why I'm not a sales person though... ;-)

Is there really a difference between this method (challenge/response) and the commenting functionality on this site (and many others)? You're asking for a validation before posting - communication isn't as easy as click-publish - but requires that the user go that one extra step.

And this is *only* when they meet a certain finite criteria - 1) the email address is not found in your sent folder, 2) not in your whitelist (which we happen to integrate with other nabs, CRM solutions, etc. so it's not as "individual-maintained" as it sounds...) and 3) has to (typically, again, we're moving some things around this week) get past reverse-DNS, blacklist, RBLs, and a few other hurdles for the typical spammer.

LinkedIn (where the email-in-question came from) appears to spoof the originator address (again, checking from webmail so I can't really tell for sure until I get back to the office) as something-other-than-vowe.net (in case that's not a domain you want to publish here...). If that's indeed the case, I would not have gotten the intended email due to our normal anti-spoofing checks...

... but I'm not saying I don't want YOUR mail V! ;-)

Chris Toohey, 2007-07-17

Chris: There are major differences between Turing tests for blog posting and CR for email. Email is asynchronous. You send, and you leave, and you don't come back for hours. Blog posting you click, and you wait for a response, and if the response is a challenge you click again. This is not just a difference in process. It is a difference in expectations.

But there are other big differences. The major ones are that CR for email doesn't really work reliably; it creates problems for automated systems that expect their email to get through to you and can't respond to every type of challenge that has been invented; it creates collateral damage in network traffic and misdirected challenges -- and it is just plain inconsiderate of those who pay the price for that collateral damage.

And very simply: it doesn't scale. It works beautifully for a few people who have adopted it, particularly those who truly are important enough for people to bother with answering the challenge. (There's a very small number of people -- a retired high-ranking IBM executive happens to be one -- whose challenges I've ever accepted, or would be willing to accept.) But it can't work for the masses. If it ever did scale, spammers will find ways around it. (You don't have to be a genius to find ways to create pairs of addresses that are likely to be on each others contact lists!)

As the last resort, after all else fails, CR is still a bad way to deal with spam. All the same problems apply. They're just less frequent -- but even this could not scale to mass usage. The last resort should be up to you, the recipient, to deal with. Making your problem into a problem for the sender is, IMHO, not the way to do things.

For more detail, see here.

Richard Schwartz, 2007-07-17

For a while this has been the only available spam protection offered by my provider. And - it sucks. The biggest problem is that people don't understand what they have to do to get their mail delivered to you. They just plain don't understand and delete the mail.

For business puposes... What a mess!

Fortunately there are much better mechanisms today and my provider decided to switch to one of the smarter methods.

Benjamin Stein, 2007-07-17

@Rich:

Well, it's a tough one. I agree with you on each of your points to an extent. This process can be costly/chatty for an environment that's not configured with a CR solution in mind, and there are those individuals who will feel as though they can't be "bothered" to respond to a challenge, AND spammers will likely find ways around ANYTHING that you do to block them - often at the extend of impairing legit email traffic.

And I understand the blog/email experiences are different for CR implementations.

But as much as I agree (as I mentioned, I worry that I'm "contributing to the problem" sometimes...), I have to say that I've found - in my customer environments - that when a solution like this is used at the 3rd or 4th layer of anti-spam, then it's a great recognition system.

The CR is only triggered (and I can't talk about ALL Challenge/Response solutions, but only cBlock) when my it meets a certain admin-defined criteria - to recap the standard configuration: email address not found in the sent folder, email address is not found in the user's CR log (whitelist/blacklist), and email address not found in the user-or-company defined address books. Again, it's a matter of architecting an environment where such a solution makes sense...

1 - Reverse-DNS/Anti-spoofing
2 - External RBL
3 - Internal Blacklists/Whitelists
4 - Challenge/Response Solution

That's an ideal setup for an environment wherein you're checking all possible spoofing and such before an email even gets to your CR-based solution - which, for cBlock - goes through another 3 checks before I send a CR email back to the originator. In addition, we can opt to allow the email message to still deliver to the intended recipient but reside in a "pending confirmation" queue - in which a user can check and auto-whitelist/blacklist a given address or domain.

We really didn't want to add to the problem, and I know the pitfalls of most email solutions that do just that in the name of saving the customer some unwanted V!agra ads - and we're desperately attempting to not follow in their footsteps.

It's not a perfect solution - I don't think any solution is - and I'm not the type of person that will blindly defend a product that happens to be put out by my company JUST BECAUSE it's put out by my company. It's an evolving product though... and something that I think can help out customers that are sick of the spam and that don't want to contribute to it themselves. If it gets to the point where it does "only add to the problem", I'll be the first to look for another way of addressing the spam issues that affect my customers and EOL cBlock!

If there are better ways, I'm all ears. And Rich - please take my comments for how they are intended - open discussion with other geeks on a topic that I happen to take interest in.

Chris Toohey, 2007-07-17

Even worse, Chris. I could not send the response to the challenge, because clearframe.com does not resolve at my ISP:

Volker Weber, 2007-07-17

I've got to call you on your claim of "checking all possible spoofing", because one look at Chris Linfoot's blog archives indicates that there are plenty of other successful strategies for detecting spoofing.

Anyhow, in addition to the type of header analysis that Chris Linfoot employs so successfully, there's lots of stuff written about the better ways in terms of technology. Not enough, obviously, given that the major vendors are of course keeping the real details of the best stuff (heuristic analysis, fingerprinting, etc.) proprietary, but quite a lot still. One thing that is clear to me about these better technical ways is this: scale matters. The major public mail services and the major anti-spam service providers benefit tremendously from the volume of mail that they process, which is why the rate of spam getting into gmail accounts is so extaordinarily low. IMHO, you can't really replicate that in a solution that lives within the walls of one company.

But then there's the better non-technical way, and that's very simple to explain: just don't make your inbound messages into somebody else's problem! I.e., Anything you can't identify via your preliminary checks gets filtered by the white lists, and anything that fails the white list test goes into the user's "Junk" (or "Pending Approval") folder. The intended recipient then decides whether to deliver the message and whitelist the sender, or not. And why should it be anybody else's responsibility to do this? Why is the recipient's time more valuable than the sender's time?? Or more importantly, why is it more valuable than the time of some unknown poor schmuck whose address has been forged into the header of your spam (and probably a million others!)???

As far as I'm concerned, no matter how you cut it down by putting it at at the end of the processing chain, and no matter how you justify it, CR always comes down to making your problem into someone else's problem. Sometimes you make it the problem of the actual sender. Lots of times you make it the problem of the poor schmuck who has been joe-jobbed And at other times you make it the problem of your server (or other servers if you relay) to discover that the challenge is either unroutable, or undeliverable once it is routed -- and bandwidth is wasted in both cases, though more obviously in the case where it actually routes to a legitimate server only to find that the forged address doesn't exist on that server. In all cases, it's the wrong thing to do.

In a word, making your problem into someone else's problem is just rude.

I mean nothing personal by this, Chris, and I hope very much that you don't take it that way. It's not the person being rude, it's the technology. CR is seductive in its apparent simplicity, but its core idea is that it is ok to make managing your white list into someone else's problem... and it's not ok.

Richard Schwartz, 2007-07-18

Ooops. Forgot to address that last response clearly to Chris.

Richard Schwartz, 2007-07-18

First off Rich - I am totally not taking any of this personally. That's the best thing I think about our community - you can have these discussions in which we all feel strongly one way or another - and you can leave such discussions hopefully both absorbing your fellow geek's standpoint (whether they are successful in changing your mind is not the point sometimes...) to allow you to grow as an individual and hopefully get the opportunity to buy that fellow geek a drink afterwards. I think it has to do with the mutual respect that we all have for eachother here.

And I totally agree - putting the ownership on the originator for maintaining YOUR whitelists is less-than-brilliant. That's the big problem. It if helps, our CR product does allow for conditional sending of CR emails - so you don't have to turn that option on if you don't want to really - it's up to the company/department/user/etc. After this discussion, I may very well disable that feature in my configuration and stick with the "Pending Approval" queue - only implementation. As I said, I don't want to really add to the problem. The good news -- I know that my product gives me such options ;-)

We're actually going back-and-forth with this at the office today - so at the very least, I have to thank both you and Volker for bringing up some really good points.

And speaking of Volker....

One of the "networking" things that we were addressing was a change in our DNS. That's most likely why your ISP couldn't resolve the domain.
*Hopefully* it's all working now (or will within the next few hours).

As an aside, I'm curious.

As I've mentioned, we do have customers that use the CR options and we do have two customers (that I can think of off the top of my head) that do not (rather opt for the individual "Pending" queue review).

Do you think that an ISV should regulate a product feature based on the potential abuse of said product feature? For example, let's take a CRM solution (which, we have - so this is a real-world example if you will...).

Our CRM solution has an integrated HTML-email Mass Mailer with Mail Merge capabilities (ie., = Chris). Now, this is currently being used by one of our customers to - and quite brilliantly - send a given customer an email (upon their request) with a unique-to-the-recipient e-coupon for usage in one of their stores. Now, said customer uses the solution in this manner, but another could start a mass-mailing (read: spamming) campaign using our product.

I feel like I'm asking if it's the gun manufacturer’s responsibility to make sure that people don't gun themselves down in the streets... but what are your thoughts on this?

Do we take away the ability for Challenge/Response messaging whitelist maintenance or mass-mailing capabilities from our products just because someone could use said functions for nefarious means?!

Chris Toohey, 2007-07-18

First of all, I'm not taking the bait on the gun manufacturers thing. It can lead only to trouble ;-)

Clearly, I don't believe the general proposition that products should be taken off the market if they can be used for nefarious purposes, because there could be no email systems, no programming languages, no MS Windows... Hmmm... that last one I'm not so sure I'd oppose taking off the market ;-)

With respect to a mass-mailing program, unless your offering is a distributed bot-net mass-mailer/controller that offers advantages over the existing ones that are already in use, then I don't think there's much ethical question about it. And if it offers automated management of opt-in (with confirmation by emailing a unique link), and opt-out (with enforced checks of any imported lists against an opt-out database that can't be purged en masse), and it comes with a nice white paper on responsible mass-mailing, then there's no ethical question at all.

But CR email systems, on the other hand, when used correctly and as responsibly as possible, are still IMHO problematic. I know there's a market for CR systems, but I would not build one. I would not use one. I would not promote its use by anyone. I would work to educate the market about fact that CR is based on premise of rudeness, that it causes collateral damage to others, interferes with timely communications, and will be easily defeated by spammers if it ever shows signs of becoming truly popular.

Richard Schwartz, 2007-07-18

Hi,

another thing to mention: If you once responded to the challenge successfully, every spam mail sent with your address as From-address will get through. And at least with my mail address there are lots of spam mails sent. Unfortunately. (I get nearly 200 false bounces per day, so one could estimate the number of mails sent ...)

Regards,
Ingo

Ingo Schaefer, 2007-07-18

Recent comments

Robert Schneider on Typ-2-Diabetes lässt sich wohl wieder zurückdrängen #dontbreakthechain at 18:28
Armin Grewe on Yancey Strickler :: The Internet is Becoming a Dark Forest at 17:44
Till Nachtmann on Yancey Strickler :: The Internet is Becoming a Dark Forest at 16:33
Volker Weber on Yancey Strickler :: The Internet is Becoming a Dark Forest at 15:22
Volker Weber on If you build barriers, people will build around you. If you are lucky. at 15:07
Armin Grewe on Yancey Strickler :: The Internet is Becoming a Dark Forest at 11:28
Theo Heselmans on If you build barriers, people will build around you. If you are lucky. at 11:13
Tim Oliver Spielmann on Ladeprobleme mit dem Apple Smart Battery Case at 09:00
Maikel Maes on Externe SSD mit USB-C für aktuell 88 Euro at 00:38
Volker Weber on Yet another butterfly for Apple at 20:58
Bernd Hofmann on Yet another butterfly for Apple at 19:24
Volker Weber on If you build barriers, people will build around you. If you are lucky. at 18:40
Jochen Kattoll on How to find text on a page in iOS Safari at 17:53
Christian Ott on Dark mode? Light mode. at 15:49
Ingo Seifert on How to find text on a page in iOS Safari at 14:35
Ben Langhinrichs on If you build barriers, people will build around you. If you are lucky. at 14:33
Volker Weber on Externe SSD mit USB-C für aktuell 88 Euro at 13:43
Martin Kautz on Externe SSD mit USB-C für aktuell 88 Euro at 11:49
Volker Weber on Externe SSD mit USB-C für aktuell 88 Euro at 11:35
Marc Beckersjuergen on Externe SSD mit USB-C für aktuell 88 Euro at 11:34
Martin Kautz on How to find text on a page in iOS Safari at 10:56
Horia Stanescu on How to find text on a page in iOS Safari at 10:38
Thomas Cloer on Dark mode? Light mode. at 10:35
Markus Mews on How to find text on a page in iOS Safari at 08:55
Oliver Regelmann on How to find text on a page in iOS Safari at 08:23

Ceci n'est pas un blog

I explain difficult concepts in simple ways. For free, and for money. Clue procurement and bullshit detection.

vowe

Contact
Publications
Stuff that works
Amazon Wish List
Frequently Asked Questions

rss feed  twitter  amazon

Local time is 00:46

visitors.gif

buy me coffee

Paypal vowe