Moving to a new credit card provider, may generate a small temporary charge

TL;DR: You may see a $1 charge appear on the credit card you have registered at Fastmail. This is temporary as part of a conversion process and will completely disappear within a few days. There is nothing you need to do.

We’re currently in the process of moving our credit card payment gateway to a new provider, Global Collect. Global Collect are a large and well respected provider of international payment services that will allow us to support more cards and payment methods in the future.

As part of the switching process, we’re securely converting all credit card details from being stored on Fastmail systems, to being stored at Global Collect. By doing this, we’ll be able to remove all credit card details from our system, something we’ve wanted to do for a while.

However there is one issue. To enter the credit card details into their system, we can’t just enter them as is, we have to enter them with a transaction so that the card can be checked and authorised.

We’re doing this by creating a dummy $1 authorisation against each card. With credit cards, it’s possible to create an authorisation on a card, but never actually complete the transaction. After a few days the authorisation times out, and the money is never actually taken from the account.

However the $1 authorisation is still something that banks will do their usual fraud checks against, potentially alerting you to the transaction via email or a phone call, and potentially having the transaction appear (temporarily until it time out) on your online statement. Because of different gateways, the payment on your statement may appear to come from either "Fastmail" or "Opera Software".

If you do see something like this occur on your credit card, then there’s no need to worry. This is just a consequence of the transfer, and the $1 charge will completely disappear from your credit card in a few days. In some cases, it’s also possible that there may be two separate attempts to charge $1, because Global Collect will route payment attempts through multiple gateways if one appears to fail. Again, there is no need to worry about this.

We’re sorry for any inconvenience this has caused some people, we didn’t realise up front the full issues this would cause some users, especially the surprising contacts from their bank, we thought it would be basically an invisible process for all users.

At this point there is nothing you need to do. If your bank contacts you about the charge, you should tell them it’s ok and to process it. The $1 charge will completely disappear after a few days.

Once the conversion is complete, all Fastmail payment services should continue as normal. Account renewals should be automatic (unless you’ve explicitly disabled them), and you should be able to add funds/upgrade/downgrade from the appropriate Options screens.

Long term we want to add additional payment options as supported by Global Collect, the first of these is likely to be Paypal sometime in a few months.

Posted in News. Comments Off

HTTP keep-alive connection timeouts

This is a technical post. Regular Fastmail users subscribed to receive email updates from the Fastmail blog can just ignore this post.

The average user of the Fastmail website is probably a bit different to most websites. Webmail tends to be a "productivity application" that people use for an extended period of time. So for the number of web requests we get, we probably have less individual users than other similar sized sites, but the users we do have tend to stay for a while and do lots of actions/page views.

Because of that we like to have a long HTTP keep-alive timeout on our connections. This makes interactive response nicer for users as moving to the next message after spending 30 seconds reading a message is quick because we don’t have to setup a new TCP connection or SSL session, we just send the request and get the response over the existing keep-alive one. Currently we set the keepalive timeout on our frontend nginx servers to 5 minutes.

I did some testing recently, and found that most clients didn’t actually keep the connection open for 5 minutes. Here’s the figures I measured based on Wireshark dumps.

  • Opera 11.11 – 120 seconds
  • Chrome 13 – at least 300 seconds (server closed after 300 second timeout)
  • IE 9 – 60 seconds (changeable in the registry, appears to apply to IE 8/9 as well though the page only mentions IE 5/6/7)
  • Firefox 4 – 115 seconds (changeable in about:config with network.http.keep-alive.timeout preference)

I wondered why most clients used <= 2 minutes, but Chrome was happy with much higher.

Interestingly one of the other things I noticed while doing this test with Wireshark is that after 45 seconds, Chrome would send a TCP keep-alive packet, and would keep doing that every 45 seconds until the 5 minute timeout. No other browser would do this.

After a bunch of searching, I think I found out what’s going on.

It seems there’s some users behind NAT gateways/stateful firewalls that have a 2 minute state timeout. So if you leave an HTTP connection idle for > 2 minutes, the NAT/firewall starts dropping any new packets on the connection and doesn’t even RST the connection, so TCP goes into a long retry mode before finally returning that the connection timed out to the application.

To the user, the visible result is that after doing something with a site, if they wait > 2 minutes, and then click on another link/button, the action will just take ages to eventually timeout. There’s a Chrome bug about this here:

http://code.google.com/p/chromium/issues/detail?id=27400

