With automated spam, automated spam-fighting systems might be the only choice. Sending rightfully angry emails to ISPs to notify about their customers violating service agreements is probably a waste of effort (something tells me most of these complaints end up in the trash folder, or even in the… spam folder). However, I get a feeling that some spam is not automated – it appears to have been actually prepared and sent by a human. (Alternatively, spammers behind those spams simply have better software.) Anyway, some spams seem to contain valid contact data of the advertized entity – like an email.

The resulting idea is very simple and was probably already implemented somewhere by someone: simply publish online contact emails of the entities which, apparently, had chosen spam as the primary means of advertising. These emails will be sooner or later harvested by spammers, added to spam databases, and will start getting progressively more spam.

There are a few drawbacks to this approach:

• knowing spam-collection points enables “black PR”-like mass-mailings in the name of one’s competitor, double-hurting the innocents; I do not see a clear method of preventing this, other than by concealing spam collection methods;
• human intelligence is required to identify if the contained email truly belongs to the advertised entity; this is fairly time-consuming, especially when scaled up; a possible solution (with its own problems) would be to build an online gateway for submitting curated spam samples, thus distributing the workload to all the participating volunteers;
• the next logical step is actually harvesting and then publishing all the emails from the advertised website;
• the biggest drawback, however, is low efficiency of this approach; increasing spam percentage will only be a mild nuisance, which isn’t likely to propagate high enough to affect spam-deciders; also, indirectly spamming someone’s mailbox will result in the loss of time, which could have been otherwise used for facebook and other important activities

What do you think? Should such a method be used?

Below I provide a few sample records from real spam comments, which had true-looking emails. I’m including some extra meta-data. Ideally, this should be stored in some kind of a database.

Submitted on 2013/11/13 at 15:23 GMT
Author : Виктор (IP: 95.134.110.37 , 37-110-134-95.pool.ukrtel.net)
E-mail : aionind@yandex.ru
E-mail : sale@aion-industry.ru
E-mail : info@aion-industry.ru
Submitted on 2013/11/26 at 8:53 GMT
Author : Виктор (IP: 95.134.146.235 , 235-146-134-95.pool.ukrtel.net)
E-mail : kvazargr@yandex.ru
E-mail : info@kvazar-gr.ru
Submitted on 2013/11/28 at 7:24 GMT
Author : Виктор (IP: 95.134.117.155 , 155-117-134-95.pool.ukrtel.net)
E-mail : relevater@yandex.ru
E-mail : info@relevate.ru
E-mail : support@relevate.ru
E-mail : billing@relevate.ru

There’s definitely a need for a public database, API keys, and quorum algorithms…

Author : casinoworka (IP: 91.207.4.201 , 201.4.207.91.unknown.SteepHost.Net)
E-mail : pharmacywork7777777@gmail.com
E-mail : info@prowessmedical.com

Current setup:

• MX records point to the spam protection mail servers, which then
• connect to my server and deliver (hopefully spam-free) mail.

Problem: some senders (like last.fm) do have proper, strict SPF records. Tumgreyspf on my server then rejects emails relayed through the spam-protection service.

If these spam protection relay servers are the only which send mail to your server, then it makes sense to fully disable/uninstall tumgreyspf. Putting tumgreyspf into the permanent “learning mode” (set defaultSeedOnly = 1 in /etc/tumgreyspf/tumgreyspf.conf) may not fix the SPF problem described above, as SeedOnly seems to only affect greylisting, and not rejecting unauthorized senders.

Solution: whitelist relay server IPs.

I will use MXGuardDog spam blocker as an example. This solution is a slightly extended version of this one, and used tumgreyspf README as the reference.

• For each of the IPs you want to whitelist, create a directory tree under /var/lib/tumgreyspf/config/client_address. Here is a copy-pasteable example for MXGuardDog, based on their list of server IPs, valid as of August 2013:
  
mkdir -p /var/lib/tumgreyspf/config/client_address/108/166/117
mkdir -p /var/lib/tumgreyspf/config/client_address/174/129/28
mkdir -p /var/lib/tumgreyspf/config/client_address/216/58/39
mkdir -p /var/lib/tumgreyspf/config/client_address/222/229/219
mkdir -p /var/lib/tumgreyspf/config/client_address/64/15/147
mkdir -p /var/lib/tumgreyspf/config/client_address/66/85/178

