On a different note, is there some way to use raw IP addresses instead of URLs that could throw a bot scanning for “x”@”y”.”z” off balance without overly confusing a desirable emailer?

Another possibility is the use of email aliasing. Maintain a single account for which you keep the direct address secret. Create an alias on an email server and use that alias “au naturale” in your sites, forwarding messages sent to it on to your central account. When you start to get too much spam through that alias, create a new one and repeat. Is this a reasonable solution, or am I misunderstanding some easy-to-foil step in this process?

Finally, a comment: I notice you keep mentioning that even the most complex obfuscation methods are easily discovered and routed if someone just looks at the code. Well… since there are so many possibilities, any spammer (hell, any programmer) would be hard-pressed to write a bot that could break them all by automation. A spammer would have to look at the code personally for each potential address to be certain of even (I’m guessing) 50% success… why bother, when the spammer could just look at the email address directly as the browser renders it on the page? What I’m trying to say is, I don’t see how “they can figure out how your code works by looking at it” is a reasonable argument against javascript-powered address obfuscation. The goal of obfuscation is to necessitate a human individual’s involvement in the identification of your email address with minimal confusion to that individual… methinks a sophisticated javascript obfuscation method accomplishes that goal.

c.a.r.t.e.r@cartercole.com is the same as
carter.@cartercole.com is the same as
c.a.rter+spam@cartercole.com

so i can filter or send any form of my address to spam and know where it was harvested from

to get around this you could find addresses with gmail domain and remove everything after the + and the periods so its the clean version (unless the normal address has a period like carter.cole@dadada.com)

I also agree that, for the time being, Javascript-based obfuscation holds the most promise. It’s not a silver bullet, though, as I discuss in my post. The ATG product you mentioned (and sell on your site as a downloadable exe) is a good example. Let’s take a look at what ATG cranks out:

<script type="text/javascript">
function SLMEJMBF(A){
var S = String.fromCharCode(109,97,105,108,116,111,58,116,101,115,»
116,64,101,120,97,109,112,108,101,46,99,111,109);
A.href = S;
}
</script>
<a href="#" onmouseover="SLMEJMBF(this);" onfocus="SLMEJMBF(this);">mail example</a>


For starters, if the client has javascript disabled, it breaks completely. That means tough luck, NoScript user: no email for you. This isn’t an insurmountable problem, though; check out Philip Hutchison’s gracefully-degrading script, for example.

Second, the “encryption” you use is pretty trivial. You rely on Javascript’s “fromCharCode” method to read the munged address–so can the harvester. I added a simple function to my de-obfuscator demo to show how easy this is (it’s example 11).

If I can break this munge with a 10-line function in a few minutes, trust me: someone else already has. Granted, this gets a lot harder to beat if you get just a little trickier; for instance, you might try breaking the address down into 10 strings and then concatenate them out of order–now a simple regex isn’t enough.

But the basic problem hasn’t gone away: your server dishes out your unencrypted Javascript to anyone who wants it, no questions asked. That makes it a fundamentally bad place to put secrets.

Thanks for your comment, and good luck with ATG!

E.Hoxha

@Jeremy: “It is hard enough to get users to contact…anything that gets in the way…is too much.” Exactly. Because contact is so important, I would think this is the last place you want to put any kind of obstacle in front of the user.

You say that “spam *filtering* is a problem for your users;” I don’t see how that’s true. You offer two choices:

either to a mailbox full of crap that users’ letters get lost in, or to aggressive filtering that prevents you from seeing their messages in the first place.

But I see at least two other options:

• better spam filtering or
• more permissive spam filter settings and more “eyeball filtering”

True, manually scanning through lot of spam is a pain for you–but that was my whole point. It’s a pain for you, not your users.

Having managed Tech Support and been engaged in customer service and marketing, it is hard enough to get users to contact with queries, problems and purchases. Anything that gets in the way, including a few seconds of checking and rekeying, is too much.