E-mail List Archives
Thread: RE: Anti-spam email links in Javascript
Number of posts in this thread: 7 (In chronological order)
From: Randy Pearson
Date: Thu, Apr 08 2004 10:06AM
Subject: RE: Anti-spam email links in Javascript
No previous message | Next message →
We have a function in our (server-side) library that munges the email
addresses so that they still look normal and act normal, but most harvesters
that look for email address "patterns" will not notice them.
Here's the function. It's written in Visual FoxPro, but you get the idea:
FUNCTION HTMunge(tcEmail)
tcEmail = ;
STRTRAN(;
STRTRAN(;
STRTRAN(;
STRTRAN( m.tcEmail, "@", "@"), ;
".", "."), ;
":", ":"),
"m", "m")
RETURN m.tcEmail
ENDFUNC
-- Randy
>
From: Mike Brockington
Date: Tue, Apr 13 2004 5:32AM
Subject: Re: Re: Anti-spam email links in Javascript
← Previous message | Next message →
On: Thu, 8 Apr 2004 19:22:52 +0300 (EEST)
Jukka K. Korpela" < = EMAIL ADDRESS REMOVED = > wrote:
> You get spam no matter what you do, sooner or later.
> Some day this might
> be fixed by effective legal actions, but now it's a fact of life.
> Just don't make life any harder for that reason to people who already have
> their own difficulties.
I probably didn't spell this out initially, but if the accessibility requirements preclude a suitably secure option, then the result will be that no email addresses will be displayed at all. This is not the intention of the WAI, nor of myself, but it is the reality of the situation. Please try and look at this from the opposite angle - I have this information which has not previously been made available; how do I best present it to ALL of the public. Incidentally, since the site in question belongs to a public body, it is also subject to Freedom of Information Legislation, so refusing to display contact details is not a long-term option. This also means that some of the email addresses in question cannot be filtered, so simply accepting that this will expose the accounts to spam is not going to go down well.
Mike
Check planning applications from your office or home
www.edinburgh.gov.uk/planning
Pay for on-street parking in central Edinburgh from your mobile phone
www.edinburgh.gov.uk/mpark
More at www.edinburgh.gov.uk/onlineservices
**********************************************************************
This Email and files transmitted with it are confidential and are intended for the sole use of the individual or organisation to whom they are addressed. If you have received this Email in error please notify the sender immediately and delete it without using, copying, storing, forwarding or disclosing its contents to any other person. The Council has endeavoured to scan this Email message and attachments for computer viruses and will not be liable for any losses incurred by the recipient.
**********************************************************************
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Jukka K. Korpela
Date: Tue, Apr 13 2004 7:43AM
Subject: Re: Re: Anti-spam email links in Javascript
← Previous message | Next message →
On Tue, 13 Apr 2004, Mike Brockington wrote:
> I probably didn't spell this out initially, but if the accessibility
> requirements preclude a suitably secure option, then the result will be
> that no email addresses will be displayed at all.
Secure? Accessibility doesn't really disturb your spam filters, does it?
And it's really not a matter of security but avoiding nuisance.
> Please try and look at this from the opposite angle
Opposite to what?
> - I have
> this information which has not previously been made available; how do I
> best present it to ALL of the public.
By writing the E-mail address as visible text, with a preceding note that
tells it's the address for... You can optionally make it a mailto: link
too.
> Incidentally, since the site in
> question belongs to a public body, it is also subject to Freedom of
> Information Legislation, so refusing to display contact details is not a
> long-term option.
Of course, it never was a reasonable option.
> This also means that some of the email addresses in
> question cannot be filtered,
Huh? I don't know what you mean by that, but surely such problems are
outside the scope of this list. Talk to the local IT staff. It is surely
not a long term solution to "spam-protect" E-mail addresses by making the
addresses available in munged form only. Sooner or later someone will put
the address somewhere as such, and it will be harvested. If you had relied
on the protective effect of address munging, the problem will be bigger
then than it is now.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Mike Brockington
Date: Wed, Apr 14 2004 3:42AM
Subject: Re: Re: Anti-spam email links in Javascript
← Previous message | Next message →
On Tue, 13 Apr 2004 16:34:00 +0300 (EEST)
"Jukka K. Korpela" < = EMAIL ADDRESS REMOVED = > wrote:
> surely such problems are outside the scope of this list.
My apologies if parts of this is OT, but the overall question is decidely relevant.
> Talk to the local IT staff.
Who do you think _I_ am? I don't do support, but 'development' does include such things as building email relays (with spam filtering) which I last did about three months ago, so I FULLY understand the implications of failing to protect addresses. This is a fully managed, enterprise-level spam solution, but there are two major issues. 1. Spam gets through - I deleted a dozen pieces of spam this morning, despite being 'protected'. 2. Genuine messages don't always get through. Both of these situations were considered unacceptable to certain people who have to respond to the public, and that was about two years ago, when spam levels were negligible compared to now, so those accounts are unfiltered. Totally.
To re-iterate; the reality is that I WILL NOT be allowed to expose email addresses without sensible obfuscation.
THEREFORE if I am to provide email contacts at all then I NEED to find some other/additional solution. The only one that has been proposed so far is to use a form-mail page.
> It is surely not a long term solution to "spam-protect"
> E-mail addresses by making the addresses available in munged form only.
> Sooner or later someone will put the address somewhere as such,
> and it will be harvested. If you had relied on the protective
> effect of address munging, the problem will be bigger
> then than it is now.
Sorry, I don't follow you here. I agree that Javascript obfuscation of email addresses could easily be beaten, but given the massive supply of addresses at the moment the spammers have little incentive to improve their spam-bots. On the other hand there is significant incentive for 'assistive' browser manufacturers to bring their software in line with 1990's technology levels by supporting Javascript - this whole issue is in fact nothing to do with User Disability, and everything to do with Browser disability. </rant>
Please don't misunderstand my intentions - I fully support the idea of accessible design, but when I look through the forums I find very little besides the odd trouble-maker complaining about the extra work, being preached at by people who often don't practice what they preach. What we all need is examples; when the WAI says 'until user agents... provide an alternative' there is rarely an indication of what that alternative should be.
Again though, that brings me back to the point that what the WAI says is NOT 'do not use' but 'provide an alternative'. My original question was whether a form-mail page was a 'suitable equivalent', or whether I need to pull the original Javascript link to avoid my employer being sued?
> Secure? Accessibility doesn't really disturb your spam filters, does it?
> And it's really not a matter of security but avoiding nuisance.
The word 'Secure' on its own may not adequatly express what either of us means
Like all professionals we try to implement 'belt and braces', part of this means taking all available precautions to prevent problems. Incidentally we recently had to upgrade our infrastructure because of the weight of spam and virus-generated messages, which at one point exceeded 10 unwanted messages for every genuine one.
I should also spell out here that I am talking about a large number of email addresses, not just one or two webmaster addresses, so the potential impact of exposing them all would be significant.
Mike
Check planning applications from your office or home
www.edinburgh.gov.uk/planning
Pay for on-street parking in central Edinburgh from your mobile phone
www.edinburgh.gov.uk/mpark
More at www.edinburgh.gov.uk/onlineservices
**********************************************************************
This Email and files transmitted with it are confidential and are intended for the sole use of the individual or organisation to whom they are addressed. If you have received this Email in error please notify the sender immediately and delete it without using, copying, storing, forwarding or disclosing its contents to any other person. The Council has endeavoured to scan this Email message and attachments for computer viruses and will not be liable for any losses incurred by the recipient.
**********************************************************************
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Jukka K. Korpela
Date: Wed, Apr 14 2004 4:29AM
Subject: Re: Re: Anti-spam email links in Javascript
← Previous message | Next message →
On Wed, 14 Apr 2004, Mike Brockington wrote:
> To re-iterate; the reality is that I WILL NOT be allowed to expose
> email addresses without sensible obfuscation.
Didn't you say there were some _requirements_ to make address information
available? It sounds like your organization is seriously
self-contradictory. Sorry, I can't help you with that.
> THEREFORE if I am to provide email contacts at all then I NEED to find
> some other/additional solution.
Then
> The only one that has been proposed so
> far is to use a form-mail page.
Do you expect that no spam will ever come through such an interface?
>. On the other hand there is significant incentive for
> 'assistive' browser manufacturers to bring their software in line with
> 1990's technology levels by supporting Javascript
Why should they take people back to the 1990's? In a World Wide Web where
JavaScript is so often used to create annoying popups or to spread
viruses, many people just have to switch it off. Besides, many people have
no choice, since the company's firewall filters out JavaScript, or the
company police makes sure browsers have JavaScript off.
> this whole issue is
> in fact nothing to do with User Disability, and everything to do with
> Browser disability.
Sorry, but that's simply nonsense.
> Please don't misunderstand my intentions - I fully support the idea of
> accessible design, but
I've heard such statements before.
In this case, accessible design is _very_ simple.
> Again though, that brings me back to the point that what the WAI says
> is NOT 'do not use' but 'provide an alternative'.
Well, you can put the simple content - E-mail address - inside
<noscript>. _That_ would be an alternative. But naturally it would just
show that the obfuscation is the problem.
> My original question
> was whether a form-mail page was a 'suitable equivalent'
Of course it's not. It is not an equivalent alternative.
> I should also spell out here that I am talking about a large number of
> email addresses, not just one or two webmaster addresses, so the
> potential impact of exposing them all would be significant.
Then implement spam filters in the mail server.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: julian.rickards
Date: Wed, Apr 14 2004 7:34AM
Subject: RE: Re: Anti-spam email links in Javascript
← Previous message | Next message →
Jukka:
I always welcome your input. I, and I am sure many others on this list,
appreciate your knowledge and understanding of web technologies and your
opinions on their application. However, I hear the frustration in Mike
Brockington's recent messages because what he seems to be receiving are "No,
you can't do that, No, you can't do that either".
Mike has a problem and apparently came to this list for either confirmation
that his ideas were sound (which the JavaScript ideas were not) or
suggestions of other methods that may solve his problem. Yes, spam is
unavoidable - I get it on an email address I set up but have never, ever
used. He should realize this and his clients should realize that when they
submit their email address, Mike and his employer will not be held
responsible for any spam.
Can we present him with some ideas that are accessible and that will provide
at least some basic protection against spam harvesters? Let's work to help
him, not hinder him.
I must admit that I am a little unclear as to what he intends to do with the
email addresses which will help us solve his problem. Does he want to allow
persons to send messages to one or more of these addresses? Do his clients
want access to the complete list? I have sent him a private message asking
him to clarify this point and I hope he will respond.
Jules
---------------------------------------------------------
Julian Rickards
Digital Publications Distribution Coordinator
Publications Services Section
Ontario Ministry of Northern Development and Mines
Phone: (705) 670-5608
Fax: (705) 670-5690
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: John Foliot - WATS.ca
Date: Thu, Apr 15 2004 10:27AM
Subject: RE: Re: Anti-spam email links in Javascript
← Previous message | No next message
Mike, et al,
I suspect we are now in a situation where we are dealing with opinion. In
some people's opinion, proving a form-mail page is not sufficiently a
"suitable equivalent" as prescribed by the WCAG, whereas others (myself
included) feels that it is - not perfect, but acceptable.
I once implemented a "form-mail" page for a local city councilor (Ottawa,
Ontario, Canada) who had similar concerns about indiscriminate exposure of
email addresses yet non-the-less wished to leverage the ability of his
constituents to contact his office. (http://dougthompson.ca/contact.html)
The <select> box in the second fieldset ("Are you writing about...?")
actually works with the back-end script to "pre-sort" the emails to the
appropriate staff member in his office. We did provide a "general" email
address as well, but encourage visitors to use the form instead. Is this
"the best" solution? For him (and myself) it is an acceptable, accessible
solution, and there has been no negative feedback since it's implementation,
almost 2 years ago.
The bottom line here is that there are good, better and best answers to this
vexing problem, but the final outcome *must* include something of a
political decision. The "task masters" at your institution should be fully
informed of the different solutions available to them, with the possible
pros and cons of each, and then *they* should make the final decision.
If it is a "legal" opinion you seek, unfortunately one does not exist (that
I am aware of). The WAI - WCAG is a Best Practices document which
unfortunately is all too often looked to as being a "policy" document; the
problem of course is that it is not written in the language of Standards or
Policies and so exposes itself to interpretation.
So: are mail-forms accessible? Generally, yes, provided they are well
constructed (and as I have outlined previously, work with all the Adaptive
Technology that I am aware of). Does providing an alternative (an email
address) make access to the recipient more accessible? Yes, but with it
comes the potential for the types of problems you are seeking to avoid.
Should this be the end users problem? No, but life is about making choices
and that includes this situation; the "harm" of not providing all email
addresses is offset by the harm exposing them causes your organization.
Does providing *only* a mail-form make the ability to contact the entity
inaccessible? I would say no - under certain circumstances and possible
scenarios it may prove more difficult or problematic, but there reaches a
point of balance, and this is what your taskmasters must decide. You
*could* also provide a telephone number, but what if the end user does not
have access to a telephone, is unable to speak due to medical or other
conditions, etc. , etc. , etc. In my opinion, if you have
expressed/demonstrated best effort in your duty/obligation to accommodate,
then for the odd individual who cannot, for whatever reason, use the tools
you have provided what is the answer? And *that* more than anything else is
the nucleus of this discussion - how far is far enough?
Mike, I hope that the discussion has given you enough ammunition to go back
to the decision makers with enough for them to make an informed decision.
You asked in a subsequent email for a vote - I vote option 2 - use the form.
JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca 1.866.932.4878 (North America)
>
>
> On Wed, 14 Apr 2004, Mike Brockington wrote:
>
> > To re-iterate; the reality is that I WILL NOT be allowed to expose
> > email addresses without sensible obfuscation.
>
> Didn't you say there were some _requirements_ to make address information
> available? It sounds like your organization is seriously
> self-contradictory. Sorry, I can't help you with that.
>
> > THEREFORE if I am to provide email contacts at all then I NEED to find
> > some other/additional solution.
>
> Then
>
> > The only one that has been proposed so
> > far is to use a form-mail page.
>
> Do you expect that no spam will ever come through such an interface?
>
> >. On the other hand there is significant incentive for
> > 'assistive' browser manufacturers to bring their software in line with
> > 1990's technology levels by supporting Javascript
>
> Why should they take people back to the 1990's? In a World Wide Web where
> JavaScript is so often used to create annoying popups or to spread
> viruses, many people just have to switch it off. Besides, many people have
> no choice, since the company's firewall filters out JavaScript, or the
> company police makes sure browsers have JavaScript off.
>
> > this whole issue is
> > in fact nothing to do with User Disability, and everything to do with
> > Browser disability.
>
> Sorry, but that's simply nonsense.
>
> > Please don't misunderstand my intentions - I fully support the idea of
> > accessible design, but
>
> I've heard such statements before.
>
> In this case, accessible design is _very_ simple.
>
> > Again though, that brings me back to the point that what the WAI says
> > is NOT 'do not use' but 'provide an alternative'.
>
> Well, you can put the simple content - E-mail address - inside
> <noscript>. _That_ would be an alternative. But naturally it would just
> show that the obfuscation is the problem.
>
> > My original question
> > was whether a form-mail page was a 'suitable equivalent'
>
> Of course it's not. It is not an equivalent alternative.
>
> > I should also spell out here that I am talking about a large number of
> > email addresses, not just one or two webmaster addresses, so the
> > potential impact of exposing them all would be significant.
>
> Then implement spam filters in the mail server.
>
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
>
>
> ----
> To subscribe, unsubscribe, suspend, or view list archives,
> visit http://www.webaim.org/discussion/
>
>
>
>
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/