Form spam? What to do?

[chlori]

Good morning

Some of my customers are complaining that someone/something
is spamming the contact forms on their sites in the last weeks.

In the E-Mail field there is a random e-mail address with
the domainname of the site. So it's difficult to use a junk
filter on the mailserver, isn't it?

In the comments field, the same e-mail address is repeated.
Nothing else. It's not always the same address.

These mails come at any day or night time, so if it's the
same person, he doesn't sleep much...

My questions:
What's happening? Is that a person? Software? Why are they
doing that? Doesn't seem to help anyone...

What's the best way to stop getting those mails without
making it a too big fight filling in the form?

Thanks for your ideas!

 

[Mark Parnell]

In the E-Mail field there is a random e-mail address with
the domainname of the site.

My questions:
What's happening? Is that a person? Software?

Most likely a bot I would say.

Why are they
doing that? Doesn't seem to help anyone...

Your guess is as good as mine. Some people

What's the best way to stop getting those mails without
making it a too big fight filling in the form?

Adjust your form handler to reject any form submissions where the email
address is from that domain. Presumably you aren't actually going to
receive any genuine submissions with that domain in the email?

 

[chlori]

Mark Parnell schrieb am 09.09.2005 08:44:

Adjust your form handler to reject any form submissions where the email
address is from that domain. Presumably you aren't actually going to
receive any genuine submissions with that domain in the email?

Thanks.... Would you have an URL explaining how to do that?

On one of the sites that wouldn't work, because it's a
volleyball clubs site, where many people have addresses with
that domain name and it's quite poosible that they use a
contact form. Any solutions for this?

 

[Chris Hope]

Good morning

Some of my customers are complaining that someone/something
is spamming the contact forms on their sites in the last weeks.

In the E-Mail field there is a random e-mail address with
the domainname of the site. So it's difficult to use a junk
filter on the mailserver, isn't it?

In the comments field, the same e-mail address is repeated.
Nothing else. It's not always the same address.

These mails come at any day or night time, so if it's the
same person, he doesn't sleep much...

My questions:
What's happening? Is that a person? Software? Why are they
doing that? Doesn't seem to help anyone...

What's the best way to stop getting those mails without
making it a too big fight filling in the form?

Thanks for your ideas!

I've been getting this a bit on some of the sites I manage. They appear
to be fishing for forms they can send spam through by sending a bunch
of headers which would go into the email and create a different email
addressed to a different person.

The way I've been combating this is to check none of the single line
fields (eg first name, last name etc) contain newline characters, and
none of the multi line fields (eg message) contain 'Content-Type:',
'multipart/mixed' or 'boundary='. If any of them match the above then
they get a message back saying the form contained invalid data.

 

[Mark Parnell]

On one of the sites that wouldn't work, because it's a
volleyball clubs site, where many people have addresses with
that domain name and it's quite poosible that they use a
contact form. Any solutions for this?

The only other way I can think of which may be possible is if the email
is from that domain, check whether it is a valid email address, and if
not, discard it. I couldn't tell you how to do it though.

 

[Chris Hope]

I've been getting this a bit on some of the sites I manage. They
appear to be fishing for forms they can send spam through by sending a
bunch of headers which would go into the email and create a different
email addressed to a different person.

The way I've been combating this is to check none of the single line
fields (eg first name, last name etc) contain newline characters, and
none of the multi line fields (eg message) contain 'Content-Type:',
'multipart/mixed' or 'boundary='. If any of them match the above then
they get a message back saying the form contained invalid data.

Hmm. Having re-read your post your and my problem seem to be different.
Oh well

 

[easygoin]

Mark Parnell schrieb am 09.09.2005 08:44:
On one of the sites that wouldn't work, because it's a
volleyball clubs site, where many people have addresses with
that domain name and it's quite poosible that they use a
contact form. Any solutions for this?

my personal favourite is to use a safe form script - there are quite a
few "spam safe form scripts" - checkout http://www.hotscripts.com

