New interface and login screens rolled out

Summary

Almost a year ago we rolled out a new webmail interface for users to test on our beta server. During the last year we have made significant updates, improvements and tweaks, and today we are launching this as the main interface for our users, along with a redesigned homepage and website at www.fastmail.fm.

Features

The main improvements the new interface brings are:

  1. Speed — Opening and dealing with email is now much faster, with many actions happening instantly, thanks to a full redesign with modern technologies that allow for pre-fetching and caching.
  2. Conversations — Emails on the same topic can be grouped together into conversations (even across folders), so you can see the back and forth history of messages, replies and forwards. Of course, this can be turned off if you like to deal with all messages individually.
  3. Push updates — New email deliveries are pushed straight to your Inbox, so they appear instantly without you needing to refresh.
  4. Archiving — To make dealing with your Inbox easier, the new default action is to Archive messages. This allows you to quickly move messages you have dealt with out of your Inbox, but still keep them for searching and referencing at a later date.
  5. Simplicity — FastMail has always provided power, but in some cases that has caused extra complexity where it is not needed. We have reduced the complexity of many of our configuration screens to make common tasks easier. For example, setting up automated retrieval of email from an external account now requires just a username and password in most cases, the rest is automatically determined.

We’ve put together a short (2 minute) video showing how all these improvements (and more) come together to create a great experience for our users.

Existing interface

While we believe that this new interface is a huge improvement, if you would like to continue using the existing interface, you can do so by checking the “Use classic interface” checkbox on the login screen (click the More link on the login screen to see it), or by logging in via https://classic.fastmail.fm. Older browsers that do not have the required support for modern web technologies used by the new interface, such as Internet Explorer 6 or 7, will also continue to get the existing interface automatically.

If you are thinking of continuing to use the existing interface because of some particular feature you like, then also consider that an equivalent might be available in the new interface as well. For instance, if you really don’t like conversations, you can disable conversations on the Settings –> Preferences pane, select the “Show every message separately” radio button. Similarly, if you don’t like the preview on every message, you can also turn that off on the same page. Unfortunately you can’t show a preview for only unread emails, it’s either all or none with the new interface.

Help

We have not yet updated our help documentation; we are currently working on that and hope to have it done soon. We do not believe this is a major impediment to users using the new interface as most of the features are highly discoverable as needed.

Posted in News. Comments Off

Changes to FastMail service levels

Summary:

  •  Guest accounts discontinued for new signups (existing accounts remain)
  •  New personal service level: Premier, which is the same as Enhanced, but with increased storage and included SMS credits.
  •  60-day free trials for all service levels

Details:

After FastMail became a part of Opera Software, our technology was used to build the free My Opera Mail service. This has proven very popular, to the extent that we now have considerably more free @myopera.com accounts than free @fastmail.fm accounts.

We’ve therefore decided to consolidate FastMail as a premium brand with only paying accounts. This will allow us to continue to offer the configurability that FastMail users have come to expect, and also to improve our customer support for FastMail users. Users that want to sign up a free account should go to the My Opera Mail service.

To this end, we are discontinuing sign-ups and downgrades to the Guest service level. Existing Guest accounts will continue to work. We have no plans to cancel active Guest accounts. However, if a Guest account is deactivated because it has not been used for 120 days, then it will not be reactivated.

To give people a chance to try out FastMail before committing funds, we are introducing a 60-day free trial for our paid service levels. You may have already noticed this if you have visited our sign-up pages recently.

In addition, we are also introducing another personal service level: Premier. This will have all the features of the Enhanced level, including Priority support, but with 60 GB mail storage, 30 GB file storage and 400 SMS for $119.95/year. The features of Enhanced have not changed in any way.

 

Posted in News. Comments Off

New login and session management code on beta.fastmail.fm

