FastMail.FM Weblog

As we’ve noted over the last two months, we’ve been planning to enforce SSL/TLS security on all IMAP/POP/SMTP connections. All users that needed to change their settings have been notified multiple times. Additionally, over the last few weeks, we’ve also notified all LDAP users that need to change their settings to enable SSL/TLS as well.

We’ve now done this and have completely disabled all non-SSL IMAP/POP/SMTP/LDAP ports. This means you can no longer access any services on the ports 110, 143, 25 or 389.

Over the next few months we’ll also be looking at enforcing SSL/TLS encryption our remaining services such as XMPP and DAV. We’ll post more as we work out our approach to enforcing SSL/TLS for these services.

As noted previously, we’ve been planning on enforcing SSL/TLS encryption of all communication between a user’s email software and our servers, ensuring that no one can eaves drop on your username or password to steal your login credentials.

Over the past month and a half we’ve been sending notification emails to all users using insecure connections with details of how to fix their email software configuration. During that time the vast majority of users have already reconfigured their email software to correctly use secure and encrypted connections.

At some point we have to completely disable the insecure connection ports and we’ve decided to do that on July 14. From July 14 onwards, only the official configurations described on our Server Names and Ports help page will be active and supported, all other ports and hostnames will be disabled.

The vast majority of users are already using the correct configuration and won’t be affected. Only the small number of users still using insecure configurations (despite the regular notifications we’ve been sending them for the last month and a half) will have problems. We’re now contacting those users to let them know they have only 5 days left to change their configuration.

We’ve just rolled out a few changes to the address book available in the web interface. These changes are based on some analysis we did of how people are using the address book.

• Remove the "Description" field on address locations

  We found that very few people used this field (the vast majority were blank), and for those that did put something in here, it was usually duplicate information (either just the string "Home", "Work" or "Other", and just duplicating the selected address type) or confused information (duplicating the first line of the address itself). So we’ve removed this, and in the few cases it appeared to be used, we’ve moved the information into the first line of the address itself.

• Remove all custom fields

  Few people were using custom fields, and in the majority of cases people were actually putting data in here that should have been in another location. Most custom fields were some form of phone number and those should clearly be in the phone contacts section. The likely reason for this happening is because the previous interface didn’t make it obvious where to put phone numbers, which we’ve now also made clearer (see below). The other use of custom fields was for new services like Skype and Twitter. We’ve added new contact types for those services.

  Any existing custom fields have been moved to the appropriate phone/email/online contact type, or where we couldn’t identify an appropriate type, we’ve moved the data into the Notes section.

• Add new contact types for Skype and Twitter

  Apart from the phone types, these were clearly the most used custom field types, so we’ve added these as explicit online contact types.

• Split the old Contacts section into 3 separate sections: Email, Phone and Online contacts

  Because we’ve always allowed an arbitrary number of "contacts", there was a single Contacts section where you could select the contact type you wanted to add: Email, Phone, Web, Instant Messenger, etc. However because the selection  of which type to add was via a pop up menu which defaulted to "Email", it wasn’t actually obvious that you used the same section to add phone numbers, web addresses, etc.

  So we’ve now split this into three separate sections for "Email", "Phone" and "Online" contact types.

Based on our analysis, we believe these changes make the address book easier to use and also better matches the actual data people are wanting to see and store, while removing unneeded and rarely used complex or difficult to understand features.

We’ve just added fastmail.nl (.nl is the TLD for the Netherlands) to the list of our available domains. That means you can can now signup an account or create an alias on the Options –> Aliases screen (subject to your account service level) in this domain.

Along with our primary domain fastmail.fm, this adds to our existing list of available “fastmail” TLDs.

fastmail.cn
fastmail.co.uk
fastmail.com.au
fastmail.es
fastmail.in
fastmail.jp
fastmail.net
fastmail.to
fastmail.us

Users regularly tell us how important the security and privacy of their email account is. Sometimes because of how their email software was initially configured, users don’t realise that their username and password are being sent over the Internet unencrypted, which is often a genuine surprise and concern.

Because of this, we have decided to enforce that all communication between a user’s email software and our servers is encrypted, ensuring that no one can eaves drop on your username or password to steal your login credentials.

