Methods to hide email addresses from page source

Updated: 2006-12-05

I've compiled a list of methods to hide email addresses from the page source to minimize visibility against the email harvesting spam bots. Each method has its (dis)advantages, therefore I leave it up to the reader to decide which method suits them the most, as there are many factors.

Plain http://csarven.ca/hiding-email-addresses#plain

The good: Since this is the standard way of defining an email address, it is bound to work in any user-agent and has good usability. If the browser is capable of opening an external email client, then it's all for the better. This requires no additional technologies. Unfortunately, email harvesters finds this just way too easy.

Written http://csarven.ca/hiding-email-addresses#written

There is no magic here, it is very similar to first method as it also contains the mailto href attribute value. Hence, once the bot recognizes mailto: it can easily grab the remaining email. Parsing AT, DOT, and the spaces and converting it to a valid email format is a piece of cake. However, there can be many variations to this idea. Consider: foo[*at*]bar[*dot*]baz.

Unicode characters http://csarven.ca/hiding-email-addresses#unicode

Not a bad idea, however again it is similar to above methods from a bot's perspective. It can just as easily interpret the special character entities &#64;, &#46; for the @ and the . characters respectively. A minor plus in this case is that, the user may use their email client.

Hex values http://csarven.ca/hiding-email-addresses#hex

Alternativily, Hex values can be used to hide an email address temporarily. A script that is after emails written in Hex values, perhaps would look at the href="mailto: portion and grab the rest of the href value. A decent method nevertheless.

HTML Comments http://csarven.ca/hiding-email-addresses#htmlcomments

The old known HTML comments takes a shot even at assisting hiding emails. Few contributors recommended this solution to be effective, by specifically confusing the way comments work. Placing the @, ., and > symbols inside of the comment makes it a little more difficult. Unfortunately, user intiated mail client can not be brought up with this method.

Fake email http://csarven.ca/hiding-email-addresses#fakeemail

Although this is written, it contains null values which can be indicated (i.e. on a pre made subject) to the user that in order to reach the proper email address one must remove the suggested text. This works well against bots because even though they get the email, it is an invalid one, hence you are safe. On the other hand, it's relatively a nuisance, and may cause confusion to the user, if the idea is not described well.

A variant of this approach would be to use the DEL element:

/*Output on screen*/
foo@REMOVETHISbar.baz

HTTP Redirect http://csarven.ca/hiding-email-addresses#httpredirect

Write a server-side script to return "mailto:foo@bar.baz" link as an HTTP redirect. All modern browsers recognise this, but perhaps not many harvester bots do. This can be done with Apache's mod_rewrite, Javascript or server-side scripting. Here is an example in PHP:

In this case the user has to follow the link and rely on their mail application to get a hold of the email address. The user has to copy the email address from the application instead of doing it directly from the webpage.

There are numerous ways of doing this in Javascript, however the idea is the same. It allows you to break the email into parts, where it can't be easily parsed from the source. This email method is only visible on screen as it renders on browsers which supports Javascript, or those have turned Javascript execution on. Keep in mind that, Javascript is not available to many user-agents, and has an accessibility issue (see: reaching the audience part 1.) Again even with this method, it is possible to get to the email, but given some creativity it can be well prevented.

Encryption http://csarven.ca/hiding-email-addresses#encryption

This technique allows you to give an encrypted email in the source. With Javascript for example, we can decrypt the email. In the end this is quite a safe way of going at it to hide emails, and is troublesome to decrypt. Similar accessibility factors apply here as above.

Obfuscate AJAXhttp://csarven.ca/hiding-email-addresses#obfuscate-ajax

For hiding emails, we can use a neat Sessions and Javascript trick to md5 an identifier for the email which needs to be hidden from source. In this method a server-side script generates a Session and an md5 value for the email attached to the identifier of an element.