or for lots of addresses - how about simple and small script to split
up the email addresses and simply put mailto links - here is one i use:

/***********************************************
* no spam - save as something like nospam.js
***********************************************/
function nospam(addr, dom, sub) {

if (dom==null) {dom="yourdomainhere.com"};

newloc = "mailto:"+addr.replace(/ /gi,'.')+"@"+dom;

if (sub!=null) { newloc += '?Subject='+sub; };

document.location = newloc;

}


then in the html page place this:

<a href="javascript:nospam('firstpartofaddress')">name or department or
whatever</a>

 

[Jukka K. Korpela]

<a href="javascript:nospam('firstpartofaddress')">name or department or
whatever</a>

Once again, someone is trying to turn his problems with spam into serious
usability problems of users. Little does she or he realize that spam will
keep arriving anyway, through other channels, so in the end, you win
basically nothing and lose visitors and customers who, for example,
follow the sound advice of having JavaScript normally disabled.

 

[Greg N.]

Some of my customers are complaining that someone/something is spamming
the contact forms on their sites in the last weeks.

1. Keep your form pages off the search engines. Put a <meta
name="robots" content="noindex,nofollow"> whereever you offer a form,
like feedback pages, guestbooks, etc. If the robots don't know about the
forms pages, the spammers won't easily find them, short of running their
own crawler.

2. Change the form page's URL every other month or so. It takes some
time for the spammers between harvesting forms pages URLs and using
those URLs in their spam bots. By changing the URL regularly, you stay
ahead of the spam.

 

[cwdjrxyz]

Good morning

Some of my customers are complaining that someone/something
is spamming the contact forms on their sites in the last weeks.

In the E-Mail field there is a random e-mail address with
the domainname of the site. So it's difficult to use a junk
filter on the mailserver, isn't it?

In the comments field, the same e-mail address is repeated.
Nothing else. It's not always the same address.

These mails come at any day or night time, so if it's the
same person, he doesn't sleep much...

My questions:
What's happening? Is that a person? Software? Why are they
doing that? Doesn't seem to help anyone...

What's the best way to stop getting those mails without
making it a too big fight filling in the form?

Thanks for your ideas!

You might consider php to help. Since a client can not turn off php on
your server, you can use php scripts without losing visitors that have
javascript turned off.

Just to indicate a possible direction, I have a perpetual calendar page
where the user must first enter a desired year in a form. I want to
validate the year so only a whole number from 1 to 60000 inclusive will
be accepted. This page is quite long and done mostly in php script, so
I have extracted the essentials so that it is more easy to see what I
am doing. To see the php script in action, see
http://www.cwdjr.net/calendar2/numbercheck.php . Enter both bad and
good characters. You will notice there is a 5 second delay after bad
inputs. This is to slow down people or bots who are guessing, and the
sleep command can be changed to any number of seconds desired. There is
no delay for a correct entry. To see the php code used, you will have
to view a text file at http://www.cwdjr.net/calendar2/numbercheck.txt .
Please note that IE6 has a bug in viewing many text files that include
php code, and you will have to right click and select view source to
see the code on IE6. Other recent common browsers do not have this
problem.

You will notice a php include at the top of the code. This include file
may be seen at http://www.cwdjr.net/calendar2/mime.txt . I am now
serving many new pages in true xhtml 1.1 using the correct mime type of
application/xhtml+xml for the extension .xhtml on the server. What the
include code does is to detect if the viewing browser will accept the
mentioned mime type. If it will, everything above the title tag of the
page is written as xhtml 1.1 and correctly served as such. If it is
detected that an outmoded browser, such as IE6, can not handle the
mentioned mime type, then the php code writes everything above the
title tag as html 4.01 strict. In addition, a regular expression is
used to change self closed tags such as <br /> to <br> required for
html 4.01 strict. I have added an alert to pop up if a browser that
will not support application/xhtml+xml is detected and the viewer has
script turned on. This is my protest of the lack of standards
compliance of IE6, which is the main current browser that will not
support true xhtml 1.1. How to remove this alert is shown in the source
code, as you would not want this on a commercial site that wants to
sell something.