If we detect that you are currently using an insecure (non-SSL/TLS) connection to send or receive email, we will send you a notification directing you to this page which explains how to fix your email software. You will keep receiving this message until you have successfully fixed your configuration.

We will be rolling out these changes over the next few weeks and will give people until the end of June to change their software. We believe these changes are in the best interests of all users and are modern best practice on the Internet these days.

There’s often quite a bit of confusion about the different terms SSL vs TLS vs STARTTLS. To help explain the differences and a bit of the history behind these terms (especially with regard to email protocols), I’ve put together a help page that I hope is useful for people.

http://www.fastmail.fm/help/technology_ssl_vs_tls_starttls.html

Some years ago, when connectivity within the pacific region was less reliable, we added a small proxy server in Singapore which forwarded sessions down a VPN connection to our datacentre in New York.

The world has moved on, and this service is barely used. Reading the logs it’s almost all search engines scanning our help pages, which is just going to direct people to the slow proxy copies rather than the originals.

So as of today, the sg.* hostnames point directly to our main New York addresses, and the Singapore proxy will be shut down.

One of the original design problems with email is that none of the email addresses in an email are certified or guaranteed in any way (when it was designed, the Internet wasn’t full of spammers and other hostile parties like it is now).

This flaw allows spammers to put any email addresses they want in any part of an email message. There are systems that attempt to limit this problem (like SPF), but these only help mitigate the issue.

One significant problem this ability to forge email addresses causes is something called "backscatter". Backscatter occurs when a spam email with a forged from address is sent to a system and that system then generates another message in response and sends it back to the forged from address. The most commonly auto-generated response messages by systems are non-delivery notifications (bounce messages) or auto-replies (vacation responses).

In that case the response message goes to some random address the spammer made up, which might be a mailbox at any system, including a spamtrap address that can affect the reputation of our sending IP addresses.

While FastMail has systems in place to try and detect these backscatter messages from other systems and file them into Junk Mail, it’s still possible for FastMail to be a source of these backscatter messages as well, which as noted above can affect the reputation of our sending IP addresses.

To reduce the chance of FastMail being a source of backscatter, we’ve now made two changes.

1. Until now, the rules to reject/discard messages on the Options –> Define Rules screen were labelled under "Reject emails". There was a separate "Silent" checkbox which controlled whether the email was silently discarded or whether a reject/bounce message was sent back to the sender of the message.

   When FastMail first started 10 years ago, the default was to always reject emails, that is, generate a bounce message. Several years ago, we changed it so the Silent checkbox was checked by default, meaning that silently discarding emails was the default behaviour.

   We’ve now completely removed the Silent checkbox and renamed the section "Discarding emails" as silent discard is now the only option. This will completely eliminate bounces generated by user filtering rules.

2. Until now, you could setup a vacation auto-response on the Options –> Define Rules screen under the Forward tab at any time.

   We’ve now changed this so that if you want to enable a vacation response message, you must enable at least Normal level spam protection on your account. This will ensure that in the vast majority of cases, we never send a vacation reply to any spam messages.

For users with existing reject rules, those rules have now all been changed to silent discard rules.

For users with existing vacation reply settings enabled, the vacation reply has been disabled if the user does not have Normal level or higher spam protection enabled. Unfortunately this means for Guest & Member accounts, you cannot re-enable vacation replies until you upgrade your account to at least Ad Free as Guest & Member accounts do not support anything but Basic level spam protection.

We’re sorry for any inconvenience these changes cause, but they are required to protect the reputation of our outgoing IP addresses, which is required to allow all users to send email with high reliability.

We’ve just made a change today so that if you go to the Options –> Account Preferences screen and change your password, or disable IMAP or POP logins, then we will immediately close any existing open IMAP or POP connections.

This security enhancement is particularly useful if you have a mobile device that is lost or stolen. By changing your password via the web interface on another device/computer, you will immediately force any existing IMAP/POP connections to be logged out and prevent any further logins from that device because the password will no longer be correct.

We also plan in the future to allow expiring web sessions from other machines as well. We’ll announce on this blog when that feature is ready.