Following this, browser initiates Javascript onload. This script collects the element(s) with the md5 values as their identifier, and submits a POST request. The compliment of this, in other words, the obfuscated value(s) contain the email which needs to be hidden from email harvesters. A Javascript function then fills in the true email once the page has finished loading.

For this to work, server-side scripting, Session cookies, and Javascript, must exist. However, given the availability of these futures, along with the considered audience, it is a good way to hide email addresses by storing the email string temporarily on the server, and then calling the value back with Javascript, which then loads the email. Otherwise, its is in high alert in terms of accessibility.

Notes: Thanks to Arpad Ray for introducing his method as an alternative method to hide emails.

Images http://csarven.ca/hiding-email-addresses#images

For this technique, we make a small image file, which contains our email address. Email hunters nearly have no luck obtaining the information in the image, unless all arrows are pointing to this image, with the words 'email is in this image, come grab it.' Even in that case, it is very difficult to extract the email address as it requires a special harvester that is capable of getting the content (if its text), from an image file. This is very costy with respect to resources required for the work just to grab an email from an image file. Given the vast availability of email addresses on the internet, harvesters can easily ignore this method of obtaining emails, and stick to simpler forms. Even at this stage in our AI development, specific software designed for this has some difficulty in interpreting the information inside images. Consider styling the written word, where it is easy for a human to understand, but it can be very difficult for the computer.

Keep in mind that, only user-agents that can render the image properly will display the email address, and there is a great accessibility issue here as visually impaired users will not be able to obtain the email address.

Great technique for those browsers that can interpret CSS2's :after pseudo-element. The drawback is that not all user-agents fully support CSS2. As browser technologies progress more browsers will be able to interpret this, however there is always a chunk of users left out; including users with screen readers, and text based browsers. This method is also in the same line as using ASCII characters in the HTML source code.

The key in this method is to change the direction of text from left-to-right (default) to right-to-left. This method is one of my favourites, since this CSS unicode-bidi algorithm is supported by more browsers. This method will display the email backwards for those user-agents without the CSS features, which could be bothersome to invert.

Yet, there is a third method to hide emails using CSS. In this case, we just remove some null text from the body of the email with display none. This property is largely supported.

If the bot script does not parse through the CSS, then the techniques above can be handy to hide email, otherwise the email may face the possibility of getting spam. Although, not overly difficult to build these scripts, they take longer time to process the stylsheet data, which may or not be a worthwhile exercise.

Again, same accessibility issues as the previous CSS technique apply here. Also the good thing with these CSS tricks is that, they are visible on screen, and can be selected and copied to the clipboard. The email is textually available to the user, however they can't click on the link in order to open their email client.

Flash http://csarven.ca/hiding-email-addresses#flash

One can also use Flash to hide emails from spammers. In this case we create a flash file that simply loads a browser function getURL() with mailto scheme. In addition to this, place the following HTML.

So, how could an email harvester find the hidden email in this flash file? One way would be to decompile the flash file. Once the source is available, parsing towards mailto and grabbing the email would be the easy part. We have to give consideration to cost of such task as it can be quite expensive. Finding, fetching, decompiling, selecting source, and finding the email address for a flash file is a lot of work. For a general sweep on the internet, it is much easier for the email spammers to look into other methods. Therefore, Flash also be a useful way to hide emails from spiders.

Needless to say accessibility issues rise up with this method, as not only certain UA's do not support Flash, but there is also the possibility of this component failing to load for any reason. For sites that have a focus market (in regards to Flash being present) then I think this is quite sufficient to hide emails.

This is a very widely used method since it reveals no email address. Since the email is not in source, it is neither available on viewport. Therefore, the user has to contact you by filling out a form, which eventually gets forwarded to your email. There are some alternative methods to this, where the email is actually accessible if the actioned value is a cgi file and not complex enough. Be careful with this since it technically brings us back to square one. A server-side scripting process for the form values is very safe, and the email spam bots simply pass this source area as it contains no email. A disadvantage for this could be the comment spammers, where they leave their mark on your form, which you might have to put up with later. But that's a different spammer all together.

