After this comment about Jeremy's spam module for this site i think,
i have context to post some ideas about simple non-CPU, bandwidth
sucking, non GUI means of fighting cheap, non-human spam. I'm
stupid text-mode guy, thus:

* CSS obscurity (non-)captcha like for web
* To, In-reply-to, From, Message-id for SMTP/e-mail.

+ CSS: basic idea is in the comment above.
More means to alternate the view:

* alternating of the color: exact matching is not needed, small
delta can be used to have similar-looking symbols; same delta to
have symbols to nearly match background, gradients, invent your own
it's simple, etc.

hide: fgcolor = bgcolor +/- small_delta
show: fgcolor = bgcolor +/- big_delta

* alternating visibility by enabling/disabling, media format,
layers, coordinates, etc. (but `lynx`-friendly versions are more
appreciated)

* asking to locate one-color symbols all-over web page -- ouu!
it's like game already :)

+ SMTP/e-mail:

* check To header to be valid person name or list name/abbr. This
is problem of personal order and culture. I.e. personal e-mail are
very rarely sent from other than address-book e-mail, thus name
*must* be there! It's stupidly effective -- No thousands of spam
message daily for my professor! I.e. all

To: spam_here_please@example.upol.cz
To: spam_here_please <spam_here_please@example.upol.cz>

are gone in one blow. If you have personified spam or buggy
subscriptions with spammy To, then you can fix it manually.

As for mailing lists: this barrier is too easy to overcome.

* "In-reply-to". Header is RFC2822-requirement in replies. So, if
say, LKML is development-mostly list with replies/start-thread
messages ratio very big, or even huge, then to demand a ticket for
starting a thread isn't a big problem.

Thus, include ticket in your `quilt`/`git`-generated patch-bomb,
and job is done. Message from individuals must have ticket on they
own.

So, what is this "magic ticket"? This is a message-id generated by
list-master to include in in-reply-to header. Simply: this is a
message you receive on request to post a thread-start (i.e. one
which originally without in-reply-to header).

i-want-a-thread-start-ticket                     > list-master
list-master                                      > here: $message-id
my-new-thread-in-lkml(in-reply-to: $message-id)  > LKML

(for `quilt`/`git` one can book as much tickets as needed)

Checking for valid message-id:
* optimised: just find ticket in References
* full: scan for valid (message-ids non marked as spam) thread
chain in headrs. NNTP server is quite fast at this. Gmane handle
all (i mean "high volume" LKML is one of hundreds) mailing list
available with ordinary inn2.

This is more complicated, but still very easy to overcome if known,
thus this is additional barrier for MLs. Spamming of ticket-booking
is smart and brainy spam, thus can be identified and black-listed.

Spamming of threads, like debian bug tracking system is also easy,
because all messages are available on-line, no subscription is
needed. Again, this is brainy stuff.

Who is responsible for global warming? He-he, morons!
I think this are means to have less hot CPU on spam processing.

--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
 #oo'L O
<___=E M