View source for fighting email spam

{{seedling}}
==Overview==
This page is about fighting [[spam]] received via [[email]].
==Types of Techniques==
Email-spam-fighting techniques can be broken down into the following categories:
* '''Pre-send''': prevent spammers from getting your "real" address
** '''Harvesting control''': one major source of spammable email addresses is web pages; you can prevent or control such harvesting in a number of different ways; see section below
** '''Domain control''':
*** "per-org unique addresses": see section below
*** "time-stamped addresses": a powerful harvesting control technique; see section below
* '''Post-send''': filters and such for catching the mail after it has been sent but before you have to read it
** Most decent web hosts now include spam-fighting tools with their email service. These tend to include sender verification against lists of known spammers, and thus do a much better job than training-based filters.
** Most decent email clients (including [[Thunderbird]] and [[Evolution (email client)|Evolution]]) also include spam fighting tools, but they tend to be error-prone.
** 3rd-party services are available which prevent email from reaching you unless the sender has passed a "humanity test" (most commonly a "[[wikipedia:CAPTCHA|CAPTCHA]]"); this is a problematic solution at best as it may prevent you from receiving legitimate automated messages and is a nuisance for legitimate senders.

==Per-Organization Unique Addresses==
A significant source of spammable email addresses is disreputable organizations who sell their emailing lists; if you have your own [[domain name]] for email and the ability to set up a "catch-all", you can invent a new email address whenever you need to give one out. If that address starts receiving spam, then there are simple techniques to have it automatically discarded. Furthermore, if the address is named in such a way that you can easily identify the organization to whom it was given (e.g. "nameoforganization@yourdomain.com"), you can also keep track of which organizations have been less than discreet with the information you have given them.

==Web Page Harvesting Control==
Email addresses which are published on a web page are a particularly likely target for spam, as any "findable" page on the web will inevitably be patrolled by [[spambots]] looking for email addresses for their spam databases. The one advantage we have here is that this process is highly ''automated'', which allows for a number of prevention techniques.

Some things to remember:
# While some spambots may be fairly sophisticated, many of them may be written by novice script-kiddies; such bots should be relatively easy to fool.
# While most workarounds may be very easy to defeat, it probably won't be worth the spambot programmer's time to implement a fix; the small increase in the number of harvested addresses simply wouldn't be worth the extra coding (and possibly support, if the spambot is being sold or traded in the "underground" [[malware]] market) necessary.
===simple HTML obfuscation===
A few simple techniques which are easily worked around by spambot programmers, but which should at least cut down the volume of spam:
* Instead of the "@" and "." characters, use the [[HTML entities]] '''&amp;#064;''' and '''&amp;#046;''' respectively. These will copy-and-paste properly into an email program, as well as being visually indistinguishable from plain "@" and "." on a web browser. (Note: on this wiki, you can use the [[Template talk:email|email template]] to disguise email addresses this way.)
* Insert HTML markup around the "@" and ".", such as &lt;i&gt; (italics), &lt;b&gt; (bold), &lt;span class="whatever"&gt; (style sheet markup; no visible effect unless you define the "whatever" class in [[CSS]]). This requires the spambot to filter out all HTML tags before searching for email addresses on the page.

An example of the above two techniques combined (using the HTYP email template): {{email|spam1|htyp|org}}

* Insert "invisible" characters within the email address using &lt;span style="display: none"&gt;. Example: {{emaillink|spam2|htyp|org|SPAM}}
** This technique has the disadvantage that it does not copy-and-paste properly, but if the inserted text is something obvious like " REMOVE ME ", you can instruct people to remove the extra text before emailing. Unfortunately, such instructions tend to get overlooked. If you include illegal characters (such as spaces) in the inserted text, you may actually be able to prevent the email from being sent until it is "fixed" by the user. Some experimentation is probably called for here.
** The above example also includes a "mailto:" link; some users can click on such links to open their email programs, but many computers are not configured to allow this to work. This opens the issue of whether or not to "obfuscate" the address as shown in the email link. A poorly-written spambot might be HTML-unaware and find the unobfuscated address inside the &lt;a href="mailto:..."&gt; tag &ndash; or it might be set to strip out all HTML before looking, in which case the unobfuscated address would be missed. As with the above, some experimentation is probably called for here.
===domain-dependent techniques===
If you have your own [[domain name]] and can control the redirection of email, then some much more powerful techniques become available.

* '''Insert a date in the address''', like this: {{emaildated|spam3|htyp|org}} (this example uses HTYP's [[Template talk:emaildated|emaildated]] template; a normal-looking address is displayed by the browser). This requires that you are able to either (a) set up a "catch-all" email account on your domain, so that all email not otherwise redirected goes to a valid email account, or (b) dynamically configure your email handler to accept email from an address that changes every day.
** In this example, the ''displayed'' address appears normal, but the mailto: address has a bunch of extra numbers after it. These numbers change every day &ndash; so if your email address happens to get picked up by a spambot on, say, {{CURRENTMONTHNAME}} {{CURRENTDAY}}, {{CURRENTYEAR}}, all the email addresses will have that particular date on them; all you have to do is put in a redirect for the address for that date &ndash; in this case, spam3{{CURRENTYEAR}}{{CURRENTMONTH}}{{CURRENTDAY}}&#064;yourdomain.com &ndash; and send those emails straight to purgatory (or your worst enemy, or the spam-reporting address of your choice).
** For the ''displayed'' address, you can use any of the simple obfuscation techniques described above ''or'' include the date; it's kind of a trade-off between friendly-looking addresses and spam-prevention.
* '''Assign a new address for each display of the web page''': This is much the same as the above technique but provides a higher degree of filtering. It may also help pollute spam databases, thus rendering them less effective. ''(It is not, however, easy to implement as a MediaWiki template. It would be pretty easy to include the ''time'' after the date, which would accomplish much the same thing, but MediaWiki's "CURRENTTIME" variable prints the time with a colon, and I don't know if that might cause problems with email routing; further investigation is needed. --[[User:Woozle|Woozle]] 10:31, 12 October 2006 (EDT))''
===obfuscation with images===
Another way to prevent harvesting is to show your email address only as an image, never as text. This is primarily useful for individual users with the necessary image-editing software (most [[operating systems]] are shipped with sufficient software to create a usable image of this sort); it does not scale well to applications with multiple email addresses or directories which must be updated frequently, although most web-servers do have the capability of generating text-based images on the fly (using [[imagemagick]] or its equivalent). It is also a nuisance for users, who must accurately transcribe addresses from one window (the browser) to another (email client).
===site-based webmail===
Rather than giving out email addresses, a web site could provide links to an on-site message-sending page which looks up email addresses internally based on an index sent as part of the URL (e.g. <nowiki>http://mysite.org/webmail?recipient=3</nowiki>). This could be combined with the image-obfuscation technique to allow site visitors the choice of using the web interface (single-click convenience, but webmail interfaces are often poorly designed; a topic for [[webmail interface design|another page]]...) or via their preferred email client.

While this would completely prevent spambots from harvesting addresses ''directly'', automatic harvesting could still take place ''if'' the webmail page automatically sends anything to the sender's address ''and'' if it includes a valid email address in such automatic messages. Such replies need to be carefully designed to prevent such harvesting without unnecessarily hampering communication with legitimate emailers. This is only likely to be a problem, however, on high-traffic sites with large numbers of email addresses to harvest; smaller sites aren't worth the trouble of custom code to handle the webmail interface.