The Question! http://csarven.ca/hiding-email-addresses#question

This method gives you the chance to reveal your email only to human users. Basically, you can have a form that asks the user a simple question. What is 5 plus 7? If the user submits a correct answer to the question then you can reveal the email address as simple as the plain method. The user has to take the few extra seconds to go through this, but email hunters have no luck with this method, since there is no way for them to process the question, yet alone know that the close-by text is the gateway for the email. This method can be done with client or server-side scripting. If client-side all the mentioned cases on previous methods apply here as well. An alternating set of simple questions would be ideal.

Conclusions

First of all, please note that there are many variations to above methods and they can be combined to produce an offspring. The CAPTCHA method for instance is a combination of using images and a question to respond in reference to the image that is displayed. Nevertheless, the ideas are generally similar in nature. When using any of these methods, some care is necessary. For example, in the Javascript method to put together the values we may overlook the fact that the variable in which the email is contained is in plain view. This defeats the purpose, since the parser goes through everything in the source.

One magical spam script? Another point which perhaps needs to be reiterated here is that all these methods can be a victim of some clever script, by going through a large set of methods, where they could be decompiled, decrypted, or even ran through image analyzers. If such email harvesting bot exists, no doubt the emails can be stolen. Having said that, the goal in developing such methods is to fight against resources such scripts are allocated within. The complexity of such script would be too expensive 'just' to grab an email address from a page. Consider the size of the source code and multiply that by the number of sites/pages a bot has to go through in order to have a good number of emails collected. With minimal measures, a greater portion of harvesters can be fooled.

Most of the methods mentioned in this article present a way to hide the emails from the source code. However, using images, and changing the actual email deal with the visual aspect of the email on screen. Keep in mind that most of the email harvesters are built to scan the source, and to a good degree, they cannot pass the well designed methods. You may ask, what about screen/output email harvesters? Against them, your possible methods are inverted as you need to reshape the visual aspect of your email. Additionally, considering the methods that heavily depend on the way HTML works, in other words how browsers render them on screen then a spam script can merely mimic this, create a temporary output file, and then parse the remaining result. Possible? Most definitely. Worthy? This question may be more difficult to answer.

Again, thank you for all your suggestions, and please keep them coming in order to achieve a solid comprehensive list of methods to hide email address from spam bots. Our goal is to have a diverse set of these methods, and then to select an applicable method. I will update this article from time to time to reflect anything else we might can come up with (see Update date-stamp - a few pending methods will be added as soon as I get some free time. Thank you again for contributing.)

All these methods have their pros and cons, and the method you pick is entirely up to your case - always keep your audience in mind.

Interactions

Flash! If you have access to PHP, you can create a form in Flash and send the email address also from Flash to the PHP script. Otherwise, take a Flash button that contains the mailto: order to open the email client.

Personally I use a form and so do a lot of websites I've visited. Although it's nice to send an email in your client, or via your webmail, it's becoming a necessity to use a form to stop spam. And after a while it's no different or more of a hassle. Maybe less than a hassle in fact as you don't have to open a new window/message to send. It's all contained on the current page you're viewing.

If you must present an email address, make sure you've sent up spam filters on your inbox! I would suggest using a contact form aswell as an email address, so the option is there to use either. How you present the email address then would be up to you. I would see if there is a combination of the CSS unicode-bidi and Javascript, so it works when clicked or copied.

Another option is to link to a .php-script that spitts out random e-mail adresses. This would probably trigger some kind of protection on harvesters and get your site "banned"... could work :) Nice article, it's good to have everything on one place.

I once read that all these complex methods, trying to hide from spambots, are mostly not needed. a simple obfuscation like mathias.rem0veth1s@gmail.com (my addres) should fool most bots. The reason was that the bots doesn't need to be very clever considering all "open" addresses out there. It doesn't pay off.

On Saturday my blog received over 1000 spam comments, so I decided to do something about it and whipped up some "whitelist" functionality.

