Over the last few weeks I’ve been working on a little IMAP server that reads RSS feeds and displays them as emails through the wonders of RFC 3501.

The time has come; I’ve put the finishing touches onto my server and let it loose into the great unknown of sourceforge.

Why another RSS Reader? Well, a few reasons actually. Firstly I didn’t want to have another app constantly open in the background; I find it annoying enough with outlook open all the time. Secondly I didn’t want to use an Outlook Plugin; I’ve had bad experiences with IE Extensions and once burnt, twice shy. Thirdly I wanted to prove to myself that I could actually do something like implement IMAP to a workable state. Finally, it seemed like a fun project that hadn’t been done yet.

Why IMAP? Why not POP? Well, POP would have been a lot easier, but I didn’t want the feed emails interfering with my normal email. IMAP also had a few features that I wanted like folders etc.

I started off with the name “RSS2IMAP”, which was a little funkier, but that was already taken. (Different idea though, RSS2IMAP is actually a script that places messages on an existing IMAP server like Courier). Still a bit upset about that, but RSS->IMAP Server is a little more descriptive, even if it is boring.

It was a bit touch-and-go there for a while, especially with the character counts. I was stuck for about 4 days, Thunderbird worked fine, but Outlook would just sit there and timeout silently. Just goes to show the issues that can be caused by failing to count that last line break…

If anyone wants to help polish it up a bit that would be fantastic. Internationalisation is a sorely missing feature that I don’t really have an excuse for not putting in (Java does make it relatively easy). The code could be cleaned up some, I’ve made rather liberal use of the Collections framework (what do you expect from a PHP coder?) which was not always necessary. It should really be tested on a few other clients, Thunderbird and Outlook seem to just use the UID command, so other commands like FETCH that do the same thing may have been left behind in the final stages of development.

All in all it was fun, but I think it will be a while before I take on another one of these types of projects. At least now I can check my email using only telnet!

All redirects are not created equal.

According to the good ole HTTP 1.1 spec there are a few different types of redirect. Everything from suggesting you view from a different source (303) to insisting that the browser use a proxy server to access the content (305).

While the type of redirect you choose to use doesn’t really matter much to the client (either way they get where they need to go), it can make a difference to the search engines. The general theory is that a temporary redirect will not transfer the pagerank (or incomming link weight) to the target page as effectively as a permanent redirect.
So, what one is the best? Well, a 301 redirect (Moved Permanently) has been suggested as being the way to go. And thankfully implementing it is a sinch (well in PHP at least).

< ?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://my.new.location/");
?>

In theory this should transfer all of the page rank weight to the new location and allow the search engine to overlook the redirect page in the future.

This is handy if you have your home page in a sub-directory (like my site) and should be the next best thing to having everything your webroot.