[Mimedefang] RE: OT: Email web form exploits

[Ian Mitchell]

Far be it for me to interject a complaint here. But perhaps the client
should take into consideration that the person on the other end filling
out the bogus information doesn't WANT to disclose their real information.
Lord knows I've registered several bogus addresses. The best way to stay
off spam lists is not to advertise your email address and contact
information to every website out there. Perhaps your client should
evaluate their need for that kind of information. If they are using it
strickly for marketing purposes, then perhaps they need to accept the
bogus information and move on with life. Otherwise, they need to have a
simple contact page that verifies the authenticity of the email address,
if it can't be verified, the account is dropped. I would say that
addresses can be confirmed through the post office, but the problem I have
with that is forms on websites that use this sort of check are highly
aggrivating for folks who don't want to give real information, and your
client is just more likely to lose business from it.

In the vary least, your sanity checks need to be occuring on the server
that processes the HTML form, not the client. Never rely on Javascript to
ensure information conforms to standards. Cause the second you do that,
I'm opening telnet to your box on port 80 and doing a "GET
/?formvalue=reallynastyvalue HTTP/1.1\r\n\r\n" ;)

Just some thoughts on the topic.
Ian.

> Date: Wed, 7 Sep 2005 09:36:54 -0400
> From: "Chris Gauch" <cgauch at digicon.net>
> Subject: RE: [Mimedefang] OT: Email web form exploits
>
> The main problem is the annoyance to our clients -- they complain to us
> when
> they receive this stuff, and we just host their website, we have nothing
> to
> do with the implementation or scripts that are running (yes, we do enforce
> guidelines to an extent, but tell a client they can't run their mail
> script
> to send out contact forms, and you start losing business).  This has been
> very difficult for us to trace as we are fairly confident that these
> scripts
> are interacting with the HTML forms themselves, and NOT the scripts.  So,
> the question is how can we really stop someone from using an HTML form
> (and
> the NUMBER verification technique is not an acceptable solution for our
> clients)?