Email addresses are essentially pseudo-random strings of characters.
I do not show email addresses with comments, but each comment has an associated email address.
Each comment has an approved (boolean) field.
Each comment has a verified (unique) field.

When you post a comment, I check to see if there is a previous *approved* comment with that email address. If there is, your comment is immediately & automatically approved to the live site.

If there are no previous approved comments using that email address, you are sent an email asking you to click a link to verify you're an actual human, and not just a bot. When you click that link, it passes the unique verify code & commentId via the GET querystring, and you essentially approve your own comment, thus adding yourself to the whitelist. BUT upon this verification I have the site notify me that someone has verified for the first time. In that email I am shown their comment, and given the option to delete it and remove them from the whitelist to prevent future automatically approved comments.

If they used a fake email address, they never get the verification email, and their comment is never seen.

Finally, I do send copies of all verified & approved comments to myself, so I don't have to surf my old entries to find them.

It's working great so far.

If you have any questions, feel free to email me at my first name, via my email-domain, geekunity.com

Off-topic: Avoiding spam is good and well but I've become a lot more casual about it since my ISP implemented the most diabolically elegant and effective anti-spam measure on their mail server. Simply put, they ignore all first smtp connect attempts from unkown ip addresses, and accept the connection if attempted a second time. It relies on the fact that most spam bulk-mailers use a fire-and-forget approach, i.e. ignoring all errors and moving on to the next address (of millions). My spam fell from dozens per day ... to 1 or 2 a month.
More info here: http://www.pair.com/support/knowledge_base/e-mail/junk_e-mail_filtering_overview.html#4

How about an equally comprehensive overview of spam control mechanisms and their true effectiveness?

Great overview, but like the last comment having a good anti-spam email service is recommended.

