beta.fastmail.fm now redirects to beta.fastmail.com

In preparation for our our move to fastmail.com, we’ll be doing some testing on beta.fastmail.fm. So if you use the beta server, expect some changes and potential issues over the next few days.

Currently that means if you go to beta.fastmail.fm, you’ll immediately be redirected to https://beta.fastmail.com. This is expected. Note that you can’t currently create @fastmail.com aliases or rename your account to @fastmail.com. This is expected. This will only be available from Thursday as described in the original blog post.

SSL 3.0 disabled due to security vulnerability

This morning Google published news of a new vulnerability in SSL 3.0. You can read more about it in the original announcement and in CloudFlare’s analysis of the problem.

This is a serious issue that can leak user data. Unfortunately there’s no workaround – the only option we have is to disable SSL 3.0 on our servers entirely. We don’t like having to do this because we want our users to be able to use any client they choose to access their mail, but when there’s a security hole and no way to plug it we have no choice but to break things for some people in order to protect everyone.

Happily, this should not affect the majority of our users. The only significant browser to be affected is Internet Explorer 6 on Windows XP, which will now not be able to connect to www.fastmail.fm at all. Similar changes have been made to our IMAP, POP and other backend services, so you may also have connection issues with older mail clients.

If you are unable or unwilling to upgrade your client software at this time, you can use insecure.fastmail.fm (web) and insecure.messagingengine.com (IMAP/POP/SMTP), both of which support SSL 3.0. As always, we highly discourage the use of these service names because they leave your data open to attack, and we may remove them in the future.

Update 16 Oct 2014 01:00 UTC: We’ve heard of at least two mail clients (Airmail and Windows Phone) that can receive but not send mail. Changing the outgoing settings to use port 587 instead of 465 has resolved the problem for some users. If you’re seeing similar problems, give that a try.

Payment Issues

Recently there have been some problems with our payment processor.

One of these is that sometimes there is a significant delay in completing a transaction, so the funds are “reserved” but the transaction isn’t actually completed until a few weeks later.

The other problem was that a number of charges were made to some of our customers’ credit cards, in our name. The majority of these are USD 1.00 test charges that are used to verify that a card is valid. Normally we cancel these charges immediately and the charge doesn’t appear on the card statement. However the problem at our payment processor has resulted in some of these supposedly “cancelled” charges recently being applied to customer cards. A number of other charges which were supposed to be “cancelled” have also been processed. This was done in error and without any instructions from FastMail.

We are currently working with our payment processor to refund these erroneous payments. In some cases, the refunds are unable to be processed directly because the card has expired or been cancelled.

We may need to refund these charges via an alternative method, or, at the user’s option, instead credit the amount towards future FastMail renewals. We will be in touch with the affected customers once we have more information on the scope of the problem.

We would like to assure our users that we will make certain that all erroneous charges are corrected. This may take some time, so thanks for your patience.

Our apologies for any inconvenience or confusion. We will post more information as it becomes available.
– the FastMail team

Posted in Technical. Comments Off

New phishing trick, data: URLs to avoid forgery reporting

This is a technical post about a new and interesting phishing technique seen today. Regular FastMail users can skip this post.

We saw an interesting new phishing attempt today that uses a relatively novel technique to try and hide the source of the attack and avoid it being reported as a web forgery.

Firstly the email itself looks reasonably well done (apart from the year in the subject being completely wrong), certainly it’s not the poor quality you often see. It looked like this (ANZ is an Australian bank):

phishing

Secondly, the email was sent using a compromised gmail account with a .edu address. In fact there were two separate emails, both from different compromised gmail .edu accounts. I imagine compromised gmail .edu accounts aren’t that easy to get, and this significantly reduced the chances of it being caught by any spam filter.

Thirdly, the phishing page itself is interesting in that it:

  1. Uses a standard link shortener for a redirect (http://ow.ly in this case)
  2. Which redirects to the phishing delivery page (a compromised page on http://zerra-performance-center.de)
  3. That page however rather than hosting the HTML phishing login page directly, does this:

<script type="text/javascript">
        window.location="data:text/html;base64,... base64 encoded version of HTML phishing login page ...";
</script>

That data: URL is itself the phishing page content, which includes links to real ANZ website logos to make it look as authentic as possible, but has a form submit action to a compromised page on http://lucinaracosta.com.br.

This approach is interesting because it makes it impossible to report this page as a forgery using the standard Firefox "Report Web Forgery" action because Firefox thinks it’s a data: URL. Neat trick that makes it harder to remove or block in the long run.

I’ve reported this issue as a Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1032564

Posted in Technical. Comments Off

Errors on classic mailbox screen and pop emails retrieved again for some users

A rollout of some new code today contained some errors that badly affected two separate areas of FastMail.

1. Errors selecting any emails to action on the classic interface would cause a fatal error

An internal misuse of an API meant that selecting any emails on the classic interface Mailbox screen and trying to action those emails would fail with a fatal error. Reading and applying actions to individual emails continued to work fine. The way this manifested itself unfortunately wasn’t picked up in our testing before being rolled out. It has been fixed now and we’ll update our tests to catch this. The error lasted for for about 3 hours.

2. Pop links for some users re-downloaded all emails again

A long term bug in the pop retrieve system resulted in a very rare and intermittent problem where some links for some users would forget all existing downloaded message. This means that in certain cases users that had set the “Leave on server” option might see existing messages that had been downloaded previously downloaded again, possibly several times. This obviously resulted in duplicate copies of the same message appearing in a folder.

Unfortunately a fix to this bug rolled out to one server for a short time actually made things worse, causing the same problem to occur for more users than the original bug.

A correct fix for the original problem and the subsequent bug has now been rolled out everywhere.

Users affected by this bug can find and remove any duplicate messages using the Advanced -> Folders -> Mass delete/Download/Remove duplicates … (button down the bottom) screen. Select the folder with the duplicates at the top, and use the “Remove duplicate messages” section to find and remove any duplicate messages.

Posted in Technical. Tags: . 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

New IP addresses in Iceland

We have just transitioned our Iceland servers to a new network range (belonging to us rather than to Opera).

This means that the addresses of ns2.messagingengine.com and in2-smtp.messagingengine.com have changed.

Unless you have hard-coded the old addresses somewhere, you shouldn’t see any difference. The new addresses will propogate over the next hour or so.

Posted in Technical. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 5,554 other followers