My example is just something to get you started. If you need to exclude
certain characters or groups of characters, regular expressions, as
used in the php include file, are a powerful way to do this.

 

[easygoin]

Once again, someone is trying to turn his problems with spam into serious
usability problems of users.

Yes very serious - so many IE users et al are savvy web browsers who
secure and protect with military efficiency their browsing experience -
no cookies, javascript, third party plugins ..and so on - of course
they also don't do any online shopping, read webmail, and numerous
other activites on the web, because all those sites have javascript, or
scripts that "do stuff" ... strange attitude - in purist terms I agree
on full compliance with accessibility - but in the real world things
aren't black and white, simply shades of grey!

Little does she or he realize that spam will
keep arriving anyway, through other channels, so in the end, you win
basically nothing and lose visitors and customers who, for example,
follow the sound advice of having JavaScript normally disabled.

yes it keeps arriving, all "we" are trying to do is stem the flow and
quantity.
I must agree with below that a php alternative is much prefered (by me
anyway)
but if you aren't a code fiddler etc, then a simpler javascript
alternative ...for now - just may be a "solution" that helps, albeit a
part time one...

always aim for compliance and accessability, we should all agree on
that, but just don't be too rigid and one sided imho.

 

[Leif K-Brooks]

You will notice a php include at the top of the code. This include
file may be seen at http://www.cwdjr.net/calendar2/mime.txt . I am
now serving many new pages in true xhtml 1.1 using the correct mime
type of application/xhtml+xml for the extension .xhtml on the server.
What the include code does is to detect if the viewing browser will
accept the mentioned mime type.

Your script will serve application/xhtml+xml to a browser with an Accept
header of "text/html,application/xhtml+xml;q=0.1', which is completely
broken behavior. Opera, one example of a browser with such an Accept
header, will fail to handle HTML entity references in
application/xhtml+xml documents.

I have added an alert to pop up if a browser that will not support
application/xhtml+xml is detected and the viewer has script turned
on. This is my protest of the lack of standards compliance of IE6,
which is the main current browser that will not support true xhtml
1.1.

So you're punishing your visitors, many of whom may have no choice in
browser, for Microsoft's behavior? If I were forced to use IE (like I
was for a month last year) and received an annoying popup every time I
viewed a page on your site, you would lose a visitor.

 

[cwdjrxyz]

Your script will serve application/xhtml+xml to a browser with an Accept
header of "text/html,application/xhtml+xml;q=0.1', which is completely
broken behavior. Opera, one example of a browser with such an Accept
header, will fail to handle HTML entity references in
application/xhtml+xml documents.

There is no problem with recent versions of Opera, Mozilla, Netscape,
Firefox, IE6, MyIE2, MSN9, and another two more obscure browsers for
which I have been sent screen shops. I test my many pages served in
this way on all of the mentioned browsers. If Opera or any other
browser lies that it will accept application/xhtml+xml, that is
apparently no problem in rendering the page. Opera does accept the page
as xhtml 1.1 as you can see by viewing the source code while on Opera,
or it will accept a page without a php include that has the extension
..xhtml which is assigned to the mime type application/xhtml_xml on the
server. On contrast IE6 accepts the html 4.01 strict code as you can
see when viewing on IE6. If you try to force the mentioned page without
a php include and with the extension .xhtml, the page is not displayed
at all on IE6. Now it would be no surprise to me if Opera lies, because
it can lie about what browser it is in the navigator.appName and call
itself IE6, etc. However, even if it claims it accepts
application.xhtml+xml in header information and then processes as
text/html instead, it has built in changes to process the true xhtml
code you deliver properly in so far as rendering the page is concerned.
Of course all of this has no bearing on my answer to the question,
because you can just as well serve a page as html 4.01 strict only with
only the php server script to validate input.

