Feedback on EmailObfuscationPlugin

-- StephenGordon

Thank you Stephen for sharing this Plugin with the TWikiCommunity. And thanks for documenting the PluginBenchmarks.

-- PeterThoeny - 17 May 2006

BTW, I never heard of "obstufication", is this another word for "obfuscation"?

-- PeterThoeny - 17 May 2006

I believe they are used interchangeably (though yes, obfuscation is more correct).

-- StephenGordon - 17 May 2006

I've updated and uploaded the zip with the correct spelling anyway, do you think you could rename the topics for me please.

-- StephenGordon - 17 May 2006

OK, I renamed the topics.

I also added you to the TWikiCommunityGroup so that you can rename/delete content. Please review the comments in that topic on how to handle the additional responsibilities.

-- PeterThoeny - 17 May 2006

Hi Stephen, a warm thanks from my side for your contribution.

But I think your plugin does not work properly on a TWiki4 install, as far as my initial tests show. TWiki4 already has two email obfuscation schemes that translate

micha@foo.bar

into either

<a href="mailto:micha@fooNOSPAM.bar">micha@fooNOSPAM.bar</a>

or into

<a href="mailto&#58;micha&#64;foo&#46;bar">micha&#64;foo&#46;bar</a>

if the anti-spam email padding $TWiki::cfg{AntiSpam}{EmailPadding} variable is disabled.

Enabling your plugin gives a

<a href="mailto&#x3A;micha&#x40;fooNOSPAM&#x2E;bar">micha&#x40;fooNOSPAM&#x2E;bar</a>

that is, it more or less combines both: email padding and recoding. Note however that your plugin does nothing if the engine's email padding is disabled as the mailto pattern already is obfuscated.

Anyway.

I would like to propose a different solution to obfuscate email addresses as the key string (mailto) is still in place giving strong evidence that there's some email address around. Note that twiki's and your obfuscation function have an easy to guess reverse function and rest assured that webcrawlers are pretty clever about all of those patterns.

The issue of obfuscating email addresses has been discussed on the web multiple times and the only solution is to take out any trace of an email address on the server side first and rewrite the document using javascript on the client side. This works out on the assumption that webcrawlers will not run a javascript engine on every page they harvest.

As things are, I have implemented that as part of the NatSkinPlugin already but was too lazy to externalize that and make it a plugin of its own. Maybe it is time to do that now. Stephen, if you like I can give you that code. Please contact me via email about your thoughts.

-- MichaelDaum - 17 May 2006

TWiki already has two email obfuscation methods in version 4 only if you are up to date with SVN, otherwise only the addition of NOSPAM is present.

CDot suggested I put the plugin up for people who aren't.

As to mailto still being present, that's only with the default setting. You'll find if you set the ESCAPELIST to \000-\177 (or higher for that matter) all characters in an email address will be converted to HTML entities, including those that make up the 'mailto:' string, if present.

-- StephenGordon - 17 May 2006

Just went back and double checked this and yep, as I had thought on a vanilla 4.0.2 install with both $TWiki::cfg{AntiSpam}{EmailPadding} and my plugin off absolutely no obfuscation occurs at all, the address and the mailto: that go with it appear in as plain text.

• Basically I'm saying that this: "Note however that your plugin does nothing if the engine's email padding is disabled as the mailto pattern already is obfuscated." is false on a vanilla 4.0.2 install that hasn't been upgraded off SVN (and I assume before this).

-- StephenGordon - 17 May 2006

Oh, ok. Sorry, I was evaluating that on a svn install. Nevertheless having a javascript based solution would be better, don't you think?

-- MichaelDaum - 17 May 2006

Probably, I just figure this is a good start (certainly good enough for my purposes on a relatively low traffic site). It was also a handy way for me to write a very basic plugin to get myself started in perl which I'm not overly familiar with.

-- StephenGordon - 17 May 2006

Some Name seems not to work (a simple name@examplePLEASENOSPAM.com is properly encoded though).

-- WolfgangSlany - 24 May 2006

I can't seem to duplicate that (both forms work properly on my install).

-- StephenGordon - 29 May 2006

It also works for me now --- I don't know why it did not work the last time and I cannot reproduce the problem. Thank you anyway, and in particular for the valuable plugin.

-- WolfgangSlany - 01 Jun 2006