After this comment about Jeremy's spam module for this site [1] 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 [2] 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