So the Chrome solution was to enable SO_KEEPALIVE on sockets. On Windows 7 at least, this seems to cause TCP keep-alive pings to be sent after 45 seconds and every subsequent 45 seconds, which avoids the NAT/firewall timeout. On Linux/Mac I presume this is different because they’re kernel tuneables that default to much higher. (Update: I didn’t realise you can set the idle and interval for keep-alive pings at the application level in Linux and Windows)

This allows Chrome to keep truly long lived HTTP keep-alive connections. Other browsers seem to have worked around this problem by just closing connections after <= 2 minutes instead.

I’ve mentioned this to the Opera browser network team, so they can look at doing this in the future as well, to allow longer lived keep-alive connection.

I think it’s going to be a particularly real problem with Server-Sent Event type connections that can be extremely long lived. We’re either going to have to send application level server -> client pings over the channel every 45 seconds to make sure the connection is kept alive, or enable a very low keep-alive time on the server and enable SO_KEEPALIVE on each event source connected socket.

robm@fastmail.fm

Posted in Technical. Comments Off

Download non-english filenames

This is a technical post. Regular Fastmail users subscribed to receive email updates from the Fastmail blog can just ignore this post.

When you want to send a download file to a user based on a web request, it’s well known you can just set the Content-Disposition header to attachment to get the browser to download the content and save it locally on the users machine. Additionally you can add a filename parameter to control the filename displayed to users.

Content-Disposition: attachment; filename="foo.txt"

The problem comes when the filename contains non-english (really non-ASCII characters). RFC2231 defines a way of adding character set encodings to MIME parameters. Unfortunately support for this RFC is scattered, and browsers have implemented various internal hacks/workarounds (eg. % URL encoded octets). The situation is sufficiently complicated that someone came up with a comprehensive set of tests and there’s a good stackoverflow answer.

However looking over the test case examples, I realised that there appeared to be a solution that would work on all browsers except Safari quite well. The attwithfn2231utf8 test shows that all modern browsers except IE and Safari support the RFC2231 encoding. The attfnboth test shows that if you have a traditional filename parameter followed by a RFC2231 filename* parameter, IE and Safari pick the traditional parameter. The attwithfnrawpctenclong test shows that if you use % URL encoded octets in a traditional filename parameter, IE attempts to decode them as UTF-8 octets.

Putting that together, if you want to send a file called foo-ä.html, then setting a header of:

Content-Disposition: attachment; filename="foo-%c3%a4.html"; filename*=UTF-8''foo-%c3%a4.html

Will cause IE8+, Opera, Chrome, FF4+ (but not Safari) to correctly save a file named foo-ä.html. This should be easy to do with a URL escaping library that encodes UTF-8 octets not in the unreserved character set.

robm@fastmail.fm

Posted in Technical. Comments Off

World IPv6 day

This is a technical blog post about Fastmail’s support of an internet standard called ipv6. Most users shouldn’t notice any difference at all, and can ignore this post. For those interested, we’ve included some description about what we’ve done to support ipv6.

We didn’t actually get organised enough to register ourselves for world ipv6 day, but we got ipv6 up and running in time, so we’ve enabled it anyway.  You can read more about ipv6 day here: http://www.worldipv6day.org/

Our prefix for NYI is 2610:1c0:0:1:: – and for convenience we’re mapping all the IP addresses from our ipv4 space (66.111.4.0/24) as direct offsets into that ipv6 space.  All the public service IPs are now bound in ipv4 and ipv6.  There was some magic requried to support our failover system because Linux doesn’t offer an option to bind non-local ipv6 addresses – so we do a little dance where the address is bound to the loopback interface on one machine as a /128 (host only) address – or to the external interface as a /64 (fully networked) address depending on where the service is located.  It seems to work OK, which is the main thing!

Due to rbl issues and the lack of working reverse DNS, we have not enabled ipv6 for inbound or outbound SMTP, and our DNS server doesn’t support ipv6 connectivity, so all your DNS queries will still be over ipv4.

The domains with ipv6 support (AAAA records) are:

  • mail.messagingengine.com
  • web.messagingengine.com
  • dav.messagingengine.com
  • http://www.fastmail.fm
  • mail.opera.com

This will pick up the majority of web, imap, pop and smtp authenticated traffic. If you have ipv6 connectivity, you should be transparently using ipv6 now.  We are getting random bits of ipv6 traffic in the logs, so it’s clearly working.

Our FTP server doesn’t support ipv6 EPRT and EPSV commands, so I haven’t added a record for ftp.messagingengine.com.

You can also try ipv6.messagingengine.com if you want to guarantee you’re using ipv6 only. That host doesn’t have an A record for ipv4.

Unless there are reports of significant problems with this experiment, we will remain dual stack into the future :)

Posted in Technical. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 5,590 other followers