We’ve just rolled out some new code on our beta server that significantly changes how sessions are managed. This new code reduces some overall session complexity, fixes some long term bugs, and adds some useful new features.

  1. There’s now just 2 main types of sessions: normal & long term
    • normal – these expire after 2 hours of inactivity
    • long term (you check the “Keep me logged in” checkbox on login) – these expire after 30 days of inactivity, for most people on most machines, this is effectively forever

    (Note: The "Keep me logged in" checkbox has been broken for the last few months on the beta server, but now correctly creates a long term login session. Also the "lightbox" login screen within the new UI now correctly works.)

  2. Logout will explicitly end a session 

    If you want to explicitly end a session, use the "Log out" link at the top right of the page. If you want to keep a session, just close the browser tab/window and when you go back to the beta server, you’ll still be logged in (see below).

  3. You can still log in to multiple different accounts

    We still support the ability to log in to multiple different user accounts at the same time on the same device/browser.

  4. You can access existing logged in sessions from the login screen

    If your device/browser has any existing logged in sessions, we now show those sessions when you go to the login screen. Simply clicking on one of those sessions will send you straight back to that mailbox for that user.

    Although by default the login screen shows existing logged in sessions, clicking the "Log in to another account" link will allow you to log in to another account at the same time.

  5. You can see (and remotely log out) all logged in web sessions on all devices/browsers

    We now track all sessions in our database and allow users to see all these sessions and remotely log out any of them individually.

    Just go to Options/Accounts –> Logged In Sessions to see all sessions in all devices/browsers. Currently only sessions created on http://beta.fastmail.fm can be deleted.

    (Note: Only web sessions are shown. IMAP/POP/XMPP/etc logins are shown on the Options -> Login Log screen)

One observation that some people might make is that with the old system, if you were logged into your account, and then closed your browser window/tab or went to http://beta.fastmail.fm again, it would appear that your existing session was automatically logged out, a nice security feature.

In fact that was never the case, the session was not logged out. Simply picking the right URL from your browser history would take you straight back in. There was just no visual indication on the login screen that this existing session was still present in your browser cookies, which is actually quite dangerous. The new system correctly shows any existing sessions on the login screen. If you want to end a session, you must use the "Log out" link at the top right of the page, whether you’re using the new system or the current system still at http://www.fastmail.fm.

Posted in News, Technical. Comments Off

Search currently broken on beta.fastmail.fm

We’re currently in the process of rolling out some new vastly improved search code (more details in a future post). This code will allow fast searching across all message headers (from/to/cc/bcc/subject) and message bodies, across all messages in all a users folders. Finally!

Unfortunately this process will take a week or two to complete, and in the meantime searching in the new AJAX UI on http://beta.fastmail.fm will be broken for most users. This doesn’t affect users using the regular interface at http://www.fastmail.fm

Sorry for any inconvenience, we hope to get it fully working ASAP.

Posted in News. Comments Off

Goodbye old.fastmail.fm

Summary

In early 2009 we rolled out an updated web interface to all users. This is the interface you currently see when you login at http://www.fastmail.fm as most users do.

To give users time to transition, we continued to let people login to the old pre-2009 interface if they wanted to by going to the web address http://old.fastmail.fm. We’ve continued to support this for the last 3 years, but as only a few users are still using this interface, we decided to shut it down. For the last 3 months there’s been a prominent message each time you logged into http://old.fastmail.fm that noted this, and we’ve now fully shut down http://old.fastmail.fm.

Important point: This only affects users that were explicitly going to http://old.fastmail.fm to login. Users that use the regular interface at http://www.fastmail.fm (the vast majority) are completely unaffected.

The description below is a detailed history of the old interface and includes technical details about how much things have changed since 2009 and why maintaining http://old.fastmail.fm is no longer feasible.

Goodbye old.fastmail.fm

It’s been a long road, but the old FastMail web interface has finally reached the end of its life.

You can always access your email at https://www.fastmail.fm/ or try our beta site at https://beta.fastmail.fm/.

If you want to stop reading here, the things you need to know are security concerns and it was about to break anyway. Two good reasons why now is the right time to shut the old interface down.

If you want to know some of the technical background and the technologies that we have moved through over the years, read on!

A new infrastructure

Looking back through our version control history, my very first commit was on 2004-09-20! The original web interface commits are from early 2000, though it was started before then.

We switched version control systems at some point during 2005 from CVS to Subversion, which made branching much easier – but imported all our history, so we can still look back at those early changes.

One of our major branches was a huge infrastructure switch from Redhat 7.3 to Debian 3.1 (sarge), which we worked on throughout the second half of 2005. This was all merged back into the main branch, and we converted everything over in early 2006.

http://blog.fastmail.fm/2006/01/02/one-web-server-now-running-new-infrastructure-code/

We upgraded to Debian 4.0 (etch) during May 2007, soon after it came out.

A new interface

In 2008, Neil Jenkins (who is so awesome Opera hired him even before they had decided if they were going to buy FastMail) worked as a contractor over the summer to design a more modern web interface which would take advantage of the new features in web browsers.

We branched the code, and it diverged quite considerably. Features like cross folder searching required major internal datastructure changes, and the new interface had hooks all through the code. Our plan was always to retire the old code eventually.

We released the new interface to beta at the end of 2008, and rolled it out to everyone in 2009.

http://blog.fastmail.fm/2008/11/27/help-beta-test-new-web-interface/

