On May 27, 2002 at 11:01, "John R. LoVerso" wrote:
Well, all obfuscations are really weak.
Not necessarily. But, any technique popular enough to be used in a
large percentage of places will all the more likely to be coded into
some of the better address harvesters.
Agreed.
I particularly like this one, as it's non-linear:
<table cellpadding="0" cellspacing="0" border="0">
<tr><td>user</td><td>@</td>
I can be reached at
<td>example.com</td></tr></table>
The only problem is that the table tag forces a break (although not in
old browsers like NN4)
The useful thing is the line break since I speculate that harvesting
software does a line-by-line processing (easy and fast) vs full
blown HTML parsing.
You can insert a line break in an address:
<AddressModifyCode>
s/\@/ AT\n/;
</AddressModifyCode>
When converted to HTML, the line break is just treated as a space, but
the newline should be in the raw HTML data. You can also do the following
if you want to make sure an address is not broken across two lines when
rendered:
<AddressModifyCode>
s/\@/\0240\AT\0240/;
</AddressModifyCode>
Unsure how will this work against harvesters.
I am guessing that you are trying to have a method that would
obfsucate addresses from harvester but allow a person to still activate
a linked address to compose a message. Well, the table approach
example appears to not do this, so maybe not.
Pretty much any obfsucation (except the entity references only method)
will require a person to edit the address when activated for message
composition. An exception is doing something like the mail-archive.com
does, but this only applies to the author of the message and not any
address listed in the message header.
--ewh
