This wide- and large- screen layout
may not work quite right without Javascript.
Maybe enable Javascript, then try again.
To help reduce SPAM, email addresses on websites should not be readable by programs (spambots). Yet usually for a website to be fully useful, email addresses still need to be readable by humans. The technical solution to this problem is simply to present email addresses as images rather than as text.
Here's an example of what this should look like: the email address for Mr. Somebody is . This address is readable by humans, but not easily harvested by spambots. (The HTML source that references the sample email address image above is <img src="sampleemail.gif" style="vertical-align: bottom;" alt="Mr. Somebody">.)
Converting email addresses from text to images sounds straightforward in theory, but the practical difficulty is producing the needed text images easily and quickly. One way to produce such images is with high end image processing programs, but this is slow and expensive. A better way is to use this simple String2GIF tool for converting email addresses to images. This tool is available to anyone, and can be downloaded directly from right here. (The program is enclosed in a ZIP archive [a typical way of heading off download issues]. So after downloading, you will need to un-zip the archive to use the program.)
This tool runs on almost all Windows systems, and its operation is self-explanatory. Just start it and fill in the requested bits of information, and your image file will be written to the location you specify. The image file is "transparent" (except for the text), so you can insert it anywhere in any text with any background without worrying about matching what's behind it.
To prevent harvesting of email addresses by spambots, the email addresses should not appear anywhere at all in the HTML behind a webpage, not even as ALT text and not even in a "comment" within the raw HTML. Email addresses should not be stored as text anywhere on a web server, not even in a non-displayable file or a database.
Although quite difficult, it's possible in theory to programmatically examine an image and turn it back into text. Thus email addresses hidden by the image method are not completely secure; they could be decoded by a program. (Of course they could always be read manually by a human spammer just as they are by other humans.) Fortunately no practical program for turning email address images back into text is currently [February 2012] known. And OCR-derived programs used to break CAPTCHAs, which could in theory be adapted to also decode email address images, use up enough CPU time and make enough mistakes that they're not cost-effective for use as part of an email address harvester. Spammers generally harvest just the easiest text addresses (the low hanging fruit); they probably won't even try to decode images.
Nevertheless it's probably a good idea to not surround your email address image with lots of descriptive and attention-grabbing text, or otherwise give away the fact the nearest image contains an email address. If the harvester bot can't easily figure out which image (if any:-) contains an email address, they'll probably just skip over your site entirely.
Using this tool, the font face, size, color, and weight of the text image are not controllable. They may or may not exactly match the surrounding text. They're composed using the same alphabet as the surrounding text and are easy for a human to read, so don't worry too much if they look a bit odd in some situations.
The images don't need to be in the same folder
as the web pages that reference them.
In fact, you will probably want to store
all your email address images in a separate folder
that doesn't contain anything else.
Doing so makes it easy to instruct search engines
not to index any of the email address images
without affecting the indexing of other parts of the website.
The conventional place to keep images is in a folder named "images",
so the SRC= attribute of the <IMG tag
may look something like either
src="../images/sampleemail.gif"
or
src="/images/sampleemail.gif"
.
Using the "images" convention,
here's all you would need in a robots.txt file
(in the root directory of the web server)
to instruct web search engines to ignore all the email address images:
User-agent: * Disallow: /images/
All this assumes that you've completely abandoned use of the "mailto:" option in the HTML Anchor tag. Abandoning "mailto" —and hence any possibility of already having the To: address filled in when an email composing window is opened so it isn't necessary to retype it— is a small initial price to pay as part of a comprehensive solution for reducing SPAM.
You may wish to automate the process of converting email addresses to images, and integrate your automation into the maintenance of your website. There are a gazillion different ways to maintain websites and so a gazillion different ways to automate and integrate the email→image process, and so suggestions here will probably be irrelevant to your situation.
If you use Dreamweaver as your preferred tool to create and maintain your website, the most sensible approach may be to cast the email→image process as a Dreamweaver "extension". Dreamweaver provides a lot of extension capabilities. Unfortunately, the best reference documentation I'm aware of, the official Macromedia documentation Developing Extensions for Macromedia Dreamweaver 8 is necessary but may not be sufficient. Despite its length (over a thousand pages!), it still doesn't thoroughly explain which kind of extension you want for your need, why, and exactly what parts are needed. The documentation of how to create and use the Javascript->C/C++ interface is particularly cryptic. Web searches are also not very helpful; you will find mostly questions and few answers.
The best companion book I'm aware of that gives a more complete view of these areas is Beyond Dreamweaver, by Joseph Lowery (full title: Joseph Lowery's Beyond Dreamweaver, ISBN: 0735712778). Although it's a bit dated now, I'm not aware of the existence of a better book. I recommend you use a reference book and an overview book rather than trying to choose just one or the other.