[Gllug] Perl Question - Spam Filter for NMS Form Mail

[Lesley Binks]

On Mon, Feb 09, 2009 at 01:24:52PM +0000, Ryan Cartwright wrote:
> 2009/2/9 Lesley Binks <lesleyb at pgcroft.net>:
> > From http://www.mcu.org.uk/articles/accessguidelines.html
> >
> > "From the W3C guidelines:
> >
> >    Text can be readily output to speech synthesizers and braille
> >    displays, and can be presented visually (in a variety of sizes) on
> >    computer displays and paper. Synthesized speech is critical for
> >    individuals who are blind and for many people with the reading
> >    difficulties that often accompany cognitive disabilities, learning
> >    disabilities, and deafness. Braille is essential for individuals who
> >    are both deaf and blind, as well as many individuals whose only
> >    sensory disability is blindness. Text displayed visually benefits
> >    users who are deaf as well as the majority of Web users.
> > "
> >
> > While I'm at a loss as to how to provide a braille output of a web page,
> > let alone ensure that it reproduces either correctly or sufficiently well
> > in that media and I will admit that I don't use a speech synthesizer to
> > view the web, the recaptcha offering does have audio output.
> 
> As Joel has said braille readers are hardware based. Most Braille
> readers will look for and use any stylesheet tagged for that media
> (and/or "aural"), failing that they will render a plain text
> equivalent of the page (e.g. one with no stylesheet applied). Your
> duty is to not restrict services because the user happens to have a
> disability.
> 
> Captcha by nature tends to use images and those without an ALT tag
> listing the captcha content (otherwise the bots would read them).
> Whilst aural readers are served by an audio equivalent captcha,
> braille is not. If your captcha prevents somebody with a braille
> reader from contacting you (if that's what the form is for) then you
> could be liable under the DDA. For the Disability Rights Commission
> this could well be viewed as seriously as having a shop accessible
> only by steps. Of course words like "reasonable" and "adequate" are
> used by many to work around such requirements and the DRC have claimed
> they prefer working with offenders to prosecuting them. Considering
> how much we all moan when a website is not-Firefox compatible, would
> it not be a little hypocritical for us not to make some effort for
> aural or braille users?
> 
> Proper accessibility in websites is about more than meeting w3c
> guidelines BTW. Look at it from the users' point of view. Things like
> providing text-only equivalents that provide the same level of
> service, meaningful ALT tags, "skip banner" links and content that can
> be easily laid out in a single column all help the experience greatly.
> 
> WRT spam-prevention, I find captcha useful only in hindering bots. It
> would seem that plenty of spammers are humans who fill out the forms
> with cut n paste. As long as a contact form does not permit them to
> spam other people, just leave the form and deal with any spam as it
> arrives. ( cue Martin ;o) )
> 

Captcha's are by definition there to detect the human from the machine
and hence will logically have a role in preventing mechanised spam.   I
do appreciate how they fall foul of existing disability legislation but
currently see little alternative to the potential problems of a mechanised
spambot - not least a packed mail spool, full disk or partition and an 
unresponsive system.  I would rather prefer effort to make captcha's
accessible in the aural/braille format.

It is entirely feasible, if rare, that HTML tags and/or http:// links will
exist legitimately in a message body. Excluding some textual elements from a
message because they also appear in spam prevents the user who wants to 
communicate using these items from doing so.  

The use of html escaping techniques via Perl modules such as HTML::Entities 
are surely a better way to go than to effectively dictate what one user
might say to the client?

As for the rest of it, I have no idea how secure the script the OP uses is 
- whether it traps entries such as 
"test at example.com\nCC: fred.bloggs at a.n.other.com\nTo: mary at example.com" 
or if his script attempts to send the email not only to the client but also
whoever is claiming to be the submitter of the form nor whether his
script makes any checks on the validity of the submitted email address
at all or if any of this security has already been provided for by the
original developers of the script.  

L.



-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug