fighting email spam - Revision history

Woozle: /* site-based webmail */ hashcash

2008-01-16T01:18:24Z

site-based webmail: hashcash

← Older revision		Revision as of 01:18, 16 January 2008
Line 47:		Line 47:

	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.		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.
			===overkill prevention===
			* [http://www.hashcash.org/ HashCash] "is a denial-of-service counter measure tool. Its main current use is to help hashcash users avoid losing email due to content based and blacklist based anti-spam systems."

Woozle: /* Types of Techniques */ harvest poisoning - sugarplum

2007-12-16T16:53:25Z

Types of Techniques: harvest poisoning - sugarplum

← Older revision		Revision as of 16:53, 16 December 2007
Line 8:		Line 8:
	*** "per-org unique addresses": see section below		*** "per-org unique addresses": see section below
	*** "time-stamped addresses": a powerful harvesting control technique; see section below		*** "time-stamped addresses": a powerful harvesting control technique; see section below
			** '''Harvest poisoning''': provide loads and loads of useless data (in a format which only a 'bot would be likely to find), thus making the spammers' database mostly chaff.
			*** There is a program called [[sugarplum (software)\|sugarplum]] which does this for Linux, but I'm not sure where to find more information about it
	* '''Post-send''': filters and such for catching the mail after it has been sent but before you have to read it		* '''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 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.

Woozle: it is an ex-seedling.

2006-10-12T15:15:09Z

it is an ex-seedling.

← Older revision		Revision as of 15:15, 12 October 2006
Line 1:		Line 1:
	~~{{seedling}}~~
	==Overview==		==Overview==
	This page is about fighting [[spam]] received via [[email]].		This page is about fighting [[spam]] received via [[email]].
Line 42:		Line 41:
	===obfuscation with images===		===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. Most web-servers do have the capability of generating text-based images on the fly (using [[imagemagick]] or its equivalent), but this would require some CGI coding. It is also a nuisance for users, who must accurately transcribe email addresses (which often contain essentially arbitrary mixes of letters and numbers) from one window (the browser) to another (email client) without the convenience of copy-and-paste.		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. Most web-servers do have the capability of generating text-based images on the fly (using [[imagemagick]] or its equivalent), but this would require some CGI coding. It is also a nuisance for users, who must accurately transcribe email addresses (which often contain essentially arbitrary mixes of letters and numbers) from one window (the browser) to another (email client) without the convenience of copy-and-paste.

	===site-based webmail===		===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.		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.		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.

Woozle: /* obfuscation with images */ requires CGI

2006-10-12T15:12:08Z

obfuscation with images: requires CGI

← Older revision		Revision as of 15:12, 12 October 2006
Line 41:		Line 41:
	* '''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))''		* '''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===		===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 email addresses (which often contain essentially arbitrary mixes of letters and numbers) from one window (the browser) to another (email client) without the convenience of copy-and-paste.		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. Most web-servers do have the capability of generating text-based images on the fly (using [[imagemagick]] or its equivalent), but this would require some CGI coding. It is also a nuisance for users, who must accurately transcribe email addresses (which often contain essentially arbitrary mixes of letters and numbers) from one window (the browser) to another (email client) without the convenience of copy-and-paste.

	===site-based webmail===		===site-based webmail===

Woozle: /* obfuscation with images */ explanation of inconvenience factor

2006-10-12T15:10:23Z

obfuscation with images: explanation of inconvenience factor

← Older revision		Revision as of 15:10, 12 October 2006
Line 41:		Line 41:
	* '''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))''		* '''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===		===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).		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 email addresses (which often contain essentially arbitrary mixes of letters and numbers) from one window (the browser) to another (email client) without the convenience of copy-and-paste.

	===site-based webmail===		===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.		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.		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.

Woozle: /* domain-dependent techniques */ image-based obfuscation; webmail

2006-10-12T15:09:08Z

domain-dependent techniques: image-based obfuscation; webmail

← Older revision		Revision as of 15:09, 12 October 2006
Line 40:		Line 40:
	** 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.		** 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))''		* '''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.

Woozle: /* Types of Techniques */ clarifications

2006-10-12T14:55:18Z

Types of Techniques: clarifications

← Older revision		Revision as of 14:55, 12 October 2006
Line 5:		Line 5:
	Email-spam-fighting techniques can be broken down into the following categories:		Email-spam-fighting techniques can be broken down into the following categories:
	* '''Pre-send''': prevent spammers from getting your "real" address		* '''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		** '''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:		** '''Domain control''':
	*** "per-org unique addresses": see below		*** "per-org unique addresses": see section below
	*** "time-stamped addresses": a powerful harvesting control technique; see 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		* '''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 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.		** 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.		** 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==		==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.		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.

Woozle: /* Web Page Harvesting */ +Control

2006-10-12T14:53:19Z

Web Page Harvesting: +Control

← Older revision		Revision as of 14:53, 12 October 2006
Line 16:		Line 16:
	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.		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==		==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.		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.

Woozle: /* General Techniques */ complete rewrite of General Techniques

2006-10-12T14:52:30Z

General Techniques: complete rewrite of General Techniques

← Older revision		Revision as of 14:52, 12 October 2006
Line 2:		Line 2:
	==Overview==		==Overview==
	This page is about fighting [[spam]] received via [[email]].		This page is about fighting [[spam]] received via [[email]].
	==~~General~~ Techniques==		==Types of Techniques==
	~~{{seed~~-~~section}}~~		Email-spam-fighting techniques can be broken down into the following categories:
	Most decent web hosts now include spam-fighting tools with their email service.		* '''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
			** Domain control:
			*** "per-org unique addresses": see below
			*** "time-stamped addresses": a powerful harvesting control technique; see 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.

	~~Most decent email clients (including [[Thunderbird]] and [[Evolution (email client)\|Evolution]]) also include spam fighting tools, but they tend to be error-prone.~~
	==Web Page Harvesting==		==Web Page Harvesting==
	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.		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.

Woozle: /* domain-dependent techniques */ time option explanation

2006-10-12T14:31:06Z

domain-dependent techniques: time option explanation

← Older revision		Revision as of 14:31, 12 October 2006
Line 24:		Line 24:
	** 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 <a href="mailto:..."> tag – 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.		** 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 <a href="mailto:..."> tag – 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===		===domain-dependent techniques===
	If you have your own domain and can control the redirection of email, then some much more powerful techniques become available.		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). 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.		* '''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 – so if your email address happens to get picked up by a spambot on, say, ~~October 2~~, ~~2006~~, 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 – in this case, ~~spam320061002~~@yourdomain.com and send those emails straight to purgatory (or your worst enemy, or the spam-reporting address of your choice).		** 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 – 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 – in this case, spam3{{CURRENTYEAR}}{{CURRENTMONTH}}{{CURRENTDAY}}@yourdomain.com – 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 ~~sinple~~ obfuscation techniques described above ''or'' include the date; it's kind of a trade-off between friendly-looking addresses and spam-prevention.		** 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.)		* '''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))''