Fastmail accounts blocked in Russia, here's what we know
fastmail.blog
fastmail.blog
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.
And then if something goes wrong I make a copy of my backup, and invert the configuration to sync local -> imap.
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
How do you like mailfence overall?
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.
Is Master = Far and Slave = Near? I'd lean towards the opposite but I can't tell for certain.
[1] https://sourceforge.net/p/isync/isync/ci/master/tree/src/mbs...
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
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/
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.
What's the point of using mbsync?
I mean the idea is great but wouldnt you need a backup mailbox provider allowing you to restore daily snapshots?
I'm not sure what happens if the remote emails are overwritten though.
* https://github.com/samhh/dotfiles/blob/master/home/.config/o...
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 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.
Wow, that is something
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
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.
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 hope you're right!
Additional bonus: use all kinds of addresses you want (me@shadyservice.domain.com) for easy blocking if an address leaks.
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.
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?
Assuming "really [good] option"
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...)
Checked out both protonmail & fastmail among others, ended up selecting kolabnow, no regrets.
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?
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 shifted over from Fastmail (who are amazing, don't get me wrong) because I got a good Black Friday deal.
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).
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.
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)
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.
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.
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.
Russia's situation is far from China, AFAIK.
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/
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?
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.
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.
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?
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.
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).
> 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.
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?
In the end they "stopped trying" and actually embraced using Telegram as a propaganda tool nowadays.
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.
[1] https://joplinapp.org/ [2] https://www.fastmail.com/help/files/davnftp.html
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.
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.
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?
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.
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.
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.
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.
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?
I.e. a choice between "russia is ineffectively blocked by us" vs "russia is effectively blocked by the russian government".
That is absolutely not the reason for this regulation existing.
Please read what you have wrote now.
Law say go spy after A and B, ESPIONAGE
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.
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.
Alternatively, their sign-up form was broken for all users at that time, but I hope they’ve better SREs than that.
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.
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)
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.
Sure. You don't have to care. But this is blatantly wrong according to GDPR.
Not really 'presence' but customers in the EU, or simply targeting people in the EU.
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.
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".
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.
> 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 think they hope that this way they will not be blocked and thus the existing customers can keep connecting indefinitely.
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.
Oh well, that's what politics and power games are all about.
They didn't tell you you should do it. Just that there aren't many other options.
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.
Do you understand the absurd level of naïvete of this position?
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.
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.
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.
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.
> 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_...
For anyone thinking what is eats in Russian.