I recommend TUFFMAIL (http://www.tuffmail.com). I get a secure (encrypted transport) service, along with a very effective anti-spam policy which has cut spam out of my life for good (1-3 every couple months).

I've been using the enkoder. It produces a rather large javascript to scramble the mailto, but what appears on the screen is a plain email address. It displays a line that says "Javascript must be enabled" if java is turned off or not present. So far, so good. Creating the encryption is VERY easy!

Using an image is also great if you also want to reduce the numbers of emails sent. People is to lazy to type in the adress themselves. They rather just copy/paste or click. And the emails you still get is the important ones.

I am using encryption in a way that leaves a pseudo address, so the spam harvester wastes their resources on non-existent addresses. I do this by not encrypting the '@' or the '.com' or other top-level domain.

If javascript is not enabled then the image method works well, note that PHP is great for dynamically creating images from text if you need to do so.

The CSS text-reverse trick is stylish but also breaks accessibility guidelines. To be confident the email address is accessible to everyone, you would need to avoid images (except with meaningful alt tags), Javascript and dependence on a stylesheet to make sense. Accessibility guidelines would also rule out most simple CAPCHAs because they depend on vision or hearing to work. Although spam is a big problem, we shouldn't allow it to drive us to excluding people using assistive devices. Properly marked-up forms might be the most inclusive way forward.

Consider that getting lists of domain names is easier than web harvesting, so obscuring domains in one's web publishing is quite lacking in effectiveness. Not long after I register new domains I start getting spam to guessed accounts. Fekkers didn't get those addresses via web harvests.

If you're talking about domains more technically, meaning subdomains, you could try to keep those obscure since they're not published like registered domains. But I didn't read that as your point.

The REMOVETHIS methods are sadly burdensome. The whole having to cope with harvesters thing is sadly burdensome. The whole spam thing is sadly burdensome. Keep in mind that greed hurts everyone.

Many thanks to Sarven Capadisli for offering this well-detailed and described summary.

I prefer and recommend the php form method for my clients (method xiv).

Besides keeping the spam bots away, I think it has many other benefits:
- professional looking
- it doesn't require an email app (great for the MANY web email people)
- can help guide visitors in how to communicate with you (when including other form elements for options/interests)

Thanks also for the reminders about accessibility problems using "images" (method ix).

Best way I've found is changing the email address to ascii (even the mailto: bit) and not putting your email addy on screen. So the text reads "click here to contact us" and the mailto: link doesnt look like a mail link until its parsed by the browser.

I use this on a very busy site, and only get a couple of spam mails a week (probably human input).

I like the method at this link. It's a PHP script that outputs a javascript script which uses the eval() command to interpret some escaped (javascript unicode?) characters. The resulting HTML is quite cryptic.

I like Derek's method for handling comment spam, that's similar to what I do besides the authentication email. Mostly I've found that my method only really allows manual entries of spam, and then with the email I recieve I can delete that comment with a couple clicks.

And that spam blocking boesman mentioned is pretty nifty.

Form is probably the most effective, accessible method.

I've used the enkoder and it worked fine so far. But what I usually use on my site is a javascript function. Instead of giving the bot all the information in one place. I pass some basic info to the function which assembles everything when clicked.

Perhaps I should extend this to "normallly" use the function, but without javascript a click would load up a form to send an email...

I use the encoded-@ method and it works beautifully. Here's why: Spamming is a bulk market. If my bot spends twice as long looking for those few @-encoded addresses or other variants, I'll get less addresses overall. And that hurts my business. Frankly, there are so many completely unhidden email addresses out there, they may never need to rewrite their bots. All they'd catch for their trouble is a couple of savvier web users, who are in fact less likely to respond to the spam anyway.

Some of these are very creative. But personally, I don't think it matters how you try to scramble the address, if it's interpretable, it can be scrapped programmatically. In fact, these are now available to anyone who wants to write the program to beat any of these methods.

Bottom line. Use a form. Yes it has drawbacks of possibly not getting the user's correct reply address. However, they offer security from spam, feedback, a minimum of standardized input to make it easier for you to recognize where the email originated from and more.

How many bots are still in use ? is it not just as easy for spammers to assume E-Mail address's exist ie fred{at}domain.com

spammer can see bar.baz as a domain so just adds fred, mary, ringo, foo etc at the begining.
I use spamcop.net and after 10,000+ spams have had maybe 10 or so that should not have been filterd.
I think the ability of anyone to create E-Mail address's is what needs changing. Just like we need to apply for a phone number we should have a system for handing out E-Mail address that stay with you for life regardless of your IP host. accountability would be a step forward.

I get tons of spam, but none to the address I have on my website. All I do is, I give the address as text [not linkable]. I've been doing this for years, with not one piece of spam yet (to that address). Is this not a simpler method than those described in Sarven's excellent article?

Nice page.
If you take a look at my website
(page http://trashy.sourceforge.net/faq.php#howtocontactauthor )
you will see another interesting way I found to show an email address using only an html table.
(I'm referring to the 1st one displayed.)

If you have enough budget, go for an e-Mail Forwarding service that has a capability of filtering those SPAM harversters. Create a FORM that sends all requests/feedbacks to that address. They shall get forwarded to your MailBox. Don't forget to get a good ISP that filters SPAMS too. So you get double filterings.
Or else, combine HTML+CSS+JavaScript+[Server Side Scripting]. They're all available on this article. No thing is a "Perfect-10". If no CSS, you got JavaScript and/or Server Side Scripting and vice-versa.

Add this function to an external JavaScript file, include it with your HTML document, and put in the body tag. Now write all your contact links like this: <a href="contact.html" rel="email">. If the user has JavaScript, they will see a mailto: link. If they don't, they will see a link to your contact page. This is XHTML-compliant.

Though a laudable effort i fear this is all a little pointless. This has probably been mentioned but if you are using your own domain in a business context. The spammers will just throw random commonly used prefixes at it anyway.
eg.
if my site were www.spannermonkeys.com then any spammer worth his salt will try
sales@spannermonkeys.com
support@spannermonkeys.com

etc
even to the point of harvesting common names from the about us section of the site and using them as prefixes too.
Think i have depressed myself now, boo.

Well I I've been using a js script to obfuscate my email for years and they work! Personally I think that the really complex ones that encrypt your email aren't all that useful since even the simple ones require a human to figure out the logic behind them and anytime ia human is involved all they need to do is click the link to see what email pops up in the email client.

I like Tobias TinyURL Solution. Are there any disadvantages? Isn't it supposable likely that email-spiders follow all the links in a page with the goal to find new addresses at the target pages? If that was so they would grab the "tinyurled" email address, isn't it?

Another tactic is using .htaccess to password-protect the webpage containing the e-mail address.

How this works:
Your website has a page to the e-mail address. You tell your visitors that when they enter the page, they have to type a password. Once they typed the correct password, they can see your e-mail.

I usethe form (with no email address) quite a bit, as in most of my situations a customer benefits greatly from being directed by the right questions, as opposed to an open, free-for-all email.

However, I do make sure to send them a copy of the email when they submit it, with a reply-to address.

This opened the possibility of harvesters being able to collect my reply-to address so I added an extra, hidden field into the form that must be left blank for the email to be considered legitimate. Most harvesters that fillout form automatically will fill in every field.

I think a good approach is to offer the user both form- and link-based contact options. There are good security advantages to forms, but when I'm the user, I like to have my message in my Sent box and to actually know the address I'm sending to.

The cgi script returns a page with the e-mail address plain as day. Perhaps spambots aren't daring enough to submit forms. This is exceedingly old technology (no Javascript, php, etc.) and should be accessible to darn near everyone.

A long long time ago, when I started using the internet, spam didn't exist. I decided to buy my own domain name. Then I got spam, but it was too late to hide. My address is everywhere, and I would have to change it, with all the trouble that would cause me. So I'm keeping it, and I don't mind putting it in clear everywhere. I have a spam *fighting* system doing a very good job.

Ah, I also leave randomly-generated addresses in the source code of my pages, to collect spam for my spam fighting system :)

One other possibility is to use a short term address which changes regularly, i.e. june07@mydomain.com and simply reply to all legitimate contacts telling them to use your real address in future. Then you delete the e-mail forward in July.

Note: my Opera 9.23 doesn't handle mailto redirects :(
And it doesn't display the content, I send after the redirect header. (For example an anchor tag with the email address.)
So I need to watch the USER AGENT string...

I notice that you didn't list the mod_rewrite solution. I found this the other day and it blew my mind - http://www.spamshiv.com/solutions/mod-rewrite.php. This solution using Apache's mod_rewrite to write out mailto link like a plain URL. It's totally awesome.

This writes the code in the DOM & the front end user can't see a difference (looks like a regular email link). The spiders don't see anything. The 3rd line in the script makes the "display" optional. If you don't put something in there, it'll default to the email address. This has been cross browser/cross platform tested.

Evan, I like your method but the end of the email address (.com, .org, etc.) seems to be missing from your code? Though it can be easily added I think. I suppose you could also add a subject line "tag" as well.

Also, there's no need to designate what type of script is being used, like javascript?

If your using php you can use the Ming library => http://ca3.php.net/ming to create flash. I belive that php5 here comes with it packaged in => http://www.entropy.ch/software/macosx/php/. You could create a simple button and text to create the mailto link. They have a simple example at the bottom of that page at the php.net site link above.

I think that once your website is visible enough to spammers, they will just spam you at info@, mail@, etcetera. Hiding the emailaddress is mostly about hiding the domain name, and they already know the domain-> they're visiting it.

IDEA -> use a form where people fill in their email adress to get your address. An automatically generated email could be sent to them. Another automatic email could be sent to you. That way you know who has your email address.
This might be slightly user unfriendly but can be good for some situations.

IDEA -> Use a catch-all email address to receive email. Use the viewer's IP address for the email address that they are given on your website. i.e. 127.0.0.1@website.com
This could be useful to keep track of who is emailing you. When the email is real, you give them your genuine address. When the email is spam, you have their IP.
This is probably not completely spam-proof, but maybe there are other ways to use email addresses based on user-info, to track who is emailing you and get info about the spammer.

UNSPAM -> An initative of unspam.com to forbid compliant robots from harvesting email addresses. Usage: <meta>
Replace the [link to your terms] with a link to your terms of use page. Alternatively you may include a link to www.unspam.com/noemailcollection

I don't know how well the unspam idea really works, but I like it and it might scare off some parties.

The Flash methods seems worthy, but much to my horror, I recently found one of my Flash embedded-text on Google!
Google had actually disassembled the swf and put the legible stuff online.
If they can do it, so can a malevolent spam-spider.

Temporary measure: One way, perhaps, is to put the email-id in pieces in a text file, and have the swf load it and re-assemble it at object-time.
This is what I am developing now. ANYTHING to avoid capchas! ;-)
But I'm sure eventually a nasty email-harvester would figure their way thru this.
If they haven't already...

Thanx fer some great ideas.. too bad I already thought of most of them.. ;-)

