Announcing the FastMail Calendar

After 9 months of intense work, we’re very proud to announce a major new addition to FastMail. We’ve taken all the great things about FastMail’s email hosting and applied them to build an awesome new calendar. You get the same incredibly speedy and elegant web interface. The same robust, fully-redundant backend (with live off-shore replicas). The same power behind an easy-to-use interface.

Our new calendar is packed full of the features you need to stay organised:

  • Continuous scrolling, because life isn’t broken into months.
  • Two-way sync with your existing Google or iCloud calendars.
  • A great experience on mobile browsers – just like with email.
  • Real-time updates, so changes are displayed immediately on all devices.
  • Multiple time zone support.
  • Powerful sharing options for easy collaboration.

We could go on, but really you should just try it for yourself. Head over to https://www.fastmail.fm and log in to your account, or if you don’t yet have one you can sign up for a free 60-day trial. Alternatively, find out more about what our new calendar can do by exploring our documentation.

A major addition like this would often be added as a separate service, but we’re delighted to announce that the new calendar will be available at no extra cost for all our paying subscribers. Most accounts also get CalDAV access included as well for syncing with your favourite mobile calendar app. More information about which accounts have CalDAV access
is available on our new pricing pages.

With contact synchronisation coming very soon now, we’re looking forward to meeting all your communication needs in one place.

We hope you enjoy using our new calendar as much we’ve enjoyed building it. As always, we’d love to hear what you think! Please let us know via support, twitter, etc.

The FastMail Team

Posted in News. Comments Off

Increased spam getting through for the last few days

Due to an undetected compatibility issue between some software modules we use for detecting spam emails, for the last few days a number of the tests we use to detect spam haven’t been working properly. This means that for the last few days, considerably more spam may have been getting through our filters and into users Inboxes.

We’ve now fixed this issue and have added additional tests to ensure this doesn’t happen again.

For those interested in the technical details: We upgraded to a newer version of Net::DNS and the version of SpamAssassin we use was using some internals from Net::DNS that had changed with the new version. This caused all RBL lookups to fail. Failing RBL lookups wouldn’t cause any email delivery to fail, just all RBL scoring to be ignored.

Posted in News, Technical. Comments Off

Making FastMail even more secure

We have a great responsibility at FastMail to keep your email secure. As part of our continual process to maintain and improve security, we recently made a number of changes. This blog post summarises what we’ve done and why it makes your email even more secure. It’s also a useful checklist of security measures to think about if you run your own web application.

This is a technical post for information only. You do not need to make any changes to your FastMail account or your email software.

Preventing cross-site logins

Cross-site request forgery is a common security problem on the internet. Briefly, if you are browsing a malicious website A, that page can make a GET or POST request to any other website B, which includes any authentication cookies you have for website B. The page making the request from website A can’t see the response, but if the request changes state on the server it could compromise the account, for example by forwarding all of your mail to the attacker’s account.

FastMail has long had robust CSRF protection throughout our application. However, one thing we didn’t protect from CSRF was the ability to log in to an account. At first glance, an attacker being able to log someone into the attacker’s own account doesn’t seem like much of a security problem. However, there are two issues that can arise from this:

  1. An attacker could manage to confuse the target into sending an email from the wrong account. This is easy to do if you’re not expecting yourself to be logged in elsewhere. The email could then be read by the attacker.

  2. Any stored XSS vulnerabilities that only affect the user’s account suddenly become much more exploitable. For example, suppose a user’s folder name was not properly escaped somewhere: it could be used to inject a script into the page. Since only the user can modify the folder name, and the pages that show that folder are only accessible when logged in as that user, this does not help an attacker target anyone but himself. However, if the attacker can log someone else into his account and force the script to run, then he could potentially access any other accounts that the target is currently logged in to.

