I was reading through MT Plus Comment Spam Equals Dead Site again (an interesting read), which prompted me to consider many of the points within. For those who don’t know, this post, along with the activity that generated it, was a big part of the reason behind the development of MT-Approval. I was doing it anyway, but that forced the issue to happen a bit faster.
Much of the problem that happened at the time was the sheer load that was generated by Movable Type, even with MT-Blacklist installed, and even in instances where the comment was moderated. These issues were addressed with an update to Movable Type and also through a later release of the MT-Blacklist software, but the general problem still remains.
The problem is that Jay, who has done an excellent job by any account, is overriding the default post function in Comments.pm, and any plugin, including MT-Approval or anything else attempting to short-circuit the comment posting process to avoid spam, will run after MT-Blacklist has had a shot at it. The MT-Blacklist post handler runs, and then if things pass the check, the process is handed off to the regular post process, and any callbacks used within that process. This means that any performance hits from MT-Blacklist will still be in effect.
That’s not to say that it will have problems. I don’t run MT-Blacklist, so I can’t speak to its performance or even to its usefulness. I just know that because of this method it runs prior to other plugins, and as a result you may not see the problems go away if you install MT-Approval or some other plugin in hopes that it will resolve your problem. To get the full effect of MT-Approval, it should be installed only with other plugins that support the callback interface. MT-Moderate, for instance, does this.
This isn’t to say that there is anything wrong with MT-Blacklist or the way it works. Just keep in mind that installing MT-Approval in hopes that it will prevent MT-Blacklist from getting a chance and causing a spike in processing is unlikely to happen because of the design of MT-Blacklist. Until Jay changes the way that MT-Blacklist interfaces with Movable Type (which may or may not ever happen), please remember that MT-Approval will run, and will likely catch some spam that MT-Blacklist cannot, but you are not preventing traffic to MT-Blacklist by installing MT-Approval. Due to its design, MT-Blacklist will always run first.
Comments
2 responses to “Revisiting Comment Spam”
Sure, Ted, I understand completely that MT-Blacklist does what it does very well. That wasn’t the point. A couple weeks ago, when there were servers all over getting blasted by what is commonly called “crapflooding”, servers were going down because they couldn’t handle the load put on them. It was only peripherally related to the spam. The servers simply couldn’t handle the traffic because of the resources being used.
MT-Approval is designed, in part, to help with this problem by discarding invalid comments before a signifcant amount of database processing has to happen. There is some that is required simply by starting up the process, but MT-Blacklist uses a bit more because it has to go and verify all of those comments against the blacklist. Jay has made some improvements to it, but this was a part, albeit a small part, of the problem.
I just wanted to point out that people installing MT-Approval in order to eliminate that as a possibility were going to be disappointed, because MT-Blacklist will indeed still run because of the design – it will, in fact, run prior to any plugins because of the way that it is coded. Does not mean at all that it doesn’t work. Just hoping to illustrate how it works.
As you know, I run MT Blacklist and am very pleased with it. I also use CloseComments so that only posts that are on my blog “home page” allow comments. This has almost completely eliminated comment spam.
On occasion I do get half-dozen spam entries, but MT Blacklist lets me burn them out in just a few seconds.