All the "spammers" have to do is read a few webpages like this one and come up with numerous ways with simple perl scripts to find real mailto tags or addresses with html comments or just plain text with @ changed to "at" or "[at]".

how can anyone trust some other site to not sell the email adresses?

php scripts etc seem complicated for casual bloggers etc...

I think an image with no mailto link is about the only way that seems reasonable from what I've read here.

Something not mentioned here is that document.write() function of javascript does not work with XML or XHTML (served as application/xhtml+xml). There used to be a hosted cgi script that worked pretty good, but I don't remember what happened to the host (and the source was never disclosed for the obvious reasons).

That really is the best thing. Come up with your own solution and DO NOT tell anyone what it is! Then the likely hood of it being negated by spam bots is GREATLY reduced!

Thanks for huge list of hints, however, I think those who are afraid readers of their pages are too lazy to read their address coded in form of an image and write it into mail client need to invest to a good spam filter and use a script-based "encryption" (if they can survive customers without script allowed will not read it).

For those who expect e-mails from people who consciously decided to write having a good reason for that, for those (including me) showing address in form of an image without "mailto:" ref is not a problem.

I really like this study - it was extremely informative. I would have liked to see more data about email addresses in the form of images. I’ve just developed a new technique to have Apache webserver automatically convert all email addresses in HTML source into images in the output stream. It is all seemless and on-the-fly, and all without touching the source format in any way. I’ve written a proof-of-concept /w example on my blog.

