One of the positive developments on the Internet over the last few years has been increased encryption of e-mail. The Internet is a hostile environment; sometimes your data goes through the servers and routers of companies you’ve never even heard of, or of governments you’ve heard of but don’t like. It makes sense to encrypt e-mail whenever possible.
We’ve supported encryption between our customers and our e-mail servers for a long time, protecting you from eavesdropping “hackers” when you use a WiFi connection at an Internet cafe, for example. But like most companies, we didn’t try encrypting outgoing e-mail after it left our servers or encrypting incoming e-mail from other servers. Although technical standards for doing that exist, they’re relatively new in Internet terms, and our original testing indicated it could cause problems with mail delivery due to many misconfigured servers on the Internet.
That’s changed: More recent testing indicates that it’s much more reliable, and other large companies like Gmail are starting to use it. Because of that, we now use strong TLS (SSL) encryption for inbound and outbound SMTP mail connections (“MX” mail delivery) wherever possible.
Read the rest of this entry »
We’ve renewed the SSL certificate on our mail servers (because it was due to expire soon).
Almost all customers shouldn’t notice any change, but if you read e-mail using a secure connection with an unusual mail program that doesn’t handle SSL connections properly, you might be asked to “accept” the new mail.tigertech.net certificate.
Read the rest of this entry »
If you use WordPress blog software on your site, be sure to upgrade to WordPress 3.0.2 as soon as possible. The upgrade contains an important security fix for a vulnerability that allows any WordPress “author” to become an “administrator”.
Although all WordPress users should upgrade right away, we’ve added security rules to our servers to protect our Web hosting customers who haven’t yet upgraded. Other people may find the rules useful if they use mod_security on Apache Web servers. The rest of this post contains more technical details.
Read the rest of this entry »
A recently published Firefox add-in named “Firesheep” can be used by “hackers” to easily hijack the connection of any nearby WiFi users visiting many popular Web sites such as Facebook, Twitter, or Hotmail. This vulnerability is a basic artifact of the way the Internet works. In order to prevent this problem, these sites will need to properly implement SSL (https) security.
Read the rest of this entry »
Google has announced that they’ve created a nifty new Apache Web server module called mod_pagespeed that can speed up some Web sites.
We’ve been asked if we’re going to offer it, and the answer is “probably, but not yet”.
Read the rest of this entry »
We’ve fixed a bug in our Webmail system that could, in rare cases, make Japanese language symbols display incorrectly. This change shouldn’t affect anything else, but as always, feel free to contact us if you have any trouble.
Read the rest of this entry »
When we store older Apache Web server access logs for your site — those that are more than two months old — we re-compress the original logs into single monthly files. These take up less disk space for your account when you have a lot of them. (We have some customers with log files going back more than ten years!)
Until now, we’ve re-compressed these files using gzip compression. However, we’re going to switch to a different modern compression format, bzip2 compression, which reduces the size even more. The resulting files are about half the size of gzip.
Read the rest of this entry »
Even if a Web site hosted with us doesn’t have an SSL certificate, our servers used to accept improper secure SSL connection attempts that start with “https://” instead of “http://” in the beginning of the URL (note the extra “s”). We’re changing that.
Read the rest of this entry »
Three of our Web hosting servers (amy, flexo, and leela) experienced high load earlier today that caused some customers to see “503 errors” on their Web sites for a few minutes.
This was caused by an upgrade to the eAccelerator PHP caching system that removed all the cached files at once, which doesn’t normally happen.
The problem has been permanently resolved and will not recur.
Read the rest of this entry »
WordPress installations handle missing image files very inefficiently by default, running the entire WordPress script to build a custom “404 Page Not Found” page rather than simply letting Apache return an immediate default “404” response. Running the WordPress script when not necessary is a huge waste of processor time. For example, WordPress might be able to only process 8 requests per second for a missing image when WordPress generates a custom “404” page, but Apache can return process over 1,000 raw “404” responses per second. If your Web site contains references to missing files, this default WordPress behavior can be driving up your CPU usage unnecessarily. We’ve seen poorly-configured Web sites spend a significant portion of their CPU time processing missing images.
Read the rest of this entry »
