Hacker News new | past | comments | ask | show | jobs | submit login
Fastmail accounts blocked in Russia, here's what we know (fastmail.blog)
297 points by andrewshadura 3 months ago | hide | past | favorite | 176 comments



I highly recommend scheduling a regular mbsync job to keep a local copy of your emails in sync with the imap server.

With this it's easy to pick up and move to a different provider or recover from outages, account closure, etc.

If you couple this with your own domain your email will be very portable.


I pay for a second inexpensive mailbox at Mailfence and sync the contents of the Fastmail account to a subfolder of the Mailfence account. There is rate-limiting involved, so my config is dialed down on "pipelinedepth" to ensure I don't hit that problem (you can easily overrun the Mailfence side pushing too much too fast). The cron runs via a unique user account on a cloud server every 4 hours using unique passwords (see below).

cron runner's ~/.mbsyncrc

    # Source
    IMAPAccount imap-src-account
    Host imap.fastmail.com
    Port 993
    User <user@domain.com>
    PassCmd "cat <redacted>/.secure/psrc"
    SSLType IMAPS
    SystemCertificates yes
    PipeLineDepth 1
    
    # Dest
    IMAPAccount imap-dest-account
    Host imap.mailfence.com
    Port 993
    User <username>
    PassCmd "cat <redacted>/.secure/pdst"
    SSLType IMAPS
    SystemCertificates yes
    PipeLineDepth 1
    
    # Source map
    IMAPStore imap-src
    Account imap-src-account
    
    # Dest map
    IMAPStore imap-dest
    Account imap-dest-account
    
    # Transfer options
    Channel mailsync
    Master :imap-src:
    Slave :imap-dest:SubFolder/
    Sync Pull
    Create Slave
    Remove Slave
    Patterns *
    CopyArrivalDate yes
