Sugarplum is an automated spam-poisoner. Its purpose is to feed realistic and enticing, but totally useless or hazardous data to wandering address harvesters such as EmailSiphon, Cherry Picker, etc. The idea is to so contaminate spammers' databases as to require that they be discarded, or at least that all data retrieved from your site (including actual email addresses) be removed.
Sugarplum employs a combination of Apache's mod_rewrite URL rewriting rules and perl code. It combines several anti-spambot tactics, includling fictitious (but RFC822-compliant) email address poisoning, injection with the addresses of known spammers (let them all spam each other), deterministic output, and "teergrube" spamtrap addressing.
Sugarplum tries to be very difficult to detect automatically, leaving no signature characteristics in its output, and may be grafted in at any point in a webserver's document tree, even passing itself off as a static HTML file. It can optionally operate deterministically, producing the same output on many requests of the same URL, making it difficult to detect by comparison of multiple HTTP requests.
Sugarplum is free software, distributed under terms of the GPL.
Etiquette and ethical considerations:
The ethical/moral/legal implications of spam are relatively straightforward, but should nonetheless be considered all the way through before making use of sugarplum. I won't go into the various arguments here -- make up your own mind, and see the net-abuse newsgroups and related resources if you need more data. There are legitimate reasons for using address harvesters, though their utility has (indirectly) been destroyed by widespread use of harvesters for abusive purposes.
Sugarplum is capable of producing entirely random addresses, some percentage of which will coincide with legitimate addresses, or with legitimate domains having universal "blanket" delivery. Since the addresses are random, the odds of intersection with an address that cannot simply be deactivated without cost are very low, but the possibility still concerns some people. While I don't agree that it's a significant problem, as of v0.9.8 this form of randomization is disabled by default, to try to provide the safest possible default configuration.