I think the best way is to output your email adress as usual, along with a few fake ones that is hidden from human visitors (i.e only visible in the source code). Add zxy0spam@yoursite.com and qwerty.asdf@yoursite.com and automatically flag any mail to any of these two adresses as fake. Then, when you are checking your email, the software needs to check these two accounts first to harvest spam, and then download emails from your real adress - excluding the ones that previously has been marked as spam.

The question I ask myself is, why would spammers waste resources trying to decrypt even the most basic of these methods? The kind of people who would go to the small trouble of even the most basic methods are surely smart enough to not open any spam let alone buy something or pay anyone money.

Is there some solution for encrypting emails in flash? Some actionscript encrypter?
Approach for flash movies mentioned in this article is quite inefficient! Google is able to grab any text data containing in swf incl emails. So don't be surprised about seeing your email adress on google... And spam bots use google to obtain email-adresses!! Please let me know if you know any solution for that problem.

The only problem is that once your email is out there it's out there. Plus some directory's list your email address.

If you combine two or more of the suggestions in this article then you should minimise your email spreading further.

We have used &#38;#64; for @ and a redirect php.

I have checked and most of all the big firms do not try any of these methods. I think the reason is they want people to contact them and they are prepared to deal with the spam as all businesses have too deal with the problem at some level.