Remember a couple months back when I wrote about my ridiculous error log woes? Well, I must be the Queen of Crappy Logs because all that fun slammed back into my life in the form of mail log overload. So what gives!? I’ve cleaned my code on older CakePHP installations, added a new WordPress installation for a new project, swapped out any standard wp_mail() functionality for Mandrill API fun, and followed my usual routines for new websites. WHY IS MY SERVER ON FIRE!?
Apparently this hosting-space-savvy developer needed a lesson in managing a server on her own. I got to see first-hand what happens when you disregard any anti-spam precautions when firing up a new WordPress site. I’ve known about Akismet or Mollom, but never thought they were super necessary. I rarely see the deep admin side of my hosted servers so out of sight out of mind, right? NOT ANYMORE! This is now my server I need to protect; I can’t just turn a blind eye while the mail log file grows 1GB/half hour and crunches all CPU. MUST. SAVE.
THE WORLD. THE SERVER!
At first, I didn’t realize this was spam. I naturally thought back to my error fun from weeks ago and approached this instance as another flare-up. I start by referencing my friend cat /dev/null >mail.log to help clear some space. This moment of clarity lasts seconds, as the spam attempts continue to overflow the screen. I figure, “Hey, I have Mandrill hooked up. Why is Postfix even trying to work without an active local mail server?” This thought leads me to turning off/stopping Postfix.
OKAY! I’ll completely unload Postfix so HA! Won’t even be an option for ya now, server. Take THAT. Wait…what’s it doing? It’s using a DIFFERENT mail option!? Ninety-two kill PID attempts later and holy hell I’ll put back Postfix. Cripes.
::spam logs continue and I swear they’re even faster/angrier::
…ugh okay. Now what!? Why is this thing so angry! I start to wonder if it’s in fact the WordPress installation. Maybe if I turn off the site for a moment? I flip the switch — silence. Mk, so it’s definitely this WordPress site. This pause gives me a moment to actually read the lines in this out-of-control log stream. That’s when I notice a bunch of phony email addresses using our WordPress site as a domain name. I definitely don’t have any emails listed for that domain name so finally the spam lightbulb goes off. Great! At least I have a clue!
Time to bust out the anti-spam guns. The most popular solution is Akismet so I went there and got a key. Back in my day ::shakes a cane::, Akismet was free to anyone. I can understand that their popularity and success has resulted in them asking for some maintenance help. Anything would be worth a quiet mail log at this point. I snag a key and pop it into place in my WordPress installation. I also decide to shove a Captcha plugin even though I disabled all commenting for good measure. It’s amazing how resilient these spam bots are even when all commenting/pinging functionality is turned off.
Welp! It’s not complete log silence, but I can see a shift in the log messages. Instead of trying to send these spam mails through a dormant mail server, I see Akismet doing it’s job of double-checking each one and rejecting accordingly. Lovely! I may still be racking up a sizable log file over time, but at least my server CPU is back to normal and free again. Hooray!
Now that I have some time to consider alternative measures, I can’t help but question if Akismet is the best solution for WordPress spam protection. They are very robust now and provide a great third-party check, but is that server-to-server jump so necessary for the sake of some phony email? For now, I believe it is. I can see myself shifting my stance once I get my feet wet and more familiarized with the whole spam front. There are many alternatives out there that can keep you within your own server; privacy-crazed developers rejoice! Be sure to check them out for yourself and save yourself from this chaotic, spammy mess!
That’s all for now! Happy coding :)