• Into each of these IP range-specific directories, put a config file, which disables checks (or symlink one). First, create /etc/tumgreyspf/disable.conf with the following lines in it:
  
SPFSEEDONLY = 0
GREYLISTTIME = 600
CHECKERS =
OTHERCONFIGS =

  It is just like the default.conf, but has empty CHECKERS and OTHERCONFIGS lines.
  Now, symlink it into each of the IP range directories:
  
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/108/166/117/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/174/129/28/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/216/58/39/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/222/229/219/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/64/15/147/__default__
ln -s /etc/tumgreyspf/disable.conf /var/lib/tumgreyspf/config/client_address/66/85/178/__default__


Note the double-underscores to the left and right of default.

That’s it.

It appears that it is very easy to use ExpressionEngine’s contact form (which uses Email module) to send emails to arbitrary addresses – simply put, send spam using someone’s EE.

And here’s why:

• recipients hidden field is passed to the client; it is encrypted, but with access to the mod.email.php code, it is a matter of several minutes to write your own email-encoding function which will produce a completely valid recipients field
• there’s also XID field, which seems to be unique for each page load

Spamming algorithm is clear, so I won’t elaborate. (I could have missed some session variables, though – didn’t check them.)

This information is valid as of ExpressionEngine 1.6.6, but nothing in the change-logs indicates that this mechanism was modified in the newer versions of EE.

Update: I’ve tested, and this vulnerability does exist. The simplest prevention measure is to enable Captcha for Contact Form.

I’ve notified the developers.

And SK2 still works under WP 2.5! (SK 2.3 was released to support WP 2.1)

Kudos to Dave!

It would be a pity if this excellent plugin is abandoned and stops functioning in one of the upcoming WP releases.

Update: SpamKarma is now GPL (at google code).

One could think that as the spam-problem is fairly well known, there should be reliable methods to get rid of spam. However, the spam problem is like the “weapon-shield” competition: the stronger the weapon, the thicker the shield. Spammers adapt, unfortunately.

Getting down to business. In this post I’ll describe how I am solving the spam problem in my blog.

The first plugin is Comment Policy. It adds a required checkbox below the comment form, which needs to be checked in order to successfully post a comment. Checkbox field name is auto-modified by JavaScript, which means that clients (preferably spam bots) without JavaScript support will be unable to post a comment. Thus, comment policy stops non-JavaScript spam bots.

Note, that this plugin defends only the comments, not pings/trackbacks.

It can be argued that JavaScript requirement might prevent people from posting comments – true, but with all those Ajax interfaces only the tiny percent of visitors would have JS disabled. Visitors with text browsers (lynx, links, etc) would be the only group unable to post… which is bad.

The reason I keep this plugin is the presence of the actual comments policy, which clearly states what kinds of comments will not be allowed. Overkill, I know

Another plugin is email immunizer. It is supposed to protect mailto: links from harvesters. Never tested it, though: I do not post mailto: links. This is a just-in-case measure.

Peter’s Custom Anti-Spam is a Captcha plugin, i.e. it displays some text as a picture, requiring the text be input into the provided field. Evidently, protects only comments. Not 100% efficient, as there are bots able to read images. Fortunately, the majority cannot :). This plugin is only one from many, and I chose it for no specific reasons – except that it is “fresh”, requires no additional accounts hosted somewhere, and is rather small. You can extend the list of captcha words with your own, which can be fun if used properly :).

Simple trackback validation checks if the referring page exists and contains a link to your blog. If it doesn’t – the trackback/ping can be held for moderation, added to the akismet’s spam queue, or simply deleted. This is a good one to have.

WP-ContactForm is not really spam-protection, but it helps you avoid publishing email address in any form, but people can still contact you. Note, that my contact form is protected by a “math captcha”: there is a trivial math question, which requires a single numeric answer. This is also good protection – not a single spam message from the contact form after protection was installed!

Corrections, questions, additions and comments on what you’re using are welcome.

Update: since I started using SpamKarma2 plugin, all other plugins nearly lost their usefulness. SpamKarma2 is excellent – try it! Since mid-late 2007 by Jan 2008 over 100000 spam comments were discarded on my blog by SpamKarma2, which has gone GPL way.