“Tell me something I don’t know”, your saying. I have a handful of sites on the grid service, from wordpress to static html. They have one common trait. Extremely long latency. Typically 1 to 4 seconds on a good day.

I’ve contacted support multiple times and it’s like speaking to a broken record. “Wordpress is the cause, Drupal is the cause, Your sucky programming is the cause” you get the picture. I guess I’m being hard on them.  How was I thinking they would respond?

Warning Extreme Sarcasm ahead.

“I’m sorry about our crappy network. We oversell accounts and so we are constantly having network issues. Let me recommend another more competent host for you. Of course we will refund your account and pay you for your unnecessary time optimizing the already optimized sites.”

If they should that kind of honesty, I might consider keeping them as a host. But as it stand now I will be switching over to slicehost.

Regardless of the situation at MT, I should be using host that gives me root access to my VPS.

P.S. Slicehost, PLEASE don’t let me down.

The trouble came when I decided to revert my code back to a previous instance, and after reviewing my site, I pushed the updates to my slice and turned on wp-super-cache. But after a few hours I noticed my site was continually going offline. Even though it never affected any of the other sites I hosted on that server.

The problem was that git doesn’t remember file permissions and I forgot to tell git to ignore the cache folder. So when I reverted back to a different version it also reverted the cache folder, its contents, and proceeded to change the permissions to what I assume was the default permissions when I first initiated the repository. So not being able to write to the cache folder made wp-super-cache crash the apache process and eventually all the apache processes took all the memory. 

So when using git don’t forget to reset your permissions, when reverting back to an earlier instance of code.

SPF stands for Sender Policy Framework. It allows domain owners to specify which mail servers they use to send mail from their domain. The policy is specified by adding a txt record containing the SPF policy to your domains nameservers. So for SPF to work the receiving mail server needs to be setup to check the sender’s domains policy.

Just because your domain doesn’t have an SPF policy doesn’t mean your email will automatically be labeled as spam, But it can help you get out of the spam folder. An emails header without a SPF policy would look like this: 

Received-SPF: neutral (google.com: 210.19.84.47 is neither permitted nor denied by best guess record for domain of www-data@gnix.us) client-ip=210.19.84.47;

Authentication-Results: mx.google.com; spf=neutral (google.com: 210.19.84.47 is neither permitted nor denied by best guess record for domain of greg[at]gnix.us) smtp.mail=greg[@]gnix.us

Once you add the policy to your nameservers, your headers will look like this: 

Received-SPF: pass (google.com: domain of greg[at]gnix.us designates 210.19.84.47 as permitted sender) client-ip= 210.19.84.47; Authentication-Results: mx.google.com; spf=pass (google.com: domain of greg[at]gnix.us designates 210.19.84.47 as permitted sender) smtp.mail=greg[at]gnix.us

Of course there are a lot of other factors that spam filters use to eliminate spam, but adding an SPF policy is an easy way to add trust between email senders and spam filters.

On SPF’s website, they have a wizard to generate your TXT record. Just input your domain and answer a few questions about which mail servers will be used to send emails from your domain.

SPF isn’t the only protocol that tries to validate the sender of an email. And out of the three big webmail companies (Google, Yahoo, Microsoft) only Google checks for SPF records. Here’s a summary on what the others use.

Microsoft

Sender ID - Is confusingly similar to SPF. they both validate email sender addresses and both use dns records to publish their policies. I won’t get into the differences, but they are different.

Yahoo

Domain Keys Identified Mail (DKIM) - Signs the email with a key, and then the recieving mail server verifies key from a record in the sender’s domain nameservers.

SPF - They don’t check for SPF records, but they do have a SPF policy in their dns records.

Google

SPF, DKIM

If your serious about your email getting through spam filters, you should look into DKIM. Unfortunately DKIM requires a lot more effort to get working, but is probably the most supported.

As far as content goes, and as long as I can stay on topic, 90% of my posts will be about web design. A more detailed list of topics are as follows:

• (x)html
• css
• javascript
• php
• mysql
• server settings
• photoshop
• illustrator