In many different situations, there are problems with simply using the literal name that one person gives something. Rather than using some completely unrelated name, we devise methods of translating problematic names into something usable.

* The CeePlusPlus technique of (when compiling/linking) changing the names of methods to allow for overloading and such. One description is at the PGIWorkstationUserGuide [http://www.pgroup.com/ppro_docs/pgiws_ug/pgiug_.htm].

* The technique of (when compiling some other language to an intermediate representation, e.g., in C) building CeeLanguage names that can be mapped to the names used in the original language.

* The PythonLanguage's internal changing of __memberName to _classOrModuleName__memberName to make __memberName less readily accessible to client programmers, though its access is still just as public as always.

* UrlMangling

* EmailMangling

----
'''Ways of NameMangling email addresses to make them more difficult to harvest'''

(These just delay the inevitable. Other ways of fighting spam are needed.)

2 basic kinds: "transparent" methods that let people with standard Web browsers select-and-copy the address from a Web page and paste into email; "Turing test" methods that mangle the address but give written instructions on how to un-mangle it.

'''Turing test methods'''

See CaptchaTest.

'''Transparent methods'''

Use an href like "mailto:username@example.net" which few, if any, address harvesters will grok. Of course these only work until they actually bother to parse the HTML properly...

Use a table like
  <table><tr>
  <td>username<td>@<td>example<td>.<td>net
  </tr></table>
It doesn't make a clickable link, but you can just copy-and-paste into your email program.

Some Scheme code for mangling email addresses lives at
http://www.scsh.net/cgi-bin/wiki.cgi?CookEmailAddress

Also, you could use JavaScript to spam-proof email addresses on Web pages.

Readers with JavaScript-enabled browsers will see normal links that are clickable ''but the rest will see nothing''.

(JavaScriptAbuse deleted)

''Argh, hideous. What if your user doesn't have JS? Such promotion of JavaScriptAbuse makes me want to write a parser for the above and send it to the spammers. -- MatthewAstley''

Is this code better ? :

 <SCRIPT LANGUAGE="javascript"><!--
 // based on SpamProof Mail Script 1.0 by Joseph M''''''cLean - freeware
 // 2003-11-29: quick hack by DavidCary
 // Linktext is the text you want folks to see and click upon.
 // before_at & after_at are the text on either side of your email address's @ sign.

 var linktext = "email Patrick";
 var before_at;
 var after_at;
 // -->

 before_at = "patrick";
 after_at = "foo.com";

 <!--
 document.write("<a href=" + "mail" + "to:" + before_at + "@" + after_at + ">" + linktext + "</a>")
 // -->
 </SCRIPT>

Readers with JavaScript-enabled browsers will see normal links that are clickable ''but the rest will see:''.

 before_at = "patrick";
 after_at = "foo.com";

Is that too mangled, or could the sort of people who turn JavaScript off figure this out?

''Bah.  Why not simply username<!-- -->@<!-- -->example.com?''

Even the very simplest, transparent kinds of NameMangling email addresses seems to work, according to the report
"Why Am I Getting All This Spam? Unsolicited Commercial E-mail Research Six Month Report"
March 2003
http://www.cdt.org/speech/spam/030319spamreport.shtml

----

See also discussion of "the plus sign technique" at SpamMail.

----

A useful anti-spam technique is given at http://www.bagley.org/~doug/elisp/hairy.shtml. It is a way to turn a normal email address into an equivalent RFC compliant one which will confuse virtually any re pattern. (If you nest parens in the comment it will even confuse the famous one by Friedl which everyone thinks is fully RFC compliant. It is not - see page 297 of MasteringRegularExpressions (first edition) for verification.)

Unfortunately, it also confuses this Wiki's pattern for recognizing plausible mailto links. :-(

-- BenTilly

----
CategoryNaming CategorySpam