Note: use the Fastmail option to set up a READ ONLY IMAP user password! (it's a really cool feature of Fastmail that many others do not support) Mailfence also has per-service passwords, set one up for IMAP as well. Do not use your main login passwords if you can avoid it - $0.02.


Nice idea to copy between imap accounts, I might set that up in addition to my local backups.

How do you like mailfence overall?


It seems just fine? As it's my secondary account it's mostly SMTP idle so I can't give an honest opinion about delivery (like emails from your bank) but it seems to be doing very well as a service. Like Fastmail, they have a detailed domain setup wizard to ensure all your DNS for SPF/DKIM/dmarc etc. is all properly configured for best results. I have no complaints for what I use it for, really. I do wish that I had finer grained app password control like Fastmail but it's not a deal killer.

I went with Fastmail as my primary due to the enhanced feature set and crazily enough - the Notes and Files feature in their mobile app. I can take a picture, toss it into that folder and get it on my desktop quicker than finding a USB cable or running a foldersync - the Notes are similar, I replaced Google Keep by just using the Fastmail Notes functionality.


I also use fastmail and I copied your config, with the only difference I'm saving in a local folder.

I'm getting this error for each email: IMAP error: unable to parse INTERNALDATE format

Do you also get that? Is this a problem?

I use this Docker image: https://github.com/JakeWharton/docker-mbsync


I am using Debian isync-1.3.0-2 and it's working - that Dockerfile shows it's using 1.3.3 and I spot a possible fix in 1.3.4 which could be related (or not, who knows). Your running mysync version might be different depending on the last time you rebuilt that running docker instance, the Dockerfile doesn't seem to pin it to a specific release version.

The Dockerfile is using Alpine Linux and the repos that it points to have already updated to isync-1.4.2 two days ago[2] - in general, I will make a guess your version of mbsync/isync has a bug? You're sort of using some random version, basically.

[1] https://sourceforge.net/p/isync/isync/ci/c8b73acad2a3c698d82...

[2] https://nl.alpinelinux.org/alpine/edge/community/x86_64/


For anyone reading mbsync(1) and getting confused now: they have renamed Master-Slave into Far-Near in the latest versions.


Which one is which?

Is Master = Far and Slave = Near? I'd lean towards the opposite but I can't tell for certain.


It looks like they did this in 1.4.0 released in February 2021, the online man page on the project website has not been updated for this new code. If you read the man page source [1], the word replacement seems to be that Far==Master and Near==Slave - the surrounding text is identical.

[1] https://sourceforge.net/p/isync/isync/ci/master/tree/src/mbs...


Are there any pros/cons to using mbsync over imapsync out of curiosity? Only ask as I've seen imapsync recommended in many places.

https://imapsync.lamiral.info/


I use a traditional local email client: macOS's Mail.app. It stores a copy of every email.

What's the point of using mbsync?


Well, if the mailbox is deleted on the server it could sync and delete everything on your mac


How do you sync back your local copy of the IMAP database? I had the problem of a misconfiguration in my email rules deleting everything older than 28 days. Not a _big_ problem due to backups, but I didn’t manage to restore those as any local restore got deleted as soon as the sync with the IMAP server started


mbsync supports syncing in both directions. In my case I have an hourly cron that syncs imap -> local.

And then if something goes wrong I make a copy of my backup, and invert the configuration to sync local -> imap.


Maybe it helps to copy the messages into a new IMAP folder before resyncing.


I have these problemes too. In my case there is no unique identifer if you abort a restore and move the files again in the "folder", which leads to duplicated emails.


In another discussion somewhere on the internet, someone mentioned using a service but I could not find any details and the person didn't reply.

The service is to send & receive email. But the storage capacity was less and the service only has a imap & smtp address and no webmail. Basically the service focuses on ensuring the emails are sent & received. The person has a webserver hosted at home that copies the emails from that server and incase of sending email, sends via that server. Then all the content of the home server is backed up at some off-site backup service.

Any idea which is the services being used and how would such a system be rated? It sounds like you are doing something similiar.


Unfortunately, you would have to trust the relay not to snoop. You might as well self host a mail server, since you can guarantee end to end encryption.


But if your primary email provider reports an empty mailbox for the synced mailbox, the backup mailbox will be cleared too?

I mean the idea is great but wouldnt you need a backup mailbox provider allowing you to restore daily snapshots?


I use offlineimap* which allows you to optionally sync in one direction.

I'm not sure what happens if the remote emails are overwritten though.

* https://github.com/samhh/dotfiles/blob/master/home/.config/o...


I wonder if the fastmail protocol could be hidden in AWS-like data streams to take an approach like telegram. If they try to block it, they shut down their entire digital business infrastructure.

I have been looking for an alternative to Gmail, does anyone have recommendations? Fastmail? Proton mail?

What put me over the edge is my young friend had a heart attack, went to the hospital and (during recovery) logged into his Gmail account using a laptop there; this triggered some security thing that permanently locked him out of his account.


I’ve had a paid account with Fastmail for probably going on 8 years I’d say. It’s been a fantastically reliable service and the odd (perhaps 3 or 4 times) I’ve needed to reach out to support it’s always prompt and a real conversation.


I'm also a happy Fastmail customer. They actually offer customer support (at least they did a couple of years ago when I needed it).

I had an issue with Fastmail where I accidentally deleted a bunch of emails, and with help from their support I was able to restore them from their backup quickly.

Contrast that to Gmail, where thousands of messages suddenly disappeared from the inbox, and the only support option was a forum with dozens of other users asking for solutions to the same problem.


I've had the same good experience as you. As another datapoint, they really do live up to their name. Everytime I test sending myself emails, I almost always get the email to my fastmail address 30-90 seconds faster then Gmail. Also gmail tends to disapear messages if they're not from a super uber reputable email provider, which sucks sometimes. Fastmail will always deliver my emails if I am playing with a local postfix server or something like that.


i have a gmail account that duplicates/forwards to my fastmail and somehow fastmail shows the forwarded email waaaaaay before gmail even tells me i got the original. i giggle every time.


I sell an app, and people often tell me they can't find their license code anymore. More often than not, these are from Gmail addresses. This may be just because Gmail is popular.

But it's still baffling how Gmails original proposition was that you would always have an archive of all your mail and could search it instantly, yet all these people can't find the email with a license code for an app.


> from _their_ backup quickly.

Wow, that is something


Deleted emails are kept for one week so that accidentally-deleted items can be restored:

https://www.fastmail.com/help/receive/restoredeleted.html


Gmail is required by law to really delete things the user deletes. There are guarantees around how quickly it will be done.


> Gmail is required by law to really delete things the user deletes.

This is not universally the case and the opposite is actually stated in their privacy policy and data retention agreements as it relates to financial transaction information (which likely needs to be retained for tax purposes).

While Google likely pays it safe and complies mostly with CCPA/GDPR 'rights to be forgotten' for the rest of the US, and a good chunk of the world there's no legal requirement outside of the contractual agreements provided in paid Workspaces on when they need to purge this data.

Current privacy policy: https://www.gstatic.com/policies/privacy/pdf/20210204/3jla0x... Data retention policy: https://policies.google.com/technologies/retention


Nice to hear about the support. I haven't had to use it.

I'm a 2 or 3 year customer, bringing my own domain. Love being able to send and receive from *@mydomain.com for the entry level price ($50/year, I believe). App works great on both Android and iOS and doesn't drain my battery.


I'll put in a recommendation for MXroute (mxroute.com). They're geared towards slightly more technical users, ime, but there's practically no limits (apart from rate of outgoing mail). Unlimited domains, unlimited aliases, unlimited accounts, even. The entire service uses DirectAdmin as a management UI so it's pretty easy to use. They've even got plans geared towards resellers. The owner/sysad is an ex-Digital Ocean guy who's obsessed with mail delivery, so you're not likely to face any issues delivering to practically anyone.

I shifted over from Fastmail (who are amazing, don't get me wrong) because I got a good Black Friday deal.


I did not know mxroute.com and went to their web site to get some information.

I must say that I would not have lasted there a long tim eif it was not for the HN recommendation. I did not find any place where they actually explain what is the "unlimited part" (= can I really, for 45 USD, register my three domains, and a number of email accounts on each of the domains?).

I wanted to ask the question on their chat - cannot login, a customer account is required.

I wanted to ask a question on the community forum, cannot login,probably limited to users as well.

I will end up sending an email to the contact address but this was not a great experience.

To be clear - I have no idea about the service itself, it sees to be very good from the technical descriptions (at least they understand email delivery).


Apologies for the bad first impression. This is somewhat intentional. MXroute was originally created for sysadmins who don't need bells and whistles, and just need their email to get to its destination without fussing with IP reputation and things like that.

You know the old saying "If you want God to laugh, tell him your plans." Well, we became very popular with end users that weren't sysadmins at all. Still convinced that we could offer high deliverability at low cost while slowly improving UX to fit a new type of customer, we entered a bit of a dark age where support tickets were going unanswered for months. Because our pricing was meant to be extremely competitive and completely ditch the whole "per user" pricing that plagues the market space, and we were becoming more popular with end users, we were overrun with basic support questions and pre-sales inquires.

The first thing we did was cut out pre-sales inquiries. With enough sales occurring organically without advertising, and with pre-sales inquires having a high correlation with cancellation requests (because our UX wasn't designed for the end user who happened to be the most likely to have a huge list of questions before purchase), we decided that we weren't going to let our overhead (and as a result, our prices for existing customers) suffer at the hands of something that wasn't generating revenue.

The second thing we did was to cut back on direct support and focus on publicly available information for troubleshooting. Ideally, we'd funnel customers or prospective customers into our community forum and community chat, where they could ask questions and help each other with answers, and build up a list of questions/answers that were given in the language of the customers, to help reduce repetitive support requests. Because we found that 15 customers might ask the same question in 15 different ways, by having a community resource where the questions and answers fit those different scenarios, we could do more there than we could by automating responses to keywords.

Leveraging these community resources assisted us in building customer facing documentation and automation rules for our direct line of support, which in turn allowed us to begin leaning back into more directly available support with automation and documentation to fall back on.

Now, we're back offering more direct support after having weathered the storm caused by the unintended shift in our customer base. This is of course assisted by our documentation, and articles are regularly added to address common questions. We're routinely adding automation to auto reply to repetitive questions, and taking those repetitive questions to form better onboarding processes that intend to prevent them.

Time and time again I saw that companies were getting lost in the overhead required for providing support. You'd see in my employment history that I've been on the front lines of that with support at HostGator and DigitalOcean. I always had a vision of how to scale support in a way that would not require the seemingly inevitable steps of outsourcing, followed by selling the company. But only on MXroute did I have the direct opportunity to implement my vision. It hasn't been a flawless process, but I do think that the present result is some of my best work. Of course, as with anything, opinions may vary.


Thank you for your reply.

I completely understand the support part - I have been in IT for 25+ years so this word hits close home.

I would also be interested in a service for technically apt users, but what I was trying to say is that having some basic information upfront, understandable by someone who know how to configure mail, would have been enough.

Something like "you pay XX€, you set the MX on your DNS to point to us (maximum XX domains), for each domain your have YY standalone accounts, and each can have ZZ aliases. You can have aliases cross-domains (or not)".

The kind of basic information that would immediately show what your service is, especially when there were so many people recommending it.

I am also all for the community approach, it is just that there is no (obvious at least) way to create an account (I was even ready to use LinkedIn for that but it was rejected).

To be completely honest, I did not go though all the docs before my first comment. I did it now and still could not find the information above :) (but maybe I did not look at the right page)


Appreciate those notes! Will be redoing a lot of the documentation very soon, and will keep this in mind.


That lifetime plan is tempting


Go to the lowendtalk.com forums and you'd probably find threads with even cheaper plans. They come with certain limitations, but are good for some people.


+1 for Fastmail. I've been happy for several years.

I wrote about my experience switching off of Gmail with some tips here if it's helpful: https://www.justus.ws/tech/how-to-ditch-gmail/


Nice blog post. I made a similar switch, but in the back of my mind I worry that I’ve introduced a new risk factor, since it’s much more likely for my custom domain to get hijacked than gmail.com.

See for example this story of someone’s Twitter account getting stolen via a social engineering attack on their registrar: https://arstechnica.com/information-technology/2014/01/picki...

A Google search suggests that setting up a registry lock could be an additional layer of defense against these types of attacks.

Have you done anything to guard against this type of attack?


Thanks! And no, I have to say I hadn't really considered that angle. In the example that you linked, they didn't steal the domain, they just changed the MX records, so transfer lock wouldn't help.

That being said, my account with my registrar is 2FA-enabled and I do have transfer lock turned on. I hope that someone wouldn't be able to social engineer their way into my Hover account, but who knows.

Maybe I just mention this in a footnote.


I'm a very happy customer of protonmail. They're consistently extending their offering (VPN, Calendar, Drive is up next), their pricing seems fair, albeit not exactly cheap, but to be honest though, I almost consider this to be a feature - I'm perfectly okay with paying good cash for something as important as mail.

Their UI was somewhat lackluster but they recently released a completely overhauled version (just a few days ago), which seems kinda nice so far.

All in all, I can only recommend it. That being said, I'm mostly only receiving mail and rarely ever sending out any, so YMMV.


As a former ProtonMail customer (for several months) and current Fastmail one (~ 4 years): If you have more than 2 domain names, you'll pay 30 EUR/month for your ProtonMail account. I think that's ridiculous. The 5 alias limit for the "Plus" tier is also too limited in my opinion.


I don't know how well all the features match up but you can use as many domains as you want on Migadu for $19/year.


> Their UI was somewhat lackluster

I remember looking at ProntonMail 3 years ago, before I settled on Fastmail instead. To be clear, I have no intention of leaving Fastmail; they have the perfect feature set for me, and have been forthright and competent when it comes to publishing details regarding the problems that have cropped up with their service. I have nothing but respect for the Fastmail team. Russia is in the top 3 countries for which the blocking of Fastmail doesn't concern me; no service is immune to this kind of government interference.

That said… just to refresh my memory, and in case anything ever does happen to Fastmail in my country… isn't ProtonMail the one that had the WORST UI I've ever seen, where every click within the settings was a new maze embedded within another maze? I remember the UI for one of these popular and "secure" email hosts being so ultimately gross, as if it was designed and coded by a 10 year old who just discovered HTML with no knowledge of CSS, where it was just pages after pages of checkboxes and radio buttons with no documentation? Was that ProtonMail, or one of the other very few and far between options?

I remember only having looked at a couple of the modern options to cut my ties with Google, and Fastmail was so far above and beyond the other "viable options", such that it wasn't even really a choice. One of the options clearly looked like a lot of low-level work had gone into security, but that it was effectively unusable from the perspective of the users–including admins–who had to contend with its interface?


I have and like ProtonMail - but until it supports calendar in its iOS app it’s an incomplete solution / non-starter.


According to the blog post, ProtonMail and others are in this boat, too.


Fastmail offers a VPN? I can't find anything about that.


ProtonMail does


My bad


Devil's advocate, wouldn't keeping the two using seperate providers be better? Not 'crossing the streams' so to speak


I've been a paying customer for a few years (since Dreamhost shutdown catch-all support) and when I 1st migrated I tripped over a bug in their IMAP implementation that made thousands of messages disappear from my mailbox. Their support identified the bug and pushed a code fix into production in less than 24 hours, which immediately resolved my issue.

Gmail on the other hand keeps kicking my devices out of being able to log in and activating a security lock down, and the closest thing to support I can get about it is a webpage that implies that can only happen if my devices are hacked.


Long-time (edit: 15+ years) customer of Fastmail, have only praise for them.

For me it's a service that just gets out of the way and I get on with life, not worrying about who's mining emails etc.


Fastmail has been nothing but awesome. Currently using PO Box, which is a a sub-company or something. I get all the Fastmail features and it's been awesome. So happy to fork over my money for such a reliable service.


> I wonder if the fastmail protocol could be hidden in AWS-like data streams

this reads funnily non-techy

i mean web-mail exists or are you reffering to some imap/smtp-in-http?

should be good as long as it is ssl-encrypted and runs over tcp-port 443, no?


Fastmail created the JMAP Standard, published by IETF. Take a look here: https://jmap.io/


Web mail can replace IMAP/POP, but you're still going to need an SMTP server to receive email. Or is there some sort of widely supported SMTP over HTTP protocol that I'm unaware of?


Webmail replaces both IMAP/POP and SMTP for the connection between the user and the mail service they are using. The connection between you and a webmail provider is just a simple HTTP/S web application. It’s the connection between your mail service and the recipient’s mail server that will use traditional mail protocols.


I am aware of that, but you're missing my point. Webmail needs SMTP (while it doesn't necessarily need IMAP/POP). So there is bound to be an SMTP server somewhere that cannot be hidden in HTTP traffic, which is what I think hansel_der was implying.


Well fastmail's servers are not in Russia, so they can just keep using SMTP without issue, it would only be the client in Russia who would need to tunnel his traffic to fastmail.


You're forgetting the SMTP server on the other end. If Fastmail SMTP servers can no longer relay messages from/to Russian SMTP servers, then Fastmail is no longer a viable email service for Russians communicating with each other, unless all of them were using foreign based email services.


I am not forgetting anything. It is indeed true that fastmail is broken for Russians in Russia. And trying to tunnel out to fastmail just to mail back in to Russia makes little sense.

Also broke are all Russian email users who have to send to or receive from the free worlds fastmail accounts. Would seem this is just Russia damaging Russians.


I've been a very enthusiastic fastmail customer for N years. (I don't remember timelines very well, but N is large.)


