Short of a server going down, one of the quickest and most effective ways for a Blog to die is for it to drop out of search engines. Sure, you might have a ton of repeat visitors, but no search ranking means no new visitors because, well, no one can find you. What a blinding flash of the obvious.
Read More
Just in case you’ve been keeping track, this is the seventh time a Spammer has forged one of the domains under my control as the return address of their Spam run. The first time it happened I felt shocked, angered, and betrayed. After I lost count of the incidents on my left hand and had to move on to my right hand to keep track it now just feels old-hat. Sure, it still pisses me off, but I now just chalk it up to being the owner of many high profile domain names.
Previously I noticed Spam runs immediately because the mail server started choking on the influx of bounces. This time the domain in question had a Barracuda Spam Firewall 200 sitting on the front lines in the DMZ; I didn’t notice the barrage until the midnight reports ran and I received the pretty pie charts showing a 600% increase in e-mail (and that was just the first day).
Days 2 and 3 jumped up to a 800% to 900% increase in e-mail before starting to plateau and drop off on Day 4. All in all around 350,000 bounces were blocked which is pretty routine for a forged run but the Barracuda performed without so much as a hiccup.
And, for the more visual among you, I’ve of course attached the obligatory pretty graph to show what a Spam forgery looks like. Green is legitimate e-mail, red is blocked Spam, magenta is bad recipient, and blue is rate control (too many connections).
By default, UNIX-based servers running Plesk and the Courier-IMAP e-mail server drastically limit the number of inbound connections to prevent users from opening up too many concurrent sessions. Unfortunately, this artificially-low restriction can impact legitimate users who have multiple computers connecting to the Courier-IMAP server from behind a firewall or a single computer that runs an IMAP client that takes advantage of mailbox caching.
Plesk comes configured with a limit of 4 connections per IP address and a limit of 40 connections total. Modern IMAP clients such as Mozilla Thunderbird use mailbox caching to open up multiple connections to increase performance. In the case of Thunderbird, it opens up 5 connections by default which is already 1 connection more than Courier-IMAP’s default restriction. Add another few family or corporate computers behind a firewall and those additional users won’t be able to connect at all since a single Thunderbird client is already utilizing all 4 connections.
To increase this restriction, modify the /etc/courier-imap/imapd configuration file and change MAXDAEMONS and MAXPERIP to a more sane number. In the case of my configuration, I changed MAXDAEMONS from 40 to 80 and MAXPERIP from 4 to 40. This allows all the machines behind my home firewall to connect to multiple accounts on the e-mail server with mailbox caching enabled.
But even those numbers may be too low for a corporate colocated server that services an entire company. Tweak those numbers based on your employee base; if 50 employees are connecting to the e-mail server from behind the same firewall then MAXPERIP could need to go as high as 250 (50 employees times 5 cached mailbox connections). Add e-mail clients of people working from home and MAXDAEMONS could go as high as 300 or 400.
Obviously, the connection limits are to prevent the Courier-IMAP server from using too many memory and CPU resources on the machine. Tweak the numbers based on the memory footprint of each daemon process and how much memory you have.
The most recent batch of RedHat Enterprise (RHEL) fixes rolled out this past week break DNS (bind) on servers running Plesk. My Plesk 7.5.4 installation was effected as well as many other Plesk 7.x and 8.x users. The problem appears to be with a conflict between RedHat’s bind-chroot RPM and Plesk’s chroot system.
When the latest RHEL RPMs were rolled out the /etc/named.conf symlink which should point at Plesk’s /var/named/run-root/etc/named.conf config file was changed to point at RedHat’s default /var/named/chroot/etc/named.conf file. Post-install scripts then munged the location of the Plesk config files. This resulted in the following error when starting or restarting the nameserver:
none:0: open: /etc/named.conf: file not found
A thread was started in the Plesk forums reporting the problem and a Rackspace employee replied in an earlier thread with a fix.
Basically, rpm -e bind-chroot to remove the RedHat RPM that conflicts with Plesk and then re-symlink /etc/named.conf to point back at the proper /var/named/run-root/etc/named.conf config file. This drops Plesk’s config files back into place.
One of my co-workers called me over to his desk this afternoon to show me an e-mail thread that had been bouncing around between a few of his family members. It went something like this:
Original E-mail:
Save those old phone bills!
If you can’t access those articles for some reason, you can Google phone tax Spanish and get several articles that tell about the decision to end the 108-year-old tax that had been implemented to help pay for the Spanish-American war.
Bottom line – you may be able to get refunds on taxes paid. 3% – may be worth it to you. I don’t know how much hassle will be involved.
According to the USA Today article, you can file for refunds back to 3/1/03 (2003, not 1903).
Response #1:
Crap! I just shredded all of those.
Response #2:
Call up NSA – they should have the records [VBG]
Werd. I love the Internet.
I’m running a combination of IOG and MRTG to keep track of network traffic and ran into a little bit of MRTG cronjob retardedness. In my haste to get MRTG up and running I forgot that it’s enabled by default on RedHat Enterprise Server even if you haven’t configured it yet. So, when I manually added it to my crontab, it actually ended up running twice in parallel. The result was MRTG eating its logfiles a few times per day so I had no history.
So, for any of you receiving the following errors, double-check your crontab and make sure MRTG is only running once!
Rateup WARNING: /usr/bin/rateup could not read the primary log file for colo1.pixoul.com_2
Rateup WARNING: /usr/bin/rateup Can't remove foo.old updating log file
Rateup WARNING: /usr/bin/rateup Can't rename foo.tmp to foo.log updating log file
Mac OS X Mail.app doesn’t properly work out of the box when connecting to a Courier IMAP (Plesk) mail server. If Mailbox Behaviors is configured to save Drafts, Sent, Junk, or Trash on the server then Mail.app will constantly report the error The message could not be saved. Quite annoying and, in the case of the Sent mailbox, Mail.app will happily just send the message to the bit bucket and not tell you.
To solve the problem go to Preferences, Advanced, and use INBOX as your IMAP Path Prefix. Problem solved!
Many thanks go out to MacFixIt and SpamapS.
Update (03/29/2007): Please note that this fix is not a magic bullet and is specifically for Courier IMAP mail servers running on Linux managed by a Plesk control panel environment because that’s the only place I’ve tested it. There are literally hundreds of different IMAP servers out there and each one has its own quirks and configuration options.
One of my co-workers was having problems connecting to the VPN at work and fired me an e-mail:
Looks like my IP address at home changed. Would that irritate the SonicWall? My new IP is XXX.XXX.XXX.XXX, can you feed that to the SonicWall? I’ll sacrifice a chicken or two over here, maybe together we can get it to work.
I updated his IP address on the firewall and got the best response evar:
OMG it works now!!!11
kthxbye
Ha. I love my co-workers.
When training the Bayesian filters for SpamAssassin, be very careful about using sa-learn on your active IMAP inbox. Most IMAP clients don’t actually delete messages until they synchronize the mbox. So, after deleting around a hundred Spams, I ran sa-learn over my inbox and SpamAssassin happily learned all of the Spams I had marked deleted as Ham (non-Spam).
Since it was a few hours before I realized what had happened when the incoming Spam getting by SpamAssassin increased tenfold, it was too late to run sa-learn over the old Spams because they had already been truly deleted.
I had to wipe my Bayesian database and start over. No big deal; just inconvenient.
I suck.