[drupal-devel] Dealing with spam (was rel=nofollow)

[Jeremy Andrews]

> Spam Karma works by running every new comment through a battery of
> filters and checks. Each of which increase or decrease the comment's
> 'Karma' value. Depending on the final score, the comment is either:
> 
>     * Approved
>     * Discarded silently as spam (no email is sent to you, unless you
> specifically require it, but a digest is sent to you every X spams
> deleted).
>     * Placed in Moderation mode. With the possibility for the
> commenter to auto-moderate his own comment by proving he's not a
> spammer (by filling a Captcha or checking a confirmation email).

The concern I have is that when a comment looks like spam, a comment looks
like spam.  There's generally not a grey area in between, where a comment
kinda looks like spam.  Rarely, perhaps.

(For example, the spam module just blocked a string of comment and forum
postings by the same user of my site because he was including ~8 links
back to his blog peppered through his posting.  This is the first non-spam
I've seen that did this, but had I been auto-deleting, I'd never have been
the wiser.)

Anyway, the auto/silent discarding is the only thing that is not currently
supported by the spam module.  That and the phrase "spam karma", instead
it's internally called "weight".  Call it what you like.  ;)

Due to the excessive amount of spam I'm getting, I intend to get back to
spam module development soon, and to add some mass-deletion and even
auto-mass-deletion functionality very soon.  Specifically, I'll provide
the option to relate one or more actions with each filter type.  So, for
example, any posting that matches the regex /online poker/i could be
linked to "auto-delete", while any just matching /poker/i could be simply
moved into the moderation queue.

> This whole process insures (by order of priority):
> 
>     * No deleted false positive (bad bad bad).

I disagree.  It does not assure this.  But by silently deleting, it could
potentially make you believe that it does.

>     * Extremely few moderated false positives (annoying): uses Captcha
> and email auto-moderation to keep these at a minimum.

This has been true for me with the spam module.  False posititives happen,
but they are very infrequent.  And as the Bayesian logic gets trained,
they seem to happen less and less often.

>     * No published spam.

True with the spam module, in my own testing of late.

>     * very little spam held in moderation (must be destroyed directly:
> really annoying to have to moderate it).

This will be dealt with in my next round of spam module development. 
(post-deleting spam will also be an option, currently not a possibility)

> Further more, Spam Karma works in an intelligent way to automatically
> update its filtering database and grow stronger with each spam it
> catches___

I don't know what this means.  But the spam module has a Bayesian filter
built into it, so it learns from its mistakes.

>     * Time taken to fill the comment (e.g.: if it's less than a few
> seconds, most likely spam).

Interesting.  I think I'll look into adding something like this to the
spam module.

>     * IP and regex match for URLs contained inside the comment (small
> weight only for non-URL text matching a URL regex).

The spam filter does this automatically, and provides statistics as to how
well each of the URLs work.  It's referred to simply as the "URL filter". 
Urls are located by the Bayesian filter.

>     * Realtime Blacklist (RBL) Server check for IP and URLs.

Nearest I can tell in the spam traffic I've seen on KernelTrap, this is
more or less worthless.  All the spam floods I've gotten are from
unbelieviably well randomized IP addresses.  I've enhanced the spam module
on my site to collection session information, etc, and I found nothing
that could be effectivly blacklisted.  (Except for offsite links, which
are already handled automatically).

I will keep analyzing the data, and should I find a trend, I will look
into this again.  (My idea is simply to auto-block any IP that posts spam
for n minutes)

>     * Comment's age (e.g. penalize comments on very old post).

Interesting.  I think I'll look into adding something like this to the
spam module.

>     * Ambiguous comments (that can neither be deleted or approved) are
> given a second check: commenter is asked to solve a Captcha or use the
> email auto-moderation (an email containing a hash to unlock the
> comment is sent to the commenter's email address). If confirmed, the
> comment's Karma is bumped up and the comment is either published or
> held for further review, if not confirmed within a certain period, its
> Karma is lowered and it is either deleted or kept into moderation (if
> it was sufficiently high to begin with).

Yes, I like the idea of tying spam filtering into a captcha system, only
displaying the captcha if the posting appears to be spam.  The only
negative feedback I heard on this idea is potential accessibility issues.

Note again that "ambiguous comments" in my experience have been rare. 
When the spam module thinks something is spam, it tends to really think
that something is spam.

>     * When a comment is struck as spam, its IP and URL(s) are
> harvested and submitted to the Admin for inclusion in the blacklist.
> In the meantime, they are used as "auto-added" values, with a lesser
> weight than permanent blacklist entries.

As noted, this would be worthless in dealing with the spam I've seen on my
websites.  Otherwise it would already be implemented in the spam module. 
;)

>     * When destroying a spam comment, it checks for recently posted
> comments that match similar values and retroactively moderate them
> (e.g.: a spammer could manage to slip X numbers of spams onto a blog,
> but upon reaching a certain suspicious threshold, all the comments
> would get retroactively moderated, then deleted).

This doesn't appear to do much good if they are posting anonymously, and
each posting is from a unique IP address, which is how all spam floods
appear on my website.  The only thing tieing them together is content -
certainly something that could be auto-analyzed.

>     * Spam Karma uses a central DB to retrieve IP and URL updates. By
> default, it will query the DB automatically every 2 days (can be
> disabled). Central DB can be configured. Each install of Spam Karma
> can work as a sort of P2P relay in the update process (both fetching
> updates and publishing its own updated list for others to grab).

As soon as someone creates a generic module for handling the
centralization of such data, it will be implemented in the spam module... 
;)  Perhaps some day I'll have the time.

Cheers,
 -Jeremy