Most seasoned web designer/developers have learned that posting an email address on a website is a sure-fire way to guarantee a steaming pile of spam delivered to that address for years to come.
Indeed, posting a naked email link anywhere on the web (or in a newsgroup, in a chatroom, on a weblog comments page …) is generally the kiss of death for your once-healthy address.
INVASION OF THE SPAMBOTS#section2
It begins innocently enough: the neophyte web developer codes his address into a fresh, new web page to solicit the feedback of his adoring fans. “Email me!” it beckons. A short time passes. Then the barrage of email begins.
From: john@48_93839aac6673030.com Subject: Make 80k working from home ...
The first few spam emails seem entertaining. Then frustrating. Following the so-called “unsubscribe” links in each mail only results in more mail. Eventually, the task of separating valid email from junk becomes so time consuming and problematic that the developer is forced to abandon the email address entirely.
I know this because the developer was me – and to this day, years later, that email address still receives dozens of unwanted email messages every day.
Have you ever wondered how, almost instantly, your email address is discovered, recorded, handed down, and passed around? This happens due to hordes of Email Harvesting Robots (aka spambots). These autonomous bots spider the web day and night in waves, crawling pages and following links until they discover an unsuspecting MAILTO tag. Then they pounce, devouring the address and sending it deep into the bowels of the web where the ugly, festering spam companies dwell.
TENTATIVE MEASURES DON’T HELP#section3
Having learned your lesson, unwilling to post your naked address on a page again, you attempt to buck the system, removing any possibility that the spambots will detect your address. Instead of providing an actual link, you type:
you at example dot com
While this will fool ’most all spambots, it fails entirely at providing your audience with an actual, clickable, email link. Your viewers will have to read and remember the text and then type it manually into their email program. Not a big deal, but this might be the extra step that prevents them from making contact with you.
Your goal is to make their life easier, not harder; to encourage, not discourage, contact. So you abandon this technique and move on to something better. But what?
TO EMBED OR NOT TO EMBED#section4
Your next move might be to embed the MAILTO link within a block of JavaScript, like this:
<script type="text/javascript">
document.write("email me");
</script>
At first, this would appear to be a suitable solution. Unlike web browsers which will execute the JavaScript and display your link correctly, spambots should, in theory, ignore the JavaScript and therefore the link to your email address.
Unfortunately, spambots can read your address without executing any code at all. This is because the link exists as plain-text within the parseable text of the page, ripe for the picking.
Drew McLellan was happy enough to prove this to us all with his Encoded email address harvester, a nice device that harmlessly scans your web page in search of vulnerable addresses. Run it against your existing web pages and see what it finds. The results should prove interesting.
DOUBLE PROTECTION: AS GOOD AS IT GETS#section5
The best solution builds on the JavaScript-wrapping idea, but rather than leave the naked email address exposed within the easily-parsed JavaScript, the address is encoded – translated – into each character’s Numerical Equivalent, and then wrapped.
You see, every character can be mapped to its own special code which, when viewed by a web browser, is translated back into that character. The following table gives you an idea of how this works:
char code a a b b c c 1 1 2 2 3 3
Using this technique, you can generate a complete link that will be rendered correctly by the web browser. Wrapping these codes yet again within a JavaScript will further limit the chances your email address will be assimilated.
NO ONE IS SAFE#section6
Unfortunately, no email address published online is entirely safe from robots that harvest addresses, but converting your email address to numerical equivalents and then wrapping the result in JavaScript should foil all but the smartest and most dedicated spambots.
AUTOMATING ANTI-SPAM PROTECTION#section7
Converting your email address into an encoded and JavaScript-wrapped link is a tedious process. Fortunately, almost every programming language features an easy way to invoke this transformation.
This author’s Automatic Labs Email Address Encoder, for example, is an online resource that will handle this process for you. Just enter your email address and the link information, and it will do the rest. You may also download a stand-alone program to run on your own computer. Both versions create the same results, and even allow you to specify cross-browser XHTML or HTML 4.01 code that validates.
On this code page, you’ll find a simple PHP function that will handle this transformation.Enjoy! {The product has been updated since this article was published in ALA issue 145. To download the latest version, see the Automatic Labs products page. – Ed.}
Could spam blocking be done with using PHP vairbales and then reasembling the e-mail address when the page is put into a browser?
Hmmm…do these forums encode user e-mail addresses when they’re input?
I do the following on my site:
mailto:aliotsy@theKILLSPAMthousand.net?subject=remove%20KILLSPAM%20from%20address
does anyone know if this is effective?
I don’t think there is really a way to block email harvesting and make it easy for the end user to click a mailto. I have seen ways using test gifs and code linking, but if a browser can render the “coded” address properly a havester can be made to do the same thing. The best way to combat spam is at the email server level. Either your company, ISP, or your own home email box. By using such things as Spam Assassin, procmail filters, or other products.
Only if the end user understands that they need to edit your email address. If your site is known to be visited by web-savy people then probably. But on a site visited by people that are amazed that a simple click can open their email client with a message ready-to-go. It may not work.
Probably one of the best ways to allow end-users to contact you is a form similar to the contact form at zeldman.com. Bypassing the users email client altogether. Wait I just viewed-source and his email address is in the code, nevermind. Ok see example to contact the Web Master at http://www.mwenergy.com.
Good article! I’ve been using an encoder I found in a March 29, 1999 Dear Dr. Website column from Internet World. The site I used (and which is still in existance) can be found at: http://www.siteup.com/encoder.html
I ran my site through the validator and no “defective” email addresses showed up! I didn’t start getting spam at my address until I used my address to register for the SXSW festival (silly me: I was looking outward, never thinking I’d be skunked from the inside! -grin). I will say, it seems to have subsided in the last month or so.
Encoding all the characters as html entities is quite ingenious. However, it shouldn’t take the savvy spambot developer long to convert all those entities back to characters…ugh!
My own pages use the trick mentioned in the article but it does have a fairly serious flaw that nobody has addressed: it relies on client-side JavaScript.
If a user has disabled scripting than they get nothing. I suppose they can always view the source code and re-assemble the e-mail address from the numeric equivalents, but who’s going to do that?
I’m starting to think a feedback form may be the only option.
You could always put your email link in a tiny swf. This of course comes with all the associated baggage but should keep the link away from spambots.
I wrote a similar JavaScript encoder that addresses (no pun intended) this problem (i.e. users that have JavaScript turned off). Similar to the Hivelogic solution, it encodes the e-mail address in Unicode, as well as the mailto: porition, so spam bots can’t even detect that it is a mail link. Furthermore, it allows for non-JS browsers to be directed to a feedback form. Take a look at: http://www.gazingus.org/js/?id=106
Oops. That should be: http://www.gazingus.org/js/?id=106
I just use a PHP contact page that takes some form variables and puts ’em in mail. If you wanted, you could even put in options for bcc, cc, priority (?) et c. to make using the form page as versatile as an e-mail client. Some people will still look at the form and run, since it’s giving you no guarantee about encoding or database addition (not more spam!) or IP logging. I guess that’s the price you pay if you want to e-mail me. Not that anyone does, which is my premise for keeping my contact page this way. PS: if anyone wants the php for this mutha or the regular expression that checks e-mail address syntax validity, contact me.
If you really want to use a mailto: link you can do so by pointing to a PHP page and redirecting from there. I’ve put up an example here:
http://members.evolt.org/simonc/php/spamtest.html
The contents of mailme.php is just:
Simple, and easily expandable to include more than one email address. Could be combined with any of the above techniques to create ‘live’ links.
The only problem with it is a usability issue – looking at the status bar makes you think you’re going to a webpage, not a mailto link (but that could be worked around by altering the status bar with JavaScript).
Good article, I love reading all the great tips that get posted on ALA. The problem I see with any encoding technique is that as someone has already mentioned, if the browser can parse/render the email link properly there is nothing stopping a spam bot from doing the same.
Sure it might stop them for a bit but you can be sure that someone will find away around any sort of trick. The best solution I have come across and I hope that others will follow suit is to create a mailto page. This page has the simple fields such as From: Subject: and Message: but the To: email address is not given anywhere on the page. Instead a simple reference number is passed when the message is sent – this number is then matched to an email address in a database or static file. Using the servers email program the message is sent to you with out ever posting your email address anywhere.
This method requires your hosting company to allow some sort of CGI or PHP script to be run and access to their sendmail (or equivalent) program, but what hosting company doesn’t offer these sorts of services now a days.
Just my $.02
Another viable solution for those that can run CGI is to install a modified, improved version of the popular Matt’s Formmail script (http://nms-cgi.sourceforge.net/), specially since the discovery of a big security hole on this popular script that allows spammers to use it as a mail relay or something. Anyways, the coolest thing about this new Formmail script, besides the heightened security measures and general debugging, is the fact that your important mail data can be specified as script variables, so you don’t have to put a “recipient” hidden field containing your email address on the HTML source. I replaced my old Formmail script with this one a while ago and I’m looking forward to see if this measure slows a bit the avalanches of spam over time…
the best thing indeed is using a contact form instead of a simple mailto. Not only for the security issues involved, but also because of the fact that not everyone is neccesarily looking at your site from their office or home computers loaded with their email programs.
The author of the Monaural Jerk (http://monauraljerk.org) provides a script that will, given a cron system and a php binary and an installed Qmail server, provide you with a random throw-away email alias. I use this for my clickable address. Who cares if it’s harvested? By the time a spammer gets to it, it’s obsolete and will bounce back to the bastards.
I’m sure that this idea isn’t unique, and could be adapted for most folks in one way or another.
You could also remove the “mailto:” by breaking up the link, like this:
Good article, and I’m sure it will benefit people who don’t have access to a database on the backend. I think a better way to handle it is to offer a feedback form, so your email address doesn’t appear anywhere on the site, encoded or not.
About three months ago I tried to come up with a solution that doesn’t fall down if the user’s browser isn’t JavaScript-enabled, and doesn’t suffer from the “if a browser can render it, a harvester can read it” problem. I came up with the method described here:
http://www.december14.net/ways/nospam.html
It’s still pretty simple, doesn’t need CGI or PHP scripts, and seems to do the trick. If anyone can see any weaknesses, I’d like to know.
Another way to save your email on the web is to place it in a flash movie. I dont know of any bot which can dig through SWF files.
Might be alil too much but its the lazy mans way to protection.
Out of curiosity, are email addy’s on this page (i.e., this ALA Forum page) encoded in any way? Because the irony of including your addy on a publicly-accessible page while talking about how to protect said addy from spambots, is a tad thick.
Another idea for all this: restrain your contact info on your site to an actual “contact info” page, then use robots.txt to dissuade bots from parsing it. Would that work? Do bots still obey robots.txt? I’m getting forgetful in my olde age.
Of course, it wouldn’t help if you’re the type (like myself) who suffers from the delusion that site visitors may at some point be gripped with an spontaneous and impatient desire to email me, but won’t want to go to all the trouble of loadinga contact page to do so.
We could also just, you know, kick spammers in the nuts whenever we meet them. The Nutcracker Vigilante, we can be. I’ll make the shirts.
reefdog asks: “Do bots still obey robots.txt?”
The robot exclusion protocol is entirely voluntary, so it’s down to the bot programmers to decide whether or not to follow it. Many bots do, notably those of the most reputable search engines, and the likes of Alexa. But given the motives of disreputable bandits like spammers, it’s a bit too much to expect of them! I remember reading somewhere of someone who had put this very idea to the test – sadly I can’t remember where – and not surprisingly, it wasn’t long before they started receiving spam.
I wholeheartedly support the “kicking spammers in the nuts” idea, though. Just line ’em up, and I’ll pull on my best steel toecapped boots.
One possible (though somewhat complex) solution could be to give two different feedback addresses on the same page. And then have the mailserver or a client program delay and check the mail before forwarding it to you. The theory here is that no human will use both addresses to send the same letter twice, but a spamer is likely to do just that.
Well, what my friend did, Zeke Runyon, (http://www.communistsquirrel.com/) was to wright a mailer perl script that made it so you had to enter in a name, email, and text to get it to send, with an email interface. Confusing, yet sucesfull. try it out at http://www.communistsquirrel.com/mail/
pretty cool…
as greyduck has already mentioned, the best defense is simply to use disposable email addresses. however the method they link to is far more complicated than something like sneakemail (http://www.sneakemail.com/).
the address is pretty ugly, but it works and users don’t have to think about it – no removing NOSPAM (which I’m sure the bots can getaround now anyway) and just one click so the less savvy users aren’t put off.
Hi,
I do actually use client-side redirection to provide spam-protected and still usable e-mail links. I use the PHP backend to split e-mail addresses in 3 parts (username, domain and top level domain name). The mailto URL is split in several concatenated strings and sensitive characters such as ‘@’ are URL-encoded. I believe this protection is robust until the day spambots will evaluate or scan pages for known patterns of JavaScript code. Now here it is :
function noSpam(n, d, tld)
{
window.location = "mail"+"to:"+n+"%40"+d+"%2e"+tld;
}
The function is simply called in the anchor tag href attribute, i usually provide a link title with the “phonetical” representation of the e-mail address such as “john dot doe at example dot com” so the link is still usable for people who just want to peek the e-mail address since the status bar only shows an unfriendly “noSpam(‘john.doe’, ‘example’, ‘com’)”.
I hope it helps… and that spammers don’t read ALA forums! 😉
X
I too use a php script and the mail() function to receive email from customers, so our address never sees the light of day. Originally though, we used a javascript with the email broken into variables and then the variables put into the .write() just to break it up and make it a little harder to piece back together.
function email(){
theName = “myName”;
at = “@”;
thePlace = “myPlace.com”;
document.write(“Send Me No Spam!“;
}
When I first learned of these Spam bots searching sites for email addresses I quickly went to using a server-side form for contacting purposes. But I completely forgot to remove my meta reply-to tag with my email in it, should I take it out? Can these bots read meta tags too?
If it’s legal to use JavaScript to document.write a meta tag, then you can use the same tricks for them as everyone is talking about for mailto links.
the problem with form submissions as a substitute for email is that then the sender has no record of the transaction or what was said. For example I have submitted email messages via forms to cbc.ca, ati.com, creativelabs.com and hp.com that have vanished into the great electron void in the sky. Now every time I am forced to use a form instead of email I keep a seperate text record so that I can phone the company and harangue them (which is necessary all too often). If that is too much work for the message (“your page at xxx is screwed up”) I often don’t bother.
So form-instead-of-mailto may protect your inbox, but it comes at a cost.
-matt
A robot which understands javascript is perfectly easy to create, and I’ve certainly got one that will get the email address in almost all of the techniques above, it’s not a harvester of email addresses for the purposes of spamming, but it does get email addresses of sites.
All these techniques have huge usability and accessibility issues – you’re requiring unwarranted levels of support for the fundamental requirement of providing a contact address.
If you want to fight spam, fight it on the mail-server, use good filters.
Jim.
How about providing people a form rather than a textlink? I always prefer being independent of a mail client when I want to contact someone.
It seems there is an ultimate kick for some simple creatures to fill your forms with bla@bla.com or test@test.com but that is the problem of your backend script to filter that out. Especially with PHP a small mail() script is sooo easy to do.
A thing I consider completely useless are forms with mailto: actions.
To add to the idea of putting some NOSPAM or alikes in the textlink, I practice that myself but found that also writing something in the message body should help even slow people to grasp the idea:
mailto:you@***NOSPAM***server.org?subject=Contact&body=Please remove the ***NOSPAM*** in the email, this is to prevent spamming, thank you
cool article by the way and the http://www.hivelogic.com/safeaddress/ online tool is such a nice idea.
For anybody who is considering replacing their MAILTO with a feedback form make sure not to include your email address anywhere in the html. This is accomplished by not using javascript and instead using an old fashioned form/cgi combination. I know that in PHP it is very easy to do, because there is a built in “mail” function so all in all it shouldn’t take more than a minute or two of coding. This is the method I would recommend if you have PHP on your server…
Hi,
I was just wondering whether spambots like ssl-pages or not. For my pages I use ssl-encryption and a form mailer for those paranoid people who like to contact me by email. But nevertheless because of my hosting service, I have to use their form mail script (cannot run custom cgi) and put the adress in a hidden field in the code.
Another great website providing a more permanent throw-away address is http://www.spamgourmet.com/ which allows you to create an infinite number of limited-use addresses which forward to your reall address.
It’s worth a look.
If you use Apache and want to block the most used spambots, then read this discussion (very good!):
http://www.webmasterworld.com/forum13/687.htm
Also, if you happen to use ColdFusion as your scripting engine, then here’s a function that converts emails to safe format:
http://www.cflib.org/udf.cfm?ID=405
.erki
Matt Wilkie
It wouldn’t be difficult to add a check box to the mail form so that users could choose to have a copy of their message sent to themselves.
regards,
matt
Just a little additional info on a free online tool that will automatically scramble your email address into ASCII:
http://alicorna.com/obfuscator.html
I refuse to put a mailto link of any form on my personal website. I get a good deal of spam from doing that through a variety of different practices and attempts to evade the spam-harvesters. I use a form oriented approach for emails; a simple HTML/CSS bit that sends all data to a php script which emails me directly.
Using this script I can limit the number of emails a person sends (no war-emailing) and can have it go to any email address I specify. If I wanted; I can then reply to this person if warranted and everything is fine and not a single spam-bot gets my email address. I have control over who KNOWS my email address and who does not.
Now, if I need to use an email address in any post or public forum; I’ll use a cheap disposable hotmail account. 🙂
the solution xavier gave on the previous page is the perfect one, if relying on javascript is not a problem. It’s fantastically easy to code and would be prohibitvely hard to scan for. I was looking to see if anyone suggested it before I posted it too.
as far as the problem with form based emails not going in your visitor’s records (a real problem for some, inclduing me), if you have a sufficiently savy audience you could offer (with a checkbox) to copy the email to the sender as well for filing.
-wg <><
Dan writes that he believes the best solution is to use both numerical equivalents and JavaScript wrapping.
This solution has a few flaws:
First, what happends if the user has JavaScript disabled? No email address.
Second, what happends if someone decides to use a harvester which understands numerical equivalents and Javascript wrapping (One might argue that many spammers are too stupid to think of such things, but that’s another discussion entirely.) – Voila, another email address to add to the spammer’s list.
I believe the final solution to this problem is also one of the simpler ones: A feedback form. There are numerous scripts for virtually any platform out there that will create and send emails based on form input.
For Linux and other *nix platforms there are the formmail scripts (Just don’t use older versions of Matt Wrights formmail scripts, as they allow your server to be exploited as spam-sending source by virtually anyone), which I presume use sendmail and/or other smtp-daemons. (I’m not very well versed in the realms of *nix, but I know just enough to be dangerous.)
For Win32, there are numerous components that can be installed and used for sending email. NT4 and 2000 even comes with a set of components that include a SMTP-component, namely CDONTS (Just don’t rely on it too much, because this feature will be replaced by CDO in .Net Server, which will require modifications.). You rarely see a Windows webhost who does not boast such a component.
In many cases, the responsibility for creating the form and the script to parse the form falls upon the webdesigner or -developer. For those, I have one bit of advice: Do not put the recipients email address in a hidden field in the form or somesuch, because that will give away the email address to some harvesters. You should rather place the email address as a variable in the script itself or in a database and only refer to it with with an ID in the form.
Right now, I am, on my own website (As linked by my name above), using mailto:-links, but this has to end very soon, as I have already now (After about one month) started to recieve spam on the email addresses mentioned there. I am going to replace these with forms, but as I am pretty swamped with school work atm, things are not progressing as fast as I want…
-Morten
An excellent article and some very nice alternatives mentioned. Lets hope this will slow the suckers down for a while…
Funnily enough, I had been thinking about making a solution similar to some of the javascript ones mentioned here… I love it when I find someone else has already done exactly what I planned but even better =)
I think the method of using a tricky javascript function and letting non-javascript users fall through to a form mail page or a PHP header redirect is an excellent all round option.
I think I have a foolproof solution, if such a thing exists. I made an image file containing my email address. Humans can read it but not spambots. To make it a link, I used an EXTERNAL .js file to write the tag before the![]()
tag, and another to write the tag after it. By linking to two separate JavaScript files, the email address is entirely removed from the HTML. The page still validates as XHTML 1.0 or whatever. If JavaScript is disabled or unsupported by the client, he can still see the address in the image file.
If you use this technique, be sure not to put the full email address in the “alt” attribute of the image tag! You could, however, use “joe at joe dot com” or something like that, as someone else already mentioned.
Sorry. I didn’t know that the form would encode by input as HTML. This is how the fourth sentence should read:
To make it a link, I used an EXTERNAL .js file to write the tag before the![]()
tag, and another to write the tag after it.
Sorry to be so late in the discussion, but I worte one because I noticed that a talented spammer (please, I realize that is an oxymoron), could effectively use the callback in LWP and unencode the entries.
Instead, what I did was wrote a program that randomizes between hex and ascii encodings for the e-mail address, encodes the prompt and even encodes the target if you want. It also obfuscates the mailto: portion of the href argument to throw off simple spambot word searches.
It needs work, so be gentle:
http://www.HealYourChurchWebSite.com/cgi-bin/obfuscate.cgi
Dean
As far as i know, email addresses in flash swf files can not be harvested.
That just makes me all warm and fuzzy inside 🙂
Okay, I’ve fixed the obfuscator so it works with our friends across the great pond, and down under as well as other places non-us.
I’ve also moved it. The new location is:
http://www.healyourchurchwebsite.com/obfuscator/
I use a simple redirection script, that can be written in any scripting language you like. The link calls, for instance, “mailme.php?username=myname&host=myserver.com”. The script then redirects the browser to “mailto:myname@myserver.com. This seems to work well in most browsers, although for some reasons it works once in Opera, then gives an error on each successive attempt unless you close it and restart.
Using a jaacript to break up the mailto: will likely solve the problem, anthough using an entity for the @ symbol might help bulletproof it.
However, the real question is, to spambots read the source code or the rendered page? If the read the source, we’re covered. If they read the rendered page, we’re wasting our time unless we don’t want the address to be the displayed text.
I wonder if simply adding a sace before or after the @ in the …>text portion of the tag would invalidate it without completely ruining it on screen, as in “…>name @domain.ca”
Any thoughts?
For the moment, I’m going to create a trap email address and pt it in a link on my main page to at least raise alarm if the spambots are trolling my site.
I can’t believe how bad the spelling is on that last post. Allow me another try:
Using a javacript to break up the mailto: will likely solve the problem, although using an entity for the @ symbol might help bulletproof it.
However, the real question is, do spambots read the source code or the rendered page? If the read the source, we’re covered. If they read the rendered page, we’re wasting our time unless we don’t want the address to be the displayed text.
I wonder if simply adding a sace before or after the @ in the “…>text” portion of the tag would invalidate it as am email address while still leaving the appearance of an email address, as in “…>name @domain.ca”
Any thoughts?
For the moment, I’m going to create a trap email address forwarded to my address and put it in a link on my main page to at least raise alarm if the spambots are trolling my site.
I dunno, I like my little obfuscator
http://www.healyourchurchwebsite.com/obfuscator/
the mailto: disappears as plain text, the @ dissapears as main text, there is a random mixture of ascii; and hex; encodings that appearently have worked well enough of the past few years at a church site I’ve developed that our spam count is very low – usually guys clicking on the address and letting it rip.
That said, I am GLAD there is more than one way to skin this cat. If there were 1 best way, you can bet your bottom dollar the spammers would be coding up a storm to get past it – instead, by us having several anti-spam tools out there, the targets are too numerous to overcome – like a grasshopper taking on a bunch of little ants (we’re the guys in black !-)
Of course, you can always make your email address as plain as day, and let live this little beauty:
http://www.perlmonks.org/index.pl?node_id=103656
On a more serious note, if encoding efforts happen to fail (or you just couldn’t resist signing up for that “free” “toothbrush”) there exists Spam Assassin (http://www.spamassassin.org), whose extremely powerful perl-driven parser can filter out more than 90% of spam.
What you have to remember is that spambots aren’t people reading your page; they’re an automated robot. They don’t SCAN the page for email addresses, they PARSE it. That means they look through the source code for email addresses, not the text; depending on the parser, an address in a meta tag is no different than one in a link. It all depends how the spambot does the parsing. For instance, it may just look at links in the page:
#!/usr/bin/perl -w
use strict;
use HTML::TokeParser;
use LWP::Simple;
sub grab_email_using_links
{
my ($url) = @_;
my $content = get (“http://someurl”);
my $parse = HTML::TokeParser->new($content);
my @addresses;
while (my $token = $parse->get_tag(“a”))
{
my $url = $token->[1]{href} || “”;
my $text = $parse->get_trimmed_text(“/a”);
my ($email) = $url =~ /mailto:(.*?)/
push (@addresses, $1) if ($email =~ /([^@]+@[^.]+..*?)/);
push (@addresses, $1) if ($text =~ /([^@]+@[^.]+..*?)/);
}
return @addresses;
}
However, what if he just looks at the source code in general, hoping to pick some out of the body text? The address finding is then greatly simplified:
#!/usr/bin/perl -w
use strict;
use LWP::Simple;
sub get_email_from_page
{
my ($url) = @_;
my $content = get (“http://someurl”);
my @addresses = $content =~ /([^@]+@[^.]+..*?)/g;
return @addresses;
}
Even if you don’t know perl, you can at least realize that the above is most definately not a lot of code; if a spammer REALLY wanted your address, I’m sure he’d be able to resole many of the solutions you are posting…
As you can see, if your are serious about protecting yourself, its pretty stupid to post your email address in any shape or form (of course, spambots don’t tend to go after personal sites; as such I wouldn’t be too worried about posting your email address on your homepage). A form based mailer is much safer, and pretty much a necessity for larger sites. The best (meaning most secure and featureful) is the NMS (http://nms-cgi.sourceforge.net) formmail (and the brand new TFMail, formmail’s big brother). To answer the argument that form-based mailers don’t give the mailer a copy of the email, formmail can be configured to email the mailer a copy of the email, or to simply display the message to the screen (in which its their own damn fault if they don’t save it! :P)
Just for fun, I wrote a page of JavaScript to change
name@example.com
to
The relevant JavaScript functions on the generation page were
// Return a string that's reversed with bit 0 flipped
function Flip(s)
{
var i;
var r = '';
for (i = s.length; i; i--) {
r += String.fromCharCode(s.charCodeAt(i - 1) ^ 1);
}
return r;
}
// Update the form
function Refresh()
{
var s = '' + document.all.LinkText.value + '';
document.all.ResultPlain.value = s;
document.all.ResultObfuscated.value = '';
}
As mentioned before, this works until the spambots figure out how to run JavaScript.
Spam is one of the main factors that is holding back the potential of the internet. Hotmail accounts are generally where most people begin their experiences with email, and considering the amount of crap that gets through to your average hotmail account, people just aren’t going to take it seriously. Fortunately there are moves under way to make spamming illegal in parts of Europe and then hopefully the rest of the world will follow suit. I can’t imagine how spam can be an effective way of marketing when everyone sees it as an infrigement on their privacy ???
I’ve had great success just listing my email like this:
mailto:name%40domain.com
Have yet to get spammed. Quite nice actually. Quite simple too. The best protection is, of course, a form submitted to the server.
Hi all,
here we go with the easiest fix ever:
instead of name@domain.com use the following:
name%40domain.com
It doesnt need any javascript (not everyone browses with javascript ON!!!) and still is fully functional. This is to help standards compliance and the new way of supplying information through the web. I got it from (personal comment by David at) http://stilleye.com
Ciao.
i promise i hadnt read above before posting 😉
I think I stated back on page 2 of this discussion, that anyone handy with LWP and HTML::Entities and could snarf up e-mail addresses that were hex encoded only. This is why I randomize between hex & ascii encoding. Not foolproof by any means, but requires enough extra coding to get overlooked by all but the most determined ‘bots … and for them, I have some SSI induced chaff in their way so by the time they get to a real e-mail address, it’s lost in the white noise or they’ve given up.
But like I said in my last post, I hope EVERYONE here implements a variety of tactics. If we all did the same thing, they’d easily code at that one solution Buy offering a milieu of methods, we keep’m spinning their wheels and hopefully driving up their cost of doing business.
Anyone tried out Cloudmark (http://www.cloudmark.com) ? I’ve just signed up. Not server-side, but it is a step in the right direction.
I am trying out the hivelogic method displayed.
However the displayed name is so coloured that it does not suit my dark background. Could some show me the exact coding and where it should be in the coding generated so I can have a choice of colour. I know nothing about coding.
Many thanks
Robin
I created a database with MySQL/PHP that stores the email addresses, which are never viewable(even through viewing the source) on the website. Am I still at risk?
I’m also in the process of configuring my email server to block everyone in the Open Relays database (http://ordb.org). Also, I’m using a tool called Mailscanner(mailscanner.info) which scans all of the emails for viruses and it has a SpamAssassin plugin.
As noted above any technique that uses client side java script is useless, the end user can turn it off.
Thats why you use an .asp or another server side solution if you want to foil spambots.
I agree that the reliance on client-side javascript is a problem; however, it’s possible to get around the problem using something like this after where you’ve embedded the javascript:
And just make How do I use this address? text a link to a page containing instructions (using a dummy email, of course!).
I see all this 20+ lines of code just to hide email addresses from html…it´s so simple to just publish the damn thing in .swf format and stick it in your page
The Way
“The Way is shaped by use,
But then the shape is lost.
Do not hold fast to shapes
But let sensation flow into the world
As a river courses down to the sea.”
Tao Te Ching; 32 Shapes
I know how to do this in php but you could use anything that makes this possible.
When the client clicks on an email link, a box pops up asking them to enter their email address and then the site emails them the address so all they have to do is reply to that email.
Easy.
all data is stored in a MySQL database which is passworded so only the php on the server can access it.
It also cuts out any display on the web of either email address. Thus bypassing the spam issue.
Another solution, used by BeSweet‘s author, is to simply replace an email link with a link to a forum page where one can leave a message on the system for the user. In my case I have forums on my site and private messages (phpnuke), so I can do that for myself too. I just did that today – what a coincidence.
simplify the javascript code to:
email me
Here’s the weakness, and a suggestion:
IT SEEMS TOO EASY to write a script that will harvest any consistently applied technique of obscuring mailto addresses. The trick is for us all to USE SOMETHING DIFFERENT. Use SSI to create throw-away e-mail addresses from some part of the user’s IP address, or use PHP to use the time of day. Mix this up with the break-apart technique, but don’t break the address at logical places. Throw in a little encoding, here and there. Keep the harvesters on their toes! Make it easier to get their addresses from other sites. The hard work they’ll go to, just for a handful of our obscured addresses, won’t be worth it.
In general I use and recommend the “caller ID” method, creating a custom e-mail address for myself each time I register for web sites, etc. I know from whom the mail came, by the address they sent it to, and can easily filter it out. Example: ebay.me@mydomain.com
I’m also using SpamAssassin, which is great by itself. I learned how to write a user_prefs file, and how to write simple procmail recipes. Together, it’s really, really effective. Because we can’t stop’em all from getting our e-mail addresses.
Blocking those nasty spambots is a real pain I agree. I have seen bots that go through the trouble of parsing email addresses after processing the web page through a browser. So how do we kill it in my shop and get even?
The Block: We have email sent to us through form submission. IP addresses are logged with the date to prevent abuse (only 3 messages an hour). This is a easy script to write. You do not have to show the address in a .cgi file
The Kill: Knowing what these bots look for, and how they operate is key. They spider hyperlinks over your entire site where there will be likely email address. We have a mailto:bsadress@bsdomain.com generator, which is hyperlinked and named directory.cgi to our contacts section.
Imagine if the spammer was caught in the mail out by getting tens of thousands of mailerdaemons. Their server admin would catch them before the complaints.
The link provided isn’t my site, just one that i found that had these scripts for free/practically nothing.
Granted This article was intended to have this be done in Javascript, and in that case consider calling the function as an external .js file to generate the email addresses and to display email links. BTW if you feel you have to display your email adress that they click on use an image that is linked the way Xavier Defrang mentioned above if you have no cgi access.
Whew I think I have said Enough,
David Smith
If you use cgi to provide web based email through forms, you do not have to display your email address. I do that in my shop and it works.
If you generate bogus random addresses like bs@bs.com you will tip them off to the sys admin when they begin a mailing getting thousands of “address unknowns”, or wasting their bandwidth if they are a service.
If you must display an email address, make an image that uses the method Xavier Defrang mentions above to link it, with the function as an external .js script.
The link is not my site, just a place i found where you can get these simple scripts if you are too lazy to write them.
Avitar
דגכעדשגכשדגכדגכדגכ
Check out spamgourmet.com
It works the same as sneakEmail.com
http://www.neilgunton.com/spambot_trap/
Just search for “Balu” to find my php-solution, that generates a uniq mailto: for each visitor – which looks like
web-32bitIP.timestamp@example.com
This way I can easily reject addresses that were found by bots and are used for SPAMming. I even know where the bot came from and when. I can even find them in the webserver-logfiles and analyze their activity.
There are many other ideas and hints on that page too…
Balu
Just use a contact form that then mails you the content of the form. The user doesn’t need to know your e-mail address at all.
I use one at my site and users find it easy to use.
Cheers
By far the most elegant approach AFAIK;
Catch the email harvester in a tar pit and destroy it’s database.
(including the email address just snatched from your HTML)
All mail links can remain unmodified.
http://www.monkeys.com/wpoison/
The easiest and as far as I know most fool-proof method is one that Xavier almost alluded to. It involves a simple Javascript function that assembles an email address when the user clicks a hyperlink.
function mail(user) {
locationstring = “mailto:” + user + “@” + “domain.com”;
window.location = locationstring;
}
You can of course add more variables so that you may use multiple domains, ie:
function mail(user,dom,tld) {
locationstring = “mailto:” + user + “@” + dom + “.” + tld;
window.location = locationstring;
}
In the hyperlink, just call the function:
javascript: mail(‘johndoe’,’domain’,’com’);
This method has proved exceptionally reliable. To test it, I put a page with a normal email link to spam@mydomain.com and one to my real address assembled through this Javascript function. Spam comes to the spam address, but not to my real address.
Hopefully this helps someone!
In pure HTML you can extra tags that will not get in the way.
You can also use the character entities.
JavaScript would be needed to dynamically add this to the HREF of the mailto link.
You can even distribute the parts of you email address in invisible tags around the page, even put some bits in attributes, and use JavaScript to reconstruct it in.
Problem with non-javascript browsers though.
Maybe have in the mailto href and on the page for a server side solution. But don’t bots get to the page after sever-side processing?