[thelist] Hiveware email address encoder

Jeff Howden jeff at jeffhowden.com
Wed Jul 23 22:16:56 CDT 2003


rudy,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: rudy
>
> > joe at user dot com is not identifiable as an email
> > address to an inexperienced web user.
>
> you cannot dismiss the " joe at user dot com " solution
> as being too difficult for inexperienced users, and
> then turn around and offer them a cgi-based web form
> as an alternative -- inexperienced web users *hate*
> web forms
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

and many experienced users *hate* web forms too.  i will *always* use an
email address if given the option.  i want the message i send to be in my
sent folder in my email client should i need to refer to it later.

web forms are impersonal.  it uses a method of communication in a manner
inconsistent with normal email usage.  there's an implied guarantee with an
email address that someone will receive it.  there is no such implied
guarantee with a web form.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > the answer isn't to obfuscate the address but to use
> > intelligent filtering (see other thread this week
> > about bayesian filtering).
>
> no offence to you personally, but that's silly
>
> out of a thousand web visitors, you want to offer one
> or two dumber-than-bricks users a convenient mailto
> link so that their precious and invaluable feedback will
> not get lost, [...]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

you must mean "dumber-than-bricks" as a relative term, right?  both of my
parents are quite intelligent when it comes to things not associated with
the internet.  however, if they encountered a site that used the joe at user
dot com obfuscation to (temporarily) protect email addresses they would miss
the email addresses entirely.

this isn't really about "dumber-than-bricks" users either.  here's something
to think about regarding accessibility (and even usability)  what about
users with some form of disability?  are you expecting them to open a mail
composition window, type in the first part of the address, toggle back to
the webpage, have software read the rest of the address, toggle back and
finish typing it?  or, would it be more appropriate for them to be able to
click a mailto: link that launches a mail composition window with the
address filled in?  (the same thing could be said for able-bodied users that
don't know you can select>copy>paste text)

this is sort of analogous to putting a url on a page in plain-text vs
putting a url on a page with the necessary html to make it a clickable link.
one is usable, one is far less so.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> and meanwhile burden your network with countless hits of
> spam, spam, and more spam?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i think most corporate types in charge of customer relations would say that
they'd rather deal with spam than miss a single email from a customer.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> which corporate network administrator have you tried
> this idea out on?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

the network administrator doesn't have to like it.  however, i'm sure they'd
like even less to deal with a boss that's pissed that a genuine customer
couldn't get their message to someone via the website because of some "neat"
email obfuscation trick.

my experience with numerous corporate clients has indicates a preference for
having an email address on the same page as the web form.  the spam is a
necessary evil that can be dealt with separate from the website.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> oh sure, send all the spam that you can recognize to the
> deleted folder, but what about network congestion?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

what about it?  how much can it possibly add up to?  what percentage of the
total network traffic do you suppose it amounts to?

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> using spam filters is bolting the barn door after the
> horse has fled
>
> nice solution, wrong problem
>
> the real solution is not to condone email harvesting
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

obfuscating email addresses on the web is like locking the gate to the field
by tying it shut with bailing wire and ignoring all the holes in the rest of
the fence.

the livestock analogy really isn't very good though.  the reality is a
website is only one of a myriad of places email addresses get published.  in
many of the places you can't control how or where the address goes once you
give it out.  you end up fighting a losing battle.  spambots will only get
more sophisticated in the future.  it'd be simple to write in recognition
for joe at user dot com, joe [at] user [dot] com, joe[at]user[dot]com, etc.
once obfuscation is widespread ($diety, i hope not), the payoff for the work
and additional processing will be worth it.

the only sensible way to stop spam is on its way to your inbox.  i'm
currently taking popfile for a spin and *love* it.  the cool thing with
bayesian filtering is zero false positives and over time no spam will get
through.

.jeff

——————————————————————————————————————————————————————
Jeff Howden - Web Application Specialist
Résumé - http://jeffhowden.com/about/resume/
Code Library - http://evolt.jeffhowden.com/jeff/code/




More information about the thelist mailing list