Given these risks, we’ve now taken steps to prevent logging in to a FastMail account from anywhere other than our own login form. Since on the homepage we don’t yet have a session (at least not one that lives longer than a couple of minutes), we’re doing strict referrer checking instead of using a CSRF token. The “Referer” header in the POST request must be present and must match the protocol and host (normally https://www.fastmail.fm), otherwise the login is rejected. (And yes, the referrer header really was standardised with an incorrect spelling.)

Whilst there are several ways of stripping a referrer header, as far as we are aware there is no way to fake one without using a browser extension or the like (at which point the extension could do anything it likes to the page, and no amount of CSRF tokens is going to save you).

Moving all user websites on to user.fm

FastMail has long had a feature where you could host some files or a small website via your FastMail account. For the account joebloggs@fastmail.fm, for example, we offered the ability to host files at joebloggs.fastmail.fm.

Unfortunately, this provides another way to log a user into your own account, because cookies are not subject to the same security restrictions as other web features. A user webpage cannot read any of our session cookies (on the http://www.fastmail.fm subdomain), so it cannot steal a session, however it can write its own cookies to the fastmail.fm domain. There’s no way for our server to tell that these were not created by us on the http://www.fastmail.fm domain. If you log into your account on your computer, you could then take the cookie and write it to someone else’s computer via your website, effectively logging them into your own account.

To resolve this, we’ve moved all user content on to a new domain, user.fm, and set up redirects so existing URLs will continue to work. For example, joebloggs.fastmail.fm will now redirect to joebloggs.fastmail.fm.user.fm.

Please note: this does not apply if you have your own domain. That will continue to work just as before. The move is only for content at one of our domains.

Content security policy

Cross-site scripting (more commonly known as XSS) is by far the most common type of security vulnerability to occur in web applications. An XSS vulnerability allows an attacker to inject a script into a web page on the target site, allowing them to access any data the user is currently authorised to access.

Arguably one of the biggest steps towards improving the security of web applications in recent years is the introduction of the Content-Security-Policy (CSP) header. You can use this to control what resources a modern browser will allow the webpage to load and run. We’ve been testing this on our beta server for some time, and we’ve now rolled it out to production. The CSP we are using for most of our webmail pages is the following:

default-src 'self'; script-src 'self' 'unsafe-eval' https://api.pin.net.au;
style-src 'self' 'unsafe-inline'; font-src data:; img-src *;
media-src 'none'; object-src 'none'; report-uri /log/csp

The most import thing about this policy is that it does not allow inline scripts to run, or for scripts to load from domains other than our own (with a specific exception for our payment provider). This means that should a future XSS bug be discovered, an attacker cannot exploit it against you if you are using a modern browser: the only scripts that can run are those hosted on our own domain (which are all written by us and known to be safe).

The other big change we’re going to be making next week is to move most user content off the fastmail.fm domain. When you open an attachment it will load in the fastmailusercontent.com domain instead. This is an isolation measure to provide an extra layer of security via the browser cross-origin restrictions. At the moment, we use a Content-Disposition: attachment header to force the browser to download rather than open any potentially dangerous files (all files except for a few specific safe MIME types such as JPEG images). Because each attachment will be isolated on a different domain (with a per-message authorisation key), we will also be able to allow more types to be opened in the browser, as each attachment is effectively sandboxed and cannot access sensitive data.

Bug bounty

Like many other internet companies, we recently introduced a security bug bounty program as a way of encouraging responsible disclosure and rewarding security researchers for their hard work.

We’d like to say a public thanks to the first two recipients of our bounty: Prasant Sharma for disclosing a stored XSS vulnerability in our support ticket system, for which we awarded $1000, and V. Harish Kumar for finding two minor self-XSS vulnerabilities, for which we awarded $200.

We welcome all whitehat security researchers who wish to help us maintain our high security. Full details of the rules and how to submit a vulnerability are available on the security issue reporting guidelines help page.

Other measures already in place

The following additional security measures have been in place for some time, but we’ve not blogged about them before.

Secure, HTTP-only cookies

All session cookies are marked “Secure” and “HTTPOnly”. This means the browser will not send them over an unencrypted connection, and they can not be read using JavaScript. This means that should an XSS attack occur, the attacker can only steal data whilst the page is still open on the victim’s computer: he cannot steal the cookie to transfer the session to another computer.

HTTP Strict Transport Security

We send the following header back with all of our responses:

Strict-Transport-Security: max-age=31536000

This tells all modern browsers to, from that point on, only connect to us over HTTPS, even if the user types in a non-HTTPS URL. This reduces the chance of a man-in-the-middle attack intercepting an insecure connection and proxying the user, instead of redirecting them to the secure site.

Frame protection

With basic support even in browsers as old as Internet Explorer 8, the X-Frame-Options header is the easiest and best way to prevent click-jacking and other attacks based on embedding your web app inside a malicious site. By setting the header X-Frame-Options: SAMEORIGIN, we only allow our pages to be framed by other pages on our domain.

Disabling content type sniffing

Content type sniffing is where browsers ignore the MIME type sent by the server and interpret the content as something else. This can be dangerous, as something that the server thought was safe (such as an image) could be interpreted by the browser as an HTML page, opening you up to XSS attacks. We disable this behaviour by setting the X-Content-Type-Options: nosniff header.

Working towards a secure web

We strongly believe in making the internet more secure, and one of the ways we feel we can help make this happen is to publicly document more of the security measures we have in place. This serves to both help educate and inform other sites, and to allow public scrutiny to improve our processes.

Thanks for reading, and as ever, thanks for using FastMail.

Posted in News. Comments Off

Please update your FastMail password

We’ve just sent the following announcement email to all FastMail users.


Dear FastMail User

You may have heard of a recent security bug in the OpenSSL library (that has been called ‘Heartbleed’) used by two-thirds of the Internet including ourselves and other major sites like Amazon, Google, Yahoo, etc. FastMail was quick to update its servers to fix this bug and issue new SSL certificates as soon as we were made aware of it.

We have no reason to believe any of our servers were targeted or exploited by this security flaw, but given the nature of the flaw it’s impossible to know if this bug was being exploited before it was announced.

Because of this, we are recommending that all FastMail users logout of all existing sessions and change their account passwords.

Again, there’s no evidence our servers or your password have been compromised, but we’re recommending this as a precautionary measure.

If you hate remembering passwords, we recommend you use a password manager program to remember them for you. Most modern browsers (e.g. Firefox, Chrome, etc) have a password manager built in and will offer to remember your passwords for you. LastPass and 1Password are also popular choices.

When you choose a new password, it’s important that you do not use the same password elsewhere and choose a password with reasonable complexity.

Your email is often the key to your online world. Many sites let you reset your password by sending a reset code to your email address. When you reuse your FastMail password at other sites, you’re making it much easier for attackers to potentially break in to your email account. Other sites often don’t have the same high security measures as FastMail (such as compulsory HTTPS, locked-down servers, etc.), which makes them much easier for criminals to break in to. If they hold your email address and the same password that you use for FastMail, the attacker can then access your email account and get into everything else you use online.

If you’re using alternative logins already, we recommend you delete and re-add them with any base password changed.

To change your password and log out of all existing sessions, you can use these steps.

Change password in current interface

  1. Log in to your FastMail account using the web interface
  2. From the menu at the top left, select ‘Password & Security’
  3. Enter your existing password where directed
  4. Enter your new password where directed. Re-enter again to make sure we got it right
  5. In the ‘Logged in Sessions’ section, click ‘Log out’ next to each existing session
  6. Click ‘Done’ to dismiss the panel
  7. From the menu at the top left, select ‘Log out’
  8. Now log in to your account again with your new password. This is often useful as a password manager will now prompt you to remember your password at this point.

Change password in ‘classic’ interface

  1. Log in to your FastMail account using the web interface
  2. Select the ‘Account’ item at the top right
  3. Select the ‘Password/Security Settings’ item
  4. Enter your new password where directed. Re-enter again to make sure we got it right
  5. Enter your existing password where directed
  6. Click ‘Update Password’
  7. Click ‘Logged In Sessions’ in the sidebar on the left
  8. Click ‘Delete’ next to each existing session
  9. Click ‘Log out’ at the top right
  10. Now log in to your account again with your new password. This is often useful as a password manager will now prompt you to remember your password at this point.

Again, this is a highly precautionary measure. FastMail is extremely concerned about security and has always tried to be highly pro-active with keeping our customer’s accounts and data as secure as possible.

Regards,

The FastMail Team

Posted in News. Comments Off

All SSL certificates updated

Based on a recent security issue in the OpenSSL library, we’ve updated all our server software and taken the precaution of replacing all of our SSL certificates. Most users shouldn’t notice any difference, but if your email client/xmpp client/ldap client/etc reports a certificate issue, this is probably the reason why.

Posted in News. Comments Off

FastMail housekeeping – removing little used features and simplifying others

In maintaining a large system like FastMail, we often find ourselves coming across code or configurations that’s can be harder to modify and update than we expect because of the way they interact with some particular feature or features. Normally this just means finding a different way of doing it. However in some cases, the feature itself is used by such a small number of people and the original reason it was useful is no longer so important that we’ve decided to retire a few rarely used features or update them to work differently than they have traditionally.

Below we describe the features we’re removing or changing, the rationale, and an alternative if available.

We plan to roll out what changes we can on beta over the next month, and fully roll them out everywhere on April 30.

Update: These changes are taking longer than expected to complete, so only some have been done so far. Details inline below.

Removing WAP

We’ve had a WAP server at http://wap.fastmail.fm for many years. WAP was a vastly reduced markup and display system designed for accessing internet content on early feature phones that didn’t have the power or bandwidth to render full HTML pages.

With the rise of smartphones and full HTML browsers, the use of WAP has dwindled to only a couple of users. Because of that, and because in most cases Opera Mini (which can access the HTML classic UI) will run on the phones people are using WAP on, we’ve decided to completely shutdown WAP.

Update: May 8, the WAP server has now been removed.

Removing Email reflector

The email reflector was an interesting attempt to provide an alternative to email forwarding. Basically the idea arose because some work places didn’t like employees logging into webmail accounts at work. So what you could do was “reflect” your FastMail email to your work address, and when you replied to the email from your work account, it would reflect back via FastMail and all the email addresses and headers would be rewritten to make it look like it came from your FastMail account!

In theory this was a really neat idea, however in practice it never quite worked as reliably as we liked. It was always marked as “in early stages of development” and was prone to “leaking” strange email addresses or creating extremely bizarre results if reflected and non-reflected email addresses somehow ended up being used together (e.g. someone accidentally added a “reflected” address into their work address book and used that with a non-reflector email address). Internally the code and configuration to make it all work is complex and messy.

Additionally these days, many people with work places with restrictive web policies have a personal smartphone they can easily configure to access any email account they want. They seems a much more natural solution to the problem.

On April 30, we’ll remove all reflector rules for any people who still have them still setup. We recommend you manually remove them before then so you’re more in control.

Removing SMS Sending via the web interface or SMTP

It’s currently possible to send SMS messages directly from the FastMail compose screen. You have to buy some SMS credits first, but after that, you just include a number@sms email address in your to/cc/bcc addresses and it’ll convert the first 160 chars into an SMS to that number. This also works via SMTP, you send to number@sms.messagingengine.com. You also have to set an originator phone number for the personality you are using to send from. In theory, this is the phone number the SMS will appear to come from.

When this was first implemented almost 10 years ago, it was a really useful feature. Most people had feature phones that were slow to type SMS’s on. Using this feature, you could quickly type a message in the web interface/email client, and to the recipient it would appear to have come from your phone, so if they replied to it, the reply would go to your phone.

Since then though, the usefulness of this has dropped significantly. Most people have smartphones where it’s now much easier to tap out a quick message. Also, mobile operators became much more strict about setting arbitrary originator numbers and now most block such messages. In it’s current state, most messages sent from FastMail now appear to come from a fixed number, not the originator number people have set the personality to, so if someone replies to the SMS, the reply disappears rather than going to the original sender.

On top of this, this feature has been an ongoing source of fraud issues for us. We still regularly see accounts signed up with stolen credit cards for the sole purpose of sending SMS spam, even with our heavy rate limiting.

Because of these flaws, we’re going to remove the ability to send arbitrary messages to SMS numbers altogether. Note that this will NOT affect SMS forwarding rules or SMS two factor authentication. Both of those are definitely being kept and will continue to work.

Update: May 8, the SMS sending via web interface/SMTP has been removed

Simplifying Pop Link retrieval

One of the features Pop Links have is the ability to set scheduled retrievals (every 1, 2, 3 or 12 hours, daily, or weekly). The minimum you can set is based on your current service level. In addition in the classic interface, you can perform additional manual retrievals from the action menu on demand. The fact the current interface doesn’t have this feature is regularly cited by a number of users as a reason not to switch interfaces.

The original reason for the different retrieval schedule limits was because we feared retrieval might be a resource intensive process with many users. What we’ve found is that almost all Pop Links are set to retrieve on the shortest interval possible for that service level and that they consume relatively negligible resources.

So what we’re going to do is remove the ability to schedule different retrieval periods, and instead just have a simple “manual” or “auto” mode switch. Respectively these will:

  • “manual” mode
    – No automatic checks
    – Classic UI: Can select from the action menu to manually retrieve
    – Current UI: (Update: This bit added based on user feedback, matches what the auto mode also does. If you don’t want this, you can still manually disable a pop link to stop this happening) If you click on a folder to go to that folder or ‘refresh’ the current folder, then any pop links that file into that folder get checked at that moment. Can go to the Advanced -> Pop Links screen to manually retrieve.
  • “auto” mode
    – Automatically checks every 1 hour
    – While logged into and active on either web interface, checks every 5 minutes (active is defined as performing actions which cause your browser to communicate with our server)
    – Classic UI: Can select from the action menu to manually retrieve.
    – Current UI: If you click on a folder to go to that folder or ‘refresh’ the current folder, then any pop links that file into that folder get checked at that moment. Can also go to the Advanced -> Pop Links screen to manually retrieve.

We believe this fits much better with what people actually want. Namely that emails are regularly retrieved from a remote service, that retrieves occur more frequently while you’re actually logged in and using the web interface, and that there’s an explicit way to perform a retrieve if you absolutely want to do one then and there.

Update: June 2, the “click on a folder to activate pop links filing into that folder” has been rolled out, the remaining changes will be rolled out soon.

Update: June 5, the remaining features have been rolled out and the Pop Links screen updated to allow “manual” or “auto” mode selection, as well as allowing an explicit “fetch” of a pop link along with the previous “test” of a pop link

Simplifying Personalities

SMTP FROM Envelope

Personalities have a option “SMTP FROM Envelope”. The fact that option says “Advanced: SMTP MAIL FROM envelope address to use. Leave blank unless told to” gives you some idea that this is a very rarely used option. Basically the point of it was to avoid SPF failures when sending email made to look like it came from an external service.

Realistically the amount of email blocked due to SPF failures is extremely low these days. SPF never really fixed any particular email problems (and added some really nasty ones like breaking forwarding without using a horrible hack) and ended up just becoming another scoring marker of little value in the overall judgement of an email’s spamminess.

The correct solution to this issue is to use the actual external server for that domain to send as that domain. In that case, the From address (in the header) and the SMTP MAIL FROM address (in the SMTP protocol) are the same, and so only the Email address field of personalities is required and is what will also be used for the SMTP MAIL FROM envelope.

Update: June 5, the SMTP FROM Envelope feature has been removed from the Personalities screen and disabled on sending

Signatures

Currently there’s a separate signatures screen for setting your signatures. You then select which signature to associate with with each personality.

Most people don’t work this way and find this extra level of indirection annoying or confusing. So we’re going to remove the signatures screen and just allow setting/editing of signatures on the personalities screen.

The one thing this will affect is the classic compose interface. In the advanced section you can choose which signature you want to use separate to the current personality. This option will be removed. If you want to use separate custom signatures, we recommend putting them in the Notepad and using the “Insert note” feature before sending.

Conclusion

Well that took longer than I expected. In some ways it’s sad to see some of these go (I wrote most of the code behind them!), but realistically the things being removed are little used and the proposed changes are small but neaten up some strange legacy edges and result in a better overall product for the majority of users.

Posted in News. Comments Off

Improved default search behaviour in classic interface

When we introduced the current interface, one of the features we were really happy with was our vastly improved searching. Basically we implemented a full text index that allowed you to search the headers and content of all your email in all folders for any words in a few seconds (in IMAP parlance, this uses the FUZZY SEARCH extension)

At the time, we decided to leave the search on the classic interface as it was (by default, search from/to/cc/subject headers but not the message content and search on substrings rather than whole terms).

However the general consensus from classic users is that they’d really like the improved search that the current interface comes with. So today we’ve rolled out a change that better unifies the search syntax on both the classic and current interfaces.

So now on both interfaces if you do a search:

dinner john

It will do a fast indexed search of the from, to, cc, bcc and subject headers as well as the message body content for messages that contain both “dinner” and “john”. This search is done on words/terms with stemming where possible, not sub-strings. This searches the current folder by default on classic, and across all folders by default on the current interface. On classic, you can check the “All” checkbox to search across all folders.

If you want to revert to the historical sub-string searching of headers, you can use the substr: modifier. Some more examples:

  • example – fuzzy search from/to/cc/bcc/subject headers and message bodies for the word “example”
  • body:example – fuzzy search message bodies for the word “example”
  • to:example – fuzzy search to/cc/bcc headers for the word “example”
  • onlycc:example – fuzzy search cc header for the word “example”
  • substr:example – search from/to/cc/subject headers (but not body content) for the substring “example”
  • substr:(dinner john) – search from/to/cc/subject headers for both substrings “dinner” and “john”
  • substr:(body:example) – search message body content for the substring “example” (warning: likely very slow!)
  • substr:(to:example) -  search to/cc/bcc headers for the substring “example”
  • substr:(onlycc:example) -  search cc header for the substring “example”

A complete list of all the search options can be found on our mailbox searching help page.

Posted in News. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 5,149 other followers