http://blog.fastmail.fm/2009/02/17/new-interface-being-rolled-out/

An incompatible upgrade

Then in 2009, Debian 5.0 (lenny) came out. Lenny shipped with apache2 and mod_perl2, and no longer supported apache 1.3 or mod_perl version 1. We put quite a lot of work into porting our codebase forwards to apache2. Since "old" was going away soon, we didn’t duplicate the work there.

So we installed the new web servers on lenny, and kept a couple of servers called "oldweb" still running etch. It’s amusing now to remember all the hoops I jumped through to allow automatic installation of either system.

About this time we also had machines with enough memory that 32 bit address spaces were wasteful, particularly on the IMAP servers. We moved to running 64 bit kernels with 32 bit userland.

New hardware

In 2010, the Opera sale happened. One of the early steps was to replace some of our aging hardware with equipment that was better understood and supported by the Opera sysadmin department. This meant a new bladecentre for the non-storage systems (including web)

For a little while I had two blades (redundancy!) running "oldweb" code. That’s a huge amount of very under-utilised resource.

And, to be honest, managing new blades with ancient OS was a pain. Things didn’t work well. The configuration tools we built for the new hardware didn’t run on etch.

When we moved to Debian 6.0 (squeeze) and at the same time went fully 64 bit, it was time to do something about "old".

We also moved version control systems AGAIN in late 2010 – from subversion to git. The old web servers were left on subversion, because they weren’t getting much in the way of changes any more. One more "split" in how things were done.

Fully virtual

Rather than having to support "real hardware", I built an etch virtual machine. Everything else was running squeeze 64 bit, but we still had a full 32 bit etch install path just to support oldweb.

While all this was happening, there were occasional changes required to support changing database schemas, configuration mechanisms, and interaction with other parts of our system. At some point I just took a snapshot of the current tree and started a new git repository so we could archive the subversion server entirely.

Maintaining the virtual machines was a real pain though. They were run in the background on some of the web servers to free up the hardware for more demanding tasks. This meant changing the network interfaces to be bonding drivers, custom configuration, lots of pain. There were occasionally long outages as we changed things and then had to patch oldweb to catch up.

Worst of all, we were maintaining the ENTIRE stack – support daemons, log rotation, pop fetching…

Old lost features over time – we just couldn’t keep them working, so we ripped the code out. Particularly some of the more advanced configuration screens – and everything related to billing.

Single component

In the end the virtual machines were too much work. Our authentication system in particular had many changes under the hood, and it just wasn’t going to keep working. We had a couple of really bad problems with file storage, where we were sure that something "couldn’t happen", but then it turned out old was still doing things differently. Talking to the wrong databases, running the wrong queries. We seriously considered dropping old at that point, but I wanted to give it a bit longer.

So I build a chroot installation of etch on our web servers, and bind mounted the daemon sockets into the chroot. This allowed us to run just the web interface code itself on the old branch, while running everything else in the modern, managed, outside world. I built a custom init script which could set up all the necessary mountpoints (/proc, /dev, /var/run, even the tmpfs with mmaped caches was shared) – and forward ported more of the code.

This was built with debootstrap originally, but in the end it was getting unreliable even fetching etch packages, so I build a .tar.gz file with the filesystem for the chroot, and a fresh install just unpacked that. As we changed internal config systems, I kept "oldweb" up to date. A couple of commits every month.

So that’s brings us to today. An init script (apache-oldweb), a chroot environment with a snapshot of a Debian etch machine with apache 1.3 and mod_perl version 1 – running perl 5.8. Everything else is perl 5.10 or newer, so I even have to backport some idioms as I bring back the bits which it just can’t live without.

I have done basically all the "keeping old alive" for the past couple of years – for a smaller and smaller set of users who still log in there. Backporting everyone else’s changes as they impacted old.

And etch doesn’t have security support. Hasn’t for ages. Sure it’s in a chroot, but it still has access to everything.

The final straw

But there’s one thing which oldweb can’t survive. We are redesigning how our session management works. There are some great benefits – bookmarkable URLs, remote logout of stale sessions, reduction of password typing on annoying little smartphone keyboards.

Everything will change, and old would have just stopped working. It’s not worth the changes to make it work. Particularly with the larger gap between the two systems as time goes on.

Also, and even worse, old interface is exposed to the wider internet – and it has full read/write access to the database and all emails. If there are security problems, all our users are at risk – not only those who use it directly.

It’s no longer safe, and it was going to break beyond easy repair in a few days anyway. It is time.

Goodbye oldweb

Posted in News, Technical. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 5,142 other followers