I've been using Protonmail for some time and started paying for it about one year ago. I mainly switched to the paid plan to get access to their Protonmail Bridge for use with a local email client and that has worked well so far.


I started using fastmail about 6 months ago and have really enjoyed it so far. My only concern is whether they’ll be around long term (10-20+ years) because it’s quickly become my default email for important stuff.


I started using fastmail about a year ago. They've been around since the late 1990s so I feel good about their longevity.


I wasn’t aware of that. That’s very reassuring.


I've had my Fastmail account for over 20 years. It's an employee-owned company with first class ethics and a first class service. An absolute beacon of integrity. It's too bad these qualities aren't more in demand. Make sure you use a Yubikey. An honourable service provider isn't enough.


Others commented about your own domain. It's straightforward to set up, costs maybe $7 a year. You may want to look into it.

Additional bonus: use all kinds of addresses you want (me@shadyservice.domain.com) for easy blocking if an address leaks.


You can always get your own domain and only give out email addresses from that. But my prediction is that Fastmail will outlast GMail.


A bold prediction to be sure.

I hope you're right!


There's German mail provider Mailbox. https://mailbox.org/en/ They tick a lot of good boxes for me.


> I wonder if the fastmail protocol could be hidden in AWS-like data streams to take an approach like telegram. If they try to block it, they shut down their entire digital business infrastructure.

