Introduction
In order to be spammed with junk-mail, the junk-mailers need to develop lists
of email addresses. A number of ways are in use for collecting these
lists, the most common two being to trawl through Usenet news-postings
picking out the "From:" addresses, and crawling Web-pages to harvest addresses
as indicated by the "Mailto:" tag in HTML.
Once harvested, the address lists are traded openly between spammers... from my
own personal experience it is clear that address-harvesting has been going on for
many years; I have received spam addressed to accounts on systems that were closed down
six years ago!
If you have ever posted to Usenet using your true address,
even via a mail-to-news gateway or
a mail-list that's peered to a usenet newsgroup,
or have a mailto: tag on your Web-page that resolves to your real
email address, or have your mail-address in the signature of
your usenet posts, you are a potential victim of SPAM!
Of course, email addresses, irrespective of where they are collected from,
are only of use to spammers if the addresses actually work: there is little point
in sending out a load of junk-email spam if none of it can actually be delivered - all
that wil happen is that the spammer gets a load of "undeliverable" or
"unknown user" messages back.
In acknowledgement of this fact, some of us have begun to take actions to deliberately
make available a range of false, cannot-be-delivered-to, email-addresses on our web-pages,
and to
post to Usenet newsgroups with headers so modified that if the addresses are harvested
for use by spammers, they are "invalid".
Continued to its' logical conclusion, the spammers will find their spam-lists
so heavily polluted with "junk" addresses that they will find their spamming futile.
This plan has been described as Spam-baiting or poisoning the well.
The downside of this is twofold:-
(a) it takes time to do, and
(b) If someone wants to reply to your posting, or mail you from a web-page, the
address picked up by their software is invalid.
The saving grace here is, of course, the fact that humans are (allegedly) intelligent
and can, with suitable guidance,
hopefully recognise the "poisoned" address and make the necessary corrections
to be able to mail you satisfactorily.
Automated spam-address-collectionbots are, for the time being, not smart enough to be able to
correct an address munged in order to defeat spammers, and since the spammers depend on volume,
it's unlikely they will bother to filter their lists to remove deliberately-bogusized
addresses.
Let's
face it; they promote their lists on the basis of the number of addresses they have for
sale, irrespective of whether the addresses actually work or not, so are they going
to weed out the bad addresses if it loses them 10% and they then have to advertise
"900,000 email addresses for $49.99" rather than "one million" for the same price?
How do I do it?
Usenet
As far as usenet is concerned, it depends on whatever software you are using
to post to Usenet, and what your ISP permits.
Basically, there are 2 methods:-
(1) Corrupt your username part of the address in the headers;
for example if your username is "aardvark", you would post as "hardvark".
(2) Corrupt the system.domain.name part of the address; this can be done in several ways,
for example including an obvious anti-spam string somewhere in the system.domain.name part,
or replacing one of the periods that make up the system.domain.name with some other character.
Of course, (1) falls down if there happens to also be a user called "hardvark" on your
system (or if one is subsequently created), while (2) is not guaranteed to work if your
chosen anti-spam string is easily recognised and edited out by the spammers!
Similarly, (1) means that the spammer actually has to open a connection to your
ISP's mail-server before finding out "no such user" or whatever, so this method imposes
a transaction overhead on your ISP, whereas method (2) merely loads
the spammer's mail-system with the overhead of a failed
address-resolution (DNS Lookup) attempt.
There's also the issue that if, by chance, your munged domain-name happens
to be that of a real ISP/domain, then they will understandbly not be
very happy when they get a whole deluge of stuff addressed to nonexistent
accounts/ hostnames/ usernames on their system! Take great care if
munging the part of the address to the right of the @-sign to
ensure you're not polluting someone else's address-space.
My preferred method is to use a combination of both the methods
described above.
Note that if you do use this munge-technique, it is worth putting
something eye-readable in
your .sig to highlight the fact; for example you could include a
comment like:-
"Spam-baited address - replace "spamaconda" with "anaconda" in address when replying"
and alternatively it may be worth spelling out your full address, a suggested
form being:-
anaconda (at) snakepit.some.site.net
for the benefit of those who may need further assistance.
Note that you shouldn't even
put your full "real" address in your .sig without modification,
as there is now some considerable evidence to suggest the spammers
are also scanning the body-parts (including signatures) of Usenet postings for
addresses as well as the headers!
If you are planning to replace one or more of the periods in the address you use when
posting to Usenet with some other character, I'd suggest something like $ or ! or / or ~
or something else that's a "difficult" character to handle when writing script-programs. This
will make it more likely that your "strange address" will cause problems to those who
use shell-scripts, Perl etc. to process/analyse Usenet-scraped addresses.
Another trick you could try is putting the standard Hayes modem escape-sequence
+++ATH0
in your munged email address too: then if a spammer grabs your
address and subsequently tries to send to this address in any of his
spams which go through a Hayes-type modem, there is a significant
chance that, unless he is expecting it and has suitably altered the
modem config. parameters, the modem will interpret the escape
sequence and hang up!
Many modems either fail to implement the "guard time"
period-of-silence which must occur between the "+++" command-prefix
and the command itself, or if they do implement it
correctly, it is often not turned on (due either to the factory
defaults being useless, or the dialer software being sleazily
configured and assuming invalid defaults); in these cases,
an "in-line "+++ATH0" will cause an immediate hangup, rather than
passing through transparently.
(Not all spammers are smart enough to realise where to look for the fix to this
technique...)
Some would say i'm nasty... yes... i agree... but i'm not as nasty as the spammers!
For more info on address-munging for Usenet posts, have a look
at the official
Address Munging FAQ.
Web-pages - Address Munging.
Using the methods described here, it is possible to avoid having a
directly-scrapable valid
"mailto:" tag anywhere on your website, thus proofing it against the
address-scrapers.
The basic problem is: "what if you want people to be able to
mail you from your web-page?" How do you reveal your address to them but in
a way that does not disclose it to the spambots?
Method 1 - bending the mail-address.
One possible answer is to provide a link to a sub-page which has a "mailto" that
almost works, but has a corrupted address like previously described for
Usenet, together with some descriptive user-readable text which explains precisely
what people have to do to correct the address and mail you.
Method 2 - Casting a character.
My favourite way to get round the problem without inconveniencing users
who you want to mail you, is to use a conventional "mailto:" tag, but to cast one
or more characters in the actual email address using an escape sequence; for
example, if your mail
address contains the letter "M", you don't put the letter "M" in the address, you
replace it with the "casted" escape sequence
M.
(or whatever other
ASCII character you feel like changing).
The actual HTML used might then look like:
<A HREF="mailto:armadillo@Moo.com">Click Here to Mail Me!<A>
Now, when a genuine user clicks on this, the majority of decent mailer-programs will
pick it up correctly and replace the
M
with the letter "M" in
the desired way.
Spambots, however, will get the fiddled ASCII string with the
embedded cast-sequence in
it, which will hopefully cause them all sorts of nasty problems when they try to
mail to it.
Note that if you are using this method,
Do not
put your actual email address as the "user-displayed text"
part of the HREF. if you do, it
could still get scraped by spammers' webcrawlerbots!
Method 3 - CGI forms.
Another answer, possibly a better one since it involves least user-involvement in
de-munging your address, is to make use of a CGI script to generate a mailform, with
fields that the user can fill in with his/her details and then click on "SEND".
There are a few disadvantages though: for example, it may not be possible to
authenticate the senders' email address (since, at worst, all you can get is the
IP address of the browser that was used to complete the form, and given that many ISPs
these days use some form of dynamic address-assignment, the difficulty should be
self-evident).
Another problem is that many earlier browsers may have difficulty handling
forms.
Finally, not all ISPs allow you to run CGI scripts on their servers...
Method 4 - Javascript.
The following technique was contributed by Jonas Bjrnerstedt.
Basically you use a Javascript function to build the mailto: tag
from a series of fragments. This will stop the usual spambots
from being able to grab the "text" following the mailto: tag
(which would normally be the email address).
First you need to define your Javascript function:-
<HTML>
<SCRIPT LANGUAGE=javascript>
<!--
function bjorn(adress) {
window.location.replace('mailto:' +adress+ '@somesite.domain');
}
-->
</SCRIPT>
Then call the Javascript function from within the main
body of your web-page:
<BODY>
.
.
<P><A href="javascript:bjorn('jonas')">Click here to send mail.</A>
</P>
.
.
</BODY>
</HTML>
which will then allow users to click on the link in the usual way - the Javascript
will then build the actual mailto: address in the background and work as expected.
Web-pages - Web Poisoning.
The trick here is to place a number of false email addresses on your web-pages,
in the usual "A HREF= "mailto:[email protected]" /A" format, and hope that the
web-crawling address-gatherer robots will find them without realising that the addresses
are all bogus.
(Some would question the ethics of this... I see it as simply giving back as
good as you got).
Alternatively you can get a copy of
wpoison , a rather nasty little CGI script that generates an entirely bogus
list of email addresses each time it's called...
To top of "Poisoning the Well" |
Back to Anti-spam page
JUNK MAILERS
be warned that many of my web-pages are defensively mined using advanced
SpamBait Stealth(tm) technology.
Sending mail to addresses collected from these web-pages will result in
the confusion of your mailer, and/or automated retaliation. So don't do it.