So you're punishing your visitors, many of whom may have no choice in
browser, for Microsoft's behavior? If I were forced to use IE (like I
was for a month last year) and received an annoying popup every time I
viewed a page on your site, you would lose a visitor.

You failed to complete quoting my discussion on this issue, which
concluded:

How to remove this alert is shown in the source
code, as you would not want this on a commercial site that wants to
sell something.

I do not use this alert on my many general web pages, since even I get
tired of looking at it when checking pages on IE6. I use it only on
pages that mention the IE6 problem to underline the problem. However,
there always is a comment in the source code when html 4.01 strict is
delivered rather than xhtml 1.1.

Of course one is free to use any level of xhtml/html they wish. So far
as I know, html 3.2 still works on current browsers and can be made to
validate as such at the W3C. Of course you could not use style sheets
in html 3.2, since CSS only came in as part of html 4. For me the time
has come to switch most new pages to true xhtml 1.1. There are several
other considerations, especially concerning javascript, that must be
considered as well as what was mentioned here. After all xhtml 1.1 has
been around quite a while now and the W3C has a newer version of xhtml
in the works. This new version will require new browsers, however.

 

[Tony]

Good morning

Some of my customers are complaining that someone/something
is spamming the contact forms on their sites in the last weeks.

In the E-Mail field there is a random e-mail address with
the domainname of the site. So it's difficult to use a junk
filter on the mailserver, isn't it?

In the comments field, the same e-mail address is repeated.
Nothing else. It's not always the same address.

These mails come at any day or night time, so if it's the
same person, he doesn't sleep much...

My questions:
What's happening? Is that a person? Software? Why are they
doing that? Doesn't seem to help anyone...

What's the best way to stop getting those mails without
making it a too big fight filling in the form?

Thanks for your ideas!

If these emails become too cumbersome to sort out manually, try using a
Captcha in your form. Make sure it's a good captcha that's not easily
cracked.

--

Tony
http://dotNet-Hosting.com - Super low $4.75/month.
Single all inclusive features plan with MS SQL Server, MySQL, ASP.NET, PHP
& webmail support.

 

[cwdjrxyz]

There is no problem with recent versions of Opera, Mozilla, Netscape,
Firefox, IE6, MyIE2, MSN9, and another two more obscure browsers for
which I have been sent screen shops. I test my many pages served in
this way on all of the mentioned browsers. If Opera or any other
browser lies that it will accept application/xhtml+xml, that is
apparently no problem in rendering the page. Opera does accept the page
as xhtml 1.1 as you can see by viewing the source code while on Opera,
or it will accept a page without a php include that has the extension
.xhtml which is assigned to the mime type application/xhtml_xml on the
server. On contrast IE6 accepts the html 4.01 strict code as you can
see when viewing on IE6. If you try to force the mentioned page without
a php include and with the extension .xhtml, the page is not displayed
at all on IE6. Now it would be no surprise to me if Opera lies, because
it can lie about what browser it is in the navigator.appName and call
itself IE6, etc. However, even if it claims it accepts
application.xhtml+xml in header information and then processes as
text/html instead, it has built in changes to process the true xhtml
code you deliver properly in so far as rendering the page is concerned.
Of course all of this has no bearing on my answer to the question,
because you can just as well serve a page as html 4.01 strict only with
only the php server script to validate input.



You failed to complete quoting my discussion on this issue, which
concluded:

How to remove this alert is shown in the source
code, as you would not want this on a commercial site that wants to
sell something.

I do not use this alert on my many general web pages, since even I get
tired of looking at it when checking pages on IE6. I use it only on
pages that mention the IE6 problem to underline the problem. However,
there always is a comment in the source code when html 4.01 strict is
delivered rather than xhtml 1.1.

Of course one is free to use any level of xhtml/html they wish. So far
as I know, html 3.2 still works on current browsers and can be made to
validate as such at the W3C. Of course you could not use style sheets
in html 3.2, since CSS only came in as part of html 4. For me the time
has come to switch most new pages to true xhtml 1.1. There are several
other considerations, especially concerning javascript, that must be
considered as well as what was mentioned here. After all xhtml 1.1 has
been around quite a while now and the W3C has a newer version of xhtml
in the works. This new version will require new browsers, however.

I should add that I detect only application/xhtml+xml to choose the
header to use. Some in the past have also detected the q and used this
to determine if the browser prefers this mime type or if it prefers
plain vanilla html. However if the browser says it accepts the
mentioned mime type, I force it to do so. One should then keep in mind
that the browser might still have a few bugs for true xhtml if you so
force. The Mozilla family of Mozilla, Firefox and Netscape in their
recent versions have a problem with background color set in the style
sheet when serving true xhtml. However this bug is easily corrected, as
will be seen in one of my pages I will soon give. When you use my php
include code and force Opera and the Mozilla family, you find that all
of these browsers parse your page as xml and become extremely strict.
The least little xml error such as an unclosed tag gives you a xml
error message rather than a view of the page. Code in ordinary html can
be full of small errors and the page often will still display in some
form, but not true xhtml served as such. Also you will find that a page
that used document.write in a javascript will not display, as
document.write is forbidden. One reason is that a document.write could
produce code with unclosed tags or other forbidden xml things, so it
can not be allowed. The browser must be able to parse all code that is
downloaded as xml. Again, there are ways to handle this problem. Those
xml parsers can see right through script and comment tags, so it is
very difficult to hide things so they can not see them.

So far as Opera is concerned, it looks like a duck and quacks like a
duck when you apparently force it to use true xhtml served as such.
However those Opera code developers are full of tricks and, so for all
I know, it could really be a small goose with Hollywood makeup to make
it look like a duck .

You may see a working page at
http://www.cwdjr.net/calendar2/perpetual_calendar.php. A text file is
at http://www.cwdjr.net/calendar2/perpetual_calendar.txt , and you will
have to right click and select show source if you use an IE6 browser
only. An earlier version of this page was written in javascript which
had a document.write at the bottom of a nest of 4 "for" loops to write
the needed divisions with their css to draw the calendar. On conversion
to true xhtml served as such, most of the code ended up as php script
on the server to overcome the document.write problem. The source will
also show you the corrections for the stylesheet background-color for
the Mozilla family of browsers, along with some comments about this.

 

[Leif K-Brooks]

If Opera or any other browser lies that it will accept
application/xhtml+xml, that is apparently no problem in rendering the
page.

Opera does not lie about accepting application/xhtml+xml, it correctly
states that it accepts application/xhtml+xml but would prefer text/html.
A conforming Accept header parser would honor that statement.

How to remove this alert is shown in the source code, as you would
not want this on a commercial site that wants to sell something.

Yes, your script allows _the_webmaster_ to remove the annoying popup.
Irrelevant.

For me the time has come to switch most new pages to true xhtml 1.1.

Why? What benefit does it provide to you?

 

[Alan J. Flavell]

On a cursory inspection, it will send application/xhtml+xml to a client
agent which says it accepts it with q=0.0 - i.e explicitly refuses it.

There is no problem with recent versions of Opera, Mozilla, Netscape,
Firefox, IE6, MyIE2, MSN9, and another two more obscure browsers for
which I have been sent screen shops.

What a silly attitude to take! Content-type negotiation has already been
implementated to specification[1] e.g in Apache; it's absurd to launch
this kind of half-witted implementation on the web, that only works on a
few known browsers (don't you know any other kinds of client agents, by
the way?).

[1] with a few minor tweaks to iron out some practical glitches.

 

[cwdjrxyz]

(e-mail address removed) wrote:

Why? What benefit does it provide to you?

I just like to keep up with the latest versions of code, when possible.
Once you have written a few pages using true xhtml served as such, I
find it no more difficult than writing a html 4.01 strict page - just a
bit different. I have to admit that it took quite a bit of time to get
to this point. A very real benefit is that it forced me to learn much
more about php. View my perpetual calendar page with script turned off.
The page still works, since the scripts used are server side php. If I
had kept the old javascript version of the page, it would not work with
script turned off. I doubt if I would have bothered to convert the
calendar page to php if the requirements for true xhtml had not
required it.

 

[cwdjrxyz]

There is no problem with recent versions of Opera, Mozilla, Netscape,
Firefox, IE6, MyIE2, MSN9, and another two more obscure browsers for
which I have been sent screen shops.

What a silly attitude to take! Content-type negotiation has already been
implementated to specification[1] e.g in Apache; it's absurd to launch
this kind of half-witted implementation on the web, that only works on a
few known browsers (don't you know any other kinds of client agents, by
the way?).

[1] with a few minor tweaks to iron out some practical glitches.

The Konqueror 3.3 on Linux Debian and the Safari 2.0 on Mac OSX also
would handle true xhtml served as application/xhtml+xml according to
screen shots someone made for me. I am quite aware that there are
thousands of browsers that one can often still download at some of the
antique browsers sites. Of course many of these were never designed to
work on the modern web. There is no way under the sun that you can be
viewed by every antique browser or computer that someone may pull out
of their closet. Also many having older versions of still used browsers
may have a much larger problem than not being able to view some modern
pages - namely security. Even several fairly recent Mozilla family and
Opera browsers were replaced with a new version of browser - not just
an add-on fix. I am told there are several security issuses with some
of the old NN 4+ series. We likely seldom hear of hacks to these
browsers because bragging about hacking an old browser probably would
get as little respect from IE6 hackers as bragging about robbing a
bubble gum machine would get from bank robbers.

In any event I am happy if my newer pages are viewed either as xhtml or
html by most browsers now used on the web. I don't know where you live,
but in the US you can not use much of the web with the old generation 4
browsers. Nearly everyone who uses major credit card, bank, and many
business pages has been forced to update to a recent browser. I can not
get into the host of my domain without a recent browser that has both
javascript and Java turned on. My bank requires one of the most recent
browsers with both javascript and Java turned on. To sign into a Yahoo
mail account now, a generation 4 browser is forced to either upgrade to
a new generation browser or select to revert back to a version of the
site for the old browser. You get this message everytime you sign in as
they want to force everyone to update. From both the standpoint of
keeping up with modern code and security, it is a pity that browsers do
not expire at least once a year and have to sign in to be reactivated
or upgraded, if needed. After all, most browsers are free. From
statistics I have seen, if you can be seen by recent IE, the 3 Mozilla
family ones, Opera, and perhaps Safari browsers, that includes all
browsers that represent over 1 % each of the browsers in use. Of course
there may be isolated regions of the world while some browsers are more
important than the world average. Opera likely is more important in
parts of Europe. Of course there are unfortunately still many sites in
the US and elsewhere that go to the other extreme and write pages only
for IE that may or may not work right on other current browsers.

 

[Toby Inkster]

If Opera or any other browser lies that it will accept
application/xhtml+xml, that is apparently no problem in rendering the
page.

Opera didn't lie. It can deal with application/xhtml+xml. It just doesn't
understand the character entity references, which are an *optional* part
of the specification. (They are only required to be implemented by
validating user agents: browsers are not typically validating user agents.)

That said, Opera implemented HTML entities in XHTML ages ago. The problem
described by Leif only effects a few fairly old versions.

Now it would be no surprise to me if Opera lies, because it can lie
about what browser it is in the navigator.appName and call itself IE6,
etc.

Pretty much every browser lies in its User-Agent string: IE6 calls itself
Mozilla 4.0; Firefox 1.0.6 calls itself Mozilla 5.0.

Of course you could not use style sheets in html 3.2, since CSS only
came in as part of html 4.

CSS is not "part" of HTML 4. One can happily use style sheets in
validating HTML 3.2 documents. (Just not the style attribute or <style>
element.)