As long as server name sent in cleartext in SNI, blocking any website is trivial. Telegram uses a different approach with multitude of proxy servers and dynamic proxy changes via Apple/Google push messages. It's not applicable to an ordinary website.

If/when encrypted SNI is widely implemented, it might work.


> If/when encrypted SNI is widely implemented, it might work.

No. China is already blocking all connections with encrypted SNI. If such services become popular or make the encrypted SNI mandatory, then the choice will be to either install a government MITM certificate or not use the internet at all.


My point is that right now Russia does not have to choose between blocking entire CDN or allowing all websites. Unencrypted SNI allows to selectively block some websites while keeping CDN for other websites untouched.

Russia's situation is far from China, AFAIK.


Try Infomaniak (https://www.infomaniak.com/en/hosting/web-and-mail/mail-host...). I've been using them for years. Solid platform, not 5-eyes, good webmail experience, cheaper than fastmail.


Just be aware that they require a phone number to sign up (can’t remember if it’s Swiss numbers only) and if their security systems trigger, they ask you to upload your government-issued ID.


FastMail customer. +1, nothing but good things to say. They even championed the new JMAP standard.


For your concern, Zoho is a great option. Very reliable support. I got locked out once and they were able to help me get back my account really fast.


I moved from fastmail to Runbox many years ago. The Runbox service is very reliable and all the servers are outside of the US.


migadu is a really option


Second this

Assuming "really [good] option"


Very happy customer of kolabnow

Checked out both protonmail & fastmail among others, ended up selecting kolabnow, no regrets.


Fastmail seems to be the best provider currently. Have only been using them for a bit but had no issues.


Around fifteen years for me, fastmail is great.


I've been using fastmail for years and I love it.


I’m also a Fastmail user (for the past 5 years or so), but I’m considering switching to iCloud, given the announcement it’ll start supporting custom domains. Fastmail is pricey ($50/month for the non-lite tier), whereas iCloud is $1/month for 50 GB.


Fastmail has three current tiers: Basic, Standard and Professional. Basic is $3/user/month, Standard is $5/user/month and Professional is $9/user/month. None of them are remotely close to $50/month for ordinary single users. You would need 10 users to get to $50/month for the Standard "non-lite tier" plan.

Perhaps the user has confused fastmail with another service or they might have some legacy plan which is more expensive than it needs to be. (I think I have a legacy plan...)


Isn't most legacy plan less expensive? I have legacy plan that's basically the current Standard plan but at $45/yr.


Could you link to the iCloud announcement that says it'll start supporting custom domains? I saw that it will support disposable addresses, but didn't notice anything about custom domains.


https://www.macrumors.com/2021/06/08/icloud-mail-custom-doma... - it wasn’t discussed in the keynote but it showed up on the iOS 15 new features page


I don't think Fastmail has any plans that are $50/month


More like $5/month. Or $50/year


The article touches on new signups being blocked, what happens to the current paying users in the region? Are they also blocked? How is fastmail helping them move/supporting them in this situation?

I am a fastmail customer in a different region (Poland). I am however looking closely at this as who knows, maybe I will be on the receiving end in the future?


Sounds like that could just get them in more trouble?

Such customers are probably on their own - but the article does spell out what they've done, so hints at the solution: VPN to outside Russia in order to sort out moving. (Or stay with Fastmail and accept that you need the VPN to use email, I suppose.) The CEO does often comment on Fastmail submissions here (brongondwana) but I suppose maybe not in this (lawyers involved) case.


Also Australian night time involved. Contrary to rumours, I'm not a vampire and do need to sleep sometimes.


Well, I would expect them to address this issue specifically as that is one of the selling points of fastmail. You can get banned on Google for nothing and not being able to reach a person with your data held hostage. Now, this is a comparable situation where data is held hostage unless the customers in Russia have a way to access and retrieve whatever is stored on their accounts.

On top of that there is a question of billing and refunds in the case of long-term plans being paid up front (eg. one year subscription).


From the article:

> As of the time of publication, there are no changes to other accounts, and email flow in and out of Russia has not been blocked, but we will continue to monitor the situation.


Where did all the brouhaha with Russia banning Telegram end?

From what I understand it seems to be operational and rather popular there. Did the state give up or did Telegram end up “cooperating” with them?


Blocking Telegram turned out to be technically unfeasible since they fought it by routing data through western cloud providers, which the Russian state was unable to block sensibly(you may remember stories from back then).

In the end they "stopped trying" and actually embraced using Telegram as a propaganda tool nowadays.



Telegram started to collaborate with Russia and they let it live.


Where did you obtain confidence for this story?


https://www.reuters.com/article/us-russia-telegram-ban-idUSK...

Roskomnadzor said it had acted because the app’s Russian founder, Pavel Durov, was prepared to cooperate in combating terrorism and extremism on the platform.


Not an exact confirmation but there was a story about the VP of Telegram meeting with the Russian Prime Minister, which is quite weird considering Durov's notorious anti-political stance.


Untrue


Fastmail +1 . I have had an active Fastmail account for at least 20 years. It provides the perfect amount of features for me, without the creepiness.


I wish their notes and calendar were better. I emailed them asking if they were ever going to improve notes, they said no. I've been a customer for 5+ years despite the bad notes


For what it's worth, you can use a dedicated note taking app like Joplin[1] and connect it to Fastmail storage via Webdav [2].

[1] https://joplinapp.org/ [2] https://www.fastmail.com/help/files/davnftp.html


In Russia using a VPN has been a necessity for a while already. I think most people here who even know about Fastmail use one already.


The open internet was a nice idea, but people with power tend to find a reason to use it.


>We have made the decision to block signups for all IP addresses we identify as coming from within Russia. We have also removed our app from the Apple and Google app stores for customers in Russia.

WTF? Why would you ever do that? You said you have no legal presence in Russia, why f*ck over the users? Instead of ignoring hostile stupidity you're helping it, this is mind boggling. Sorry, I can't "feel good" about your services anymore.


According to their blog post, "If we didn't comply, they stated they had the right to block our website (and possibly all data transmission) between us and anyone within Russian borders."

They were were going to be blocked anyway. So the two options were "Russian users are blocked, and the Russian government considers us law-breakers," or "Russian users are blocked, and the Russian government does not consider us law-breakers."

Even if there are no direct consequences that the Russian government can enforce on Fastmail, I can't imagine why they would want to choose option 1. Why do you think they should? What good would it do for anyone?


They might also be aiming to preserve their ability to send mail to russian mail servers, and to serve existing russian users, and to let new russian users sign up by signing up with a IP address outside of russia.

I.e. a choice between "russia is ineffectively blocked by us" vs "russia is effectively blocked by the russian government".


yeah remember the block is because they don't have enough Russian customers to make complying with local data laws worth the cost/effort. They were not banned the were asked to obey the law and they weighed up pros and cons. Normal. Plenty of US sites refuse to let eu citizens view thier content because they don't want to comply with GDPR (which I consider a reasonable set of laws that protect me) Personally I use Yandex for email so the NSA can't get their hands on it and I don't have to continually fight changes in terms and conditions that want to sync my advertising id with Google or Facebook. Fastmail obeying local laws is the correct thing to do. There is no malice in the law as it is written, its just data protection _from_ the US government.


> There is no malice in the law as it is written

Please read what you have wrote now.

Law say go spy after A and B, ESPIONAGE


> There is no malice in the law as it is written, its just data protection _from_ the US government.

That is absolutely not the reason for this regulation existing.


To me it's more disappointing that they actually considered meeting the demands of the regulatory body. I'd have simply blocked Russia after the loss in court.

Also, why should Fastmail expose itself any further, in any way as a target of Russia's corrupt dictatorship? It does suck for those Russians impacted. They should turn their ire toward the real problem though: their government.


What if they could meet the regulations without it costing too much and without exposing them to risk of compromising privacy and security? I don't see why you find it disappointing that they checked to see if that was the case rather than immediately pulling out.


I thought this too. On the other hand, it does make sense to them to publicly claim that the reason they moved out was for technical rather than political reasons. It might not make themselves a highly attractive target for a retaliatory DDoS attack.


> why should Fastmail expose itself any further

Expose to what exactly? Sanctions, neural-gas attacks or nuclear weapons? Does Russia have any legal or technical levers which could potentially harm Fastmail business?


I mean, I legitimately wouldn't be surprised if they took political prisoners if Fastmail showed up to court to fight, or hammer out an agreement. Let alone what they would end up having to submit to while operating within the country. Russia is known to be pretty hostile towards the west.


I don't think it's up to Fastmail to fix the nonsense coming out of the Kremlin. The Russian government wants them to basically compromise their service to comply with their spying needs, Fastmail simply opted out. I think they chose a reasonable option.


They didn't comply, which is perfectly reasonable. But they should have stopped at that. I don't know what "fixing" you're talking about.


We recently did a similar thing at the company I work for in response to similar pressures.

The effort to make that change was significantly less than the continual effort required to deal with the pressures. From a cost perspective their decision makes sense, from a customer perspective less so.


Again, what pressures?


I think you are underestimating the trouble a nation-state can make for a foreign company, especially if that foreign company continues to leave itself exposed by doing business in that nation-state.

I don't know the exact ins and outs of how courts will enforce foreign judgements (I'm sure it's very case-by-case), but saying "we cut off signups from people in that country" is surely a very strong prophylactic against such a judgement being enforced.

And on a more petty level, Russia could make serious trouble for any Russian expats employed by Fastmail (or their relatives still living in Russia). Cutting off signups makes this at least marginally less likely.


They still want their customers to be able to send emails to Russian servers. Having their servers straight up blocked would be annoying at best, disastrous for some users at worst.

Because email isn't like internet, the MXes connect directly and don't typically have intermediary relays.

If Russia decided to straight up block all fastmail MXes - Russian customers wouldn't be able to transmit anything between Russian hosted MXes and Fastmail. So their actions protect their functionality, more than their potential customers.


Soon similar will be happening because of the EU's TERREG - only difference is that even if you block EU IP addresses, the law is still going to apply if you have a "significant" EU user base. This means companies who want to opt out will have to request proof of citizenship of all their users to establish how "significant" is their user base and then either terminate the accounts or set up a legal presence in the EU with a censorship officer.


This is not a difference. The Russian law also talks about Russian users, not IP addresses.


I can understand Fastmail wanting to be in compliance with the law... or just not do business there.

Making a whole effort of operating in Russia, being blocked, and trying to work around that seems like a potentially endless effort. Meanwhile you're offering a service to your customers that would be pretty spotty considering all the hassle going on.


You may also want to watch my FOSDEM 2020 talk, "Software distribution: new points of failure (In a censored world)". It is about cases when governments block legitimate services due to nothing bad done by the said services, only because of their bad neighbors.

https://archive.fosdem.org/2020/schedule/event/sdnpof/


It is not about compliance (existing accounts are kept, and decision to prevent signups is made purely on the basis of the IP address and not e.g. the country that issued the credit card). It is about avoiding the promised blocking of outgoing mail from Western users of FastMail to Russian users of any other mail provider.


Well compliance and "avoiding the promised blocking" are same at this point.


It's a business decision and I doubt that they made it lightly.


To prevent new users from potentially losing access to the service later on. Why would you sell a mission critical service to a customer you know you cannot support?


I'm in US. I have a few people that I send emails to, who's MX servers are in Russia. I would be extremely annoyed, if I suddenly couldn't contact those people... because Russian "sovereign internet" system blocks my MX.

I would also be annoyed, if my email provider provided access to my data for Russian special services.

All considered - I'd rather that they cut off Russian signups, than either of the other two options.


I can't say enough good things about Fastmail, been a customer for many years now.


I wonder if it will affect the mail exchange, or only client access?


According to the article, it sounds like Fastspring themselves blocked customers with Russian IP addresses from signing up, and removed their app from Russian app stores.

I'd hope that even if the Russian authorities would block Fastmail, that they would only block their web servers and maybe their IMAP servers, but not their SMTP servers. The latter would impact a lot more people in Russia.


Anecdotally, Fastmail seemed to already be blocking Russian sign-ups 4 years ago. I know at least one non-user who couldn’t sign up around that time because of this issue. Either IP or (more likely) billing address was the issue, if I recall correctly.

Alternatively, their sign-up form was broken for all users at that time, but I hope they’ve better SREs than that.


Roskomnadzor themselves is not likely to block smtp or even imap traffic to fastmail in Russia.


Mostly because they're incompetent, not because they actually wanted those services to go under the radar.


I wonder why Fastmail decided to bend the knee and proactively block Russian IPs. The only thing those &^#%$-!@ could do is just that what FM did: block Russian IPs. Why make life easier for the dictators? What does FM gain by complying with their demands?


Why are they doing the government's work for them, and blocking Russia? Let the Russian government do the blocking. It's not your job to enforce authoritarianism, and no country west of Belarus is going to extradite you for providing email.


> Why are they doing the government's work for them, and blocking Russia?

In order to avoid outgoing mail to Russian mail providers from being blocked.

I.e., if the government blocks them, then BOTH Russian and Western users suffer (Russians because they can't access the service without technical tricks, and both because they can't send mail to Russian users of other mail providers). If they block Russian user signups themselves or can otherwise kinda-sorta-legitimately claim that they don't have Russian users, then only Russian users who don't have a VPN suffer from being unable to access the service.


Stopping people signing up in the first place means that in a few months' time when the government actually starts blocking, they don't get a load of angry customers demanding their money back.


Presumably, they and their lawyers believe they are subject to Russian jurisdiction. Why else would they have challenged an order from the Russian government in Russian court?


Leaving aside the rights and wrongs of the Russian government, I think that their general goal is sensible and we'll see more and more of this from all countries.

By their general goal I mean "the Russian media regulation body, the Roskomnadzor, demanded that Fastmail comply with Russian data laws. This is because Russia has a national goal of controlling the flow of information within their borders." (from the blog).

A company may not have any presence in a country but if they have customers there it's not unreasonable for that country to expect that its data laws should apply to the company's relation with those customers (and as it happens that's what the GDPR stipulate as well)


Compliance with legal features of various nations does not divorce companies from the responsibility for the results if they choose to comply.

Actively participating in oppressive behavior makes companies complicit. This is why companies today rightly face criticism for use of slave labor, abusive labor, resource exploitation, helping governments restrict speech, helping governments breach privacy (which results in people actually dying in places like Russia). Just because these things are legal to not make them right or acceptable to Western exployees, shareholders or governments. If Russia demanded that I must take actions that would potentially result in deaths from their authoritarian regime, like by giving them access to our customer's communications, I'd tell them to get bent.


That was my reaction as well, though I still don't like it.

That is, I don't like that GDPR-like laws can extend to actually blocking services. But they already do. I'd prefer that they just force "disclosure", like "Yes, I understand my email won't be stored in my home country".


Except there was much MORE to it than just that statement.


Actually, GDPR went way beyond that, demanding that every website in the world comply with their laws, regardless of whether or not you had customers in the EU, unless you count somebody reading your personal blog as a “customer.”


Wrong. GDPR asks that every website comply with their laws for anything that relates to EU. An italian citizen has to agree about it even if they live in Nepal. But a nepalese website doesn't have to care about GDPR as long as they don't have a presence in the EU.

The fact that websites put a cookie wall for everyone is the strategy of said websites to make everyone think they are victims of GDPR, but that is not true. If you don't want to put a cookie wall, the easiest option for everyone is to not gather personal data.


> But a nepalese website doesn't have to care about GDPR as long as they don't have a presence in the EU.

Not really 'presence' but customers in the EU, or simply targeting people in the EU.


EU TERREG changes the scope so that the location no longer matters and it applies to services with "significant" user base of EU citizens. It essentially mean to opt our from having to support 1hr SLA for content removal, services will have to check papers of all users to ensure they are not EU citizens.


> ...A nepalese website doesn't have to care about GDPR as long as they don't have a presence in the EU.

Sure. You don't have to care. But this is blatantly wrong according to GDPR.


No, because you're not targeting EU citizens and are also not operating in the EU.


Nearly everyone gets GDPR territorial scope wrong and whose data it applies to wrong.

Where GDPR applies is covered in Article 3, "Territorial scope". In what follows I'm going to use the term "processor" to refer to those processing or holding data or controlling those who process or hold data. GDPR makes the distinction but in most places the same rules apply to both.

1. GDPR applies if the processor is "in the Union", regardless of whether or not the processing takes place in the Union.

2. GDPR applies regardless of the location of the processor if they are processing the data of people are are in the Union if the processing is related to:

(a) the offering of goods or services (paid or free) to people in the Union, or

(b) the monitoring of their behavior as far as their behavior takes place within the Union.

Some things to note that are often overlooked.

1. It says "in the Union", not "citizen", not just in Article 3 but everywhere in GDPR. An Italian citizen living in Nepal is equivalent to a Nepalese citizen living in Nepal. (And it goes the other way around, too...a Nepalese citizen living in Italy would be equivalent to an Italian citizen living in Italy as far as GDPR goes).

2. If people in the Union come to your website and you either offer them goods and services or you monitor behavior of theirs that takes place in the Union, then the EU considers GDPR to apply.

Whether or not you have to care about that is complicated, because even if the EU does not have the power to directly enforce it against you, they may have indirect power. For example, a place I worked collected tax on online sales of digital goods in Europe, even though there was no way the EU could make us do so, because our payment processor required us to collect taxes of the jurisdiction the customer was in.

One of the recitals says that when it comes to offering goods and services, what matters is whether you envisage offering them. The fact that people in the EU can reach a Nepalese website would not be sufficient on its own--what the EU would look at is whether the site did things like localize to EU languages (that aren't common in Nepal), accepted EU currencies, advertised in the EU, and things like that.

If you aren't intending to offer goods and services in the EU, and aren't doing things EU specific to make it easier and more likely that people in the EU will use your goods and services, then you probably don't have to worry about the 2(a) "offering goods and services" basis for GDPR territorial scope.

It's the 2(b) one that is the big worry, monitoring behavior that takes place in the Union. As written that is pretty open ended. It is not at all obvious what kind of behavior is behavior that takes place in the Union. There's nothing in the relevant recital about "envisages" with that one, so it appears that if you are doing something that counts as tracking behavior that takes place wherever the visitor is from, then GDPR is something you have to worry about if people in the EU can visit your site.


Wait a minute. Why would Fastmail preemptively block Russian IPs if they don't have any legally vulnerable presence in Russia? Just to deny Roskomnadzor the joy? There is Russian proverb that aptly describes such behavior: "назло маме отморожу уши" (cut off your nose to spite your face).

> What you can do if you're affected

> - Talk to Roskomsvoboda: a digital rights advocacy organization.

I like when private companies tell their customers what politics they should engage in.


> I like when private companies tell their customers what politics they should engage in.

Well, if they can't provide a service or are having problems doing so for legal reason, it's only sensible to ask their customers to lobby for a better legal framework if they wish to receive that service. It's a problem (IMO) if what they ask for is unrelated to their business, but quite a few people would disagree with that, as well; especially if they fight for something they deem necessary.


> ask their customers to lobby for a better legal framework

Do you understand the absurd level of naïvete of this position?


I genuinely don't. Can you explain it to me?


First of all, you're a service operator, political activity of your customers is not your business.

Secondly, lobbying doesn't exist in countries with no political representation. The only political activity available in such countries are activism (not of the bureaucratic type) and sabotage, all severely punishable.


> First of all, you're a service operator, political activity of your customers is not your business.

Yes, but they're not asking about it. They're just saying "we can't provide this service for this reason; if you want to use this, we need help with this law". I don't see anything unreasonable there. Of course, one could go the Google way and say "No service for you, no reason why, your questions will be ignored", but I think this is quite an unreasonable demand. It's not like someone is forced to lobby for you, they just say why and what to change.

> Secondly, lobbying doesn't exist in countries with no political representation. The only political activity available in such countries are activism (not of the bureaucratic type) and sabotage, all severely punishable.

Lobbying was meant in the farthest sense in my original comment. Still, I don't see why they should not name a reason and/or course of action despite this. "We can't service you, come cry with us in the corner" is really not something to put on your website.


> if you want to use this, we need help with this law

It's reasonable to say this, but not reasonable to expect this to happen. Knowing this won't happen but still asking for this just paints you clueless.

> We can't service you

They can, they just decided not to.


We don't have political representation, but very much have lobbying. Sabotage of telegram is not punishable at all. This is straight nonsense.


> block signups for all IP addresses we identify as coming from within Russia

I think they hope that this way they will not be blocked and thus the existing customers can keep connecting indefinitely.


> I like when private companies tell their customers what politics they should engage in.

They didn't tell you you should do it. Just that there aren't many other options.


A sufficiently powerful state actor can find ways to penalize you, harm your company, or make the lives of principals or employees terrible even if you don't think you have a legally vulnerable presence in their jurisdiction. Just ask the USA!

I would imagine their lawyers recommended it. I too would be curious to see the legal memo, but I'm not surprised that a company would take this course, it does not seem unreasonable to me.


>Just to deny Roskomnadzor the joy?

No, to minimize damage by calming down proverbial monkey with a grenade.

Webmail, imap & registration blocking is trivial to avoid. MX servers ending up in some blocklist might cause much more problems.


Understandable from this point of view -- with Internet being a shared resource -- but a strange concession nevertheless. Every participant of the Internet would end up blocking Russia to reduce the chance of some Russian official doing something stupid, hoping that they see website/email/torrents inaccessible and go bother someone else.

Oh well, that's what politics and power games are all about.


O/T

> There is Russian proverb that aptly describes such behavior: "назло маме отморожу уши" (cut off your nose to spite your face).

Curious to finally learn its origin, I had a Google - particularly as the phrase popped into mind this morning on my walk to work.

It Doesn't appear to be of Russian origin, per se. Certainly, It was something I heard a fair few times coming out of the mouths of Scottish family when I was younger.

https://en.wikipedia.org/wiki/Cutting_off_the_nose_to_spite_...


The Russian phrase has a different literal meaning though. ‘I’m going to freeze my eats to spite my mum’ which refers to mothers insisting their kids wear warm hats in winter.


Ears*

For anyone thinking what is eats in Russian.


Thanks, 'r' → 't' is a very easy to make typo :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: