All of this effort is being done in order to provide a better level of service to our clients and expand our value proposition to both existing and new clientele. In the next coming weeks and months look forward to hearing about all the new features and services UnderGrid Network Services will be providing. If you’ve been working with us in the past, we look forward to doing so in the future and we look forward to working with you that we have not yet had the opportunity to do so.

Recently there had been work being done to add FastCGI access to the Linux Hosting plan which already offers PHP5, Python 2.4 and Perl 5. Ruby is still not available on the system as a whole; however, that doesn’t stop you from adding it to your own account which is precisely what I did. Armed with the ability to test out FastCGI I proceeded to work on getting a very simple test RoR app setup and running.

To start with I needed to get Ruby installed. To do this I simply logged into my shell account (another great feature of Web.com’s Linux Hosting) and proceeded to download the necessary sources:

$ wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p174.tar.gz

$ wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz

With the source downloaded I then extracted them into the tmp/ directory in my account and built them.

$ tar -xzf ruby-1.8.7-p174.tar.gz -C tmp/

$ tar -xzf rubygems-1.3.5.tgz -C tmp/

$ cd tmp/ruby-1.8.7-p174/

$ ./configure –prefix=$HOME

$ make

$ make install

$ cd ~/tmp/rubygems-1.3.5/

$ ruby setup.rb

With this completed you should have Ruby 1.8.7 and RubyGem 1.3.5 ready to go. You can test by running the following couple of commands:

$ ruby -v

ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-linux]

$ gem -v

1.3.5

Now we’re ready to rock and roll… We just need a few gems to be thrown in and we’ll have Ruby on Rails ready to go and be able to use MySQL for the database. So we’ll start off with the basics…

$ gem install rails mysql fcgi

This should install any other gems that are necessary for dependencies and you can check the final list of gems installed running gem list later if you’re curious to see them all. Now would also be a good time to go ahead and clean-up your tmp/ directory as you won’t be needing all that source any more so why use up the disk resources.

Now we just need a Rails application to run, so we’ll start out with building one from scratch although if you have one ready to go then you could just upload it to your home directory. For purposes of this I’m just going to setup a Rails webapp aptly called “test” as follows:

$ rails -D -d mysql ~/test

Now we just need to go create our webapps public/.htaccess file with the necessary configuration settings. For my example I used the following for my .htaccess file:

Options +FollowSymLinks +ExecCGI

<IfModule mod_fastcgi.c>

AddHandler fastcgi-script .fcgi

</IfModule>

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteRule ^$ index.html [QSA]

RewriteRule ^([^.]+)$ $1.html [QSA]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

</IfModule>

Armed with this we just need to setup the virtual host. I set this up as test.example.com so it ran isolated from my regular non-Rails website. To do this I logged into my support account (outside scope of this entry) and setup test.example.com as a website content path as /test/public. Then while still logged into the support site created the necessary database tables test_development and test_production. You could also setup separate database uses at this time for the databases as well if you liked.

Once the databases were created I needed to edit the test/config/database.yml file with the necessary database name and credentials. Also set the database host to the appropriate hostname provided for your account. You’ll then need to setup and migrate the database.

$ cd ~/test

$ rake db:migrate

$ rake db:setup

Everything done you’re now ready to test it out and see if it all works. If you open up your browser and go to http://test.example.com and you should see the default Ruby on Rails welcome page. If you click on the “About your application’s environment” link it should drop-down and show you the version information for your Rails application. From here you’re ready to begin the rest of your webapp development.

Over the years the URL I’ve used for my key policy has changed, as well the URL itself has evolved with the times. Originally it was simply a text/plain file returned back. I have not turned it into a manager that not only presents the key policy, but also provides links to the detached signatures of the policy and verifies either the MD5 or SHA1 checksum of the policy file if provided.  This policy manager is currently being worked on to be able to provide as both a shareware and licensed versions. As it involves GPG key usage the license will be generated for the users GPG key.

Those interest can feel free to check out my key policy and watch as it evolves. Those wishing to potentially make use of the policy manager can also inquire further as there is no current targeted date for a general release.

There are so many methods out there to try and curb the amount of spam out there but never seems to be enough adoption of them. I try my best to implement what I can as I’ve fallen victim of several “joe jobs” in the past. As a result of that I looked at Sender Policy Framework (SPF) before it got introduced into the IETF track and became spf2.0/mfrom,pra. I’m still running my spf1 classic records and it has helped a bit, but I wonder just how many servers really bother to check and honor the policies published.

Likewise, recently I’ve taken the time to implement DomainKeys and DKIM on our servers. On our newest domain which hasn’t even been put to use yet so there are no email addresses in the wild I’ve actually been working to set the policy stating all emails will be signed. As I maintain the only legitimate servers that should be sending email out with the domain it shouldn’t be a problem and should hopefully limit the use of it for phishing and spam.

Another tool in the aresenal that has helped considerably has be greylisting. It’s simple, it works with existing protocols and I’m surprised more sites don’t use it. So you incur a small delay in email delivery time but it eliminates untold amounts of spam just by simply delaying the inevitable. For the longest time greylisting and SPF were more than enough to help keep my inboxes clean of most spam although I still dealt with a handful or so.

The other tools I’ve found invaluable but some consider controversial is use of DNS RBLs. While not all RBLs are created equal there are some very good ones out there that have reputable organizations behind them. I do limit the number of RBLs I check but the ones I check eliminate a fair amount of the spam that once made it through to my mailbox. The composite RBLs are even nicer as they cover more with a single query which helps speed up performance when you have multiple RBLs along with DK, DKIM and SPF all making DNS queries as well.

A good metric that things were working for me was when I had it down to less than a handful of spam messages getting through to my inbox a day. I then updated one of my forwarded email addresses on a server that had no RBLs in use to my regular mailbox address. Within 24 hours the number of spam messages that had gotten through numbered in the hundreds. I worked quickly to get that address using the same blacklists as my main mail servers and the volume of spam nearly disappeared.

Bottom line is with existing technologies it’s easy to curb the spam if more mail servers made use of them. When we can finally get authoritative authentication with the messages being delivered that will help even more. Although sadly as it’s already shown all too well, as the technologies advance to reduce the spam the spammers themselves have evolved to get around them.

Never a slow day when you’re wearing the postmaster/abuse hat but it comes with the job.