I've been a happy Fastmail customer too, until I was made aware that you can impersonate other Fastmail customers by just spoofing the email address. Their servers just happily accept it. SPF and DKIM all pass with flying colours, and the only way you'd know it's happened is if you have DMARC on and happen to notice a pass in the report you don't remember sending. Well, that is if the recipient doesn't reply to the spoofed message - hope the damage wasn't already done though. It's effectively impossible for the recipient to know it's been spoofed.

The worst part is I think Fastmail is aware of it and just don't care (believe that's why they mark their emails with a green tick and text). I understand that email has never been really authenticated, but this just throws any trust I had in Fastmail out the window.

I will be evaluating other mail hosts at the end of my subscription.

SPF/DKIM are designed to prevent spam and not to prevent spoofing of From. There is a difference.

SPF has nothing to do with the From header. And the DKIM signature does not have to match the sender’s domain, the signature can be that of any domain. This means that for practical purposes, anybody can send spoofed emails. That an email is signed with DKIM, that doesn’t mean much and it is meant to build a web of trust between servers, but otherwise it is useless for the users themselves.

They wrote a blog post about how SPF/DKIM work: https://fastmail.blog/2016/12/24/spf-dkim-dmarc/

If you want to let people know which emails are from you, the From address is very weak. This is because the From/To headers tell you nothing about the source and the destination of the message, according to the email standard. Read that blog post for details.

You need a proper signature via PGP or S/MIME if you want to ensure that the receiver knows the message is from you. And unfortunately this requires education and email clients with support for such signatures (most desktop clients do), but that’s email for you.

Sure, I get that. I get there is a whole weird and wacky world of email use that is considered legitimate and needs to work that way for a myriad of reasons. I don't get why their MTA cannot at least have an option to reject mail from your domains if it's not being sent using your account credentials.

The average layperson will not get that. I'm fairly sure if my mother received an email that wasn't delivered to a their spam folder saying "Hey, remember that old copy of my birth certificate you have floating around? Could you send that. Also, CC my good friend [email protected]" that she would call me first - if I was reachable. Also is totally ignorant of digital signatures and most likely unable to verify any present anyway.

As much as I dislike Google and try to avoid their products and services at all cost, at least I have confidence this wouldn't happen with them. Not that I would go back, but it's still concerning.

But that’s the point, you can send a spoofed email to your mother that will not go into her spam folder, even if she uses Gmail.

The only way Google could protect you is if the From address is from @gmail.com (maybe, not completely sure). But if you have your own domain, you can’t have that protection. Sure, you might not be able to use Google’s own servers to send that email, but email is federated so you can use somebody else’s servers.

The only thing that stops spammers from doing more of this is the web of trust happening between email services. This is precisely why if you setup your own server, you’ll start off with a negative reputation and your emails will end up tagged as spam depending on the destination.

> But that’s the point [...]

No, that's not the point.

> Sure, you might not be able to use Google’s own servers to send that email

That is the point. Why does Fastmail allow this where Google doesn't. At best, it's ignorant and intentionally misleading. At worst, downright malicious and ripe for abuse.

There's much I don't know about email, so take what I say with a grain of salt. I imagine that maybe this could simply be a low priority issue for Fastmail because such a restriction would not be a protection for their customers but rather a restriction/disservice to them to potentially protect everyone else.

I also wonder if there are superusers that have a legitimate use for sending emails that have a different "From".

Something to think about is that, looking at the postal mail it was designed after, I don't imagine a postal office would reject me if I tried to drop off mail authored by someone else. They don't check the "From" in the envelope with my ID or anything. In fact, many envelopes don't even have a "From", and you don't even have to face a human when dropping off your mail. All the postal office does is provide access to the global delivery network for a fee.

It might be more apt to think of email providers likewise as network providers that allow transparent access to the global MTA network.

Both postal and electronic mail rely on signatures for proper authentication. It's only that electronic mail's (cryptographic) signatures are more secure but more difficult to use by laymen.

Maybe this issue ought to be thought of a similar to how illiterate people sign paper documents by making an "X". I imagine it's trivially easy to spoof documents supposedly signed by them, and even mail them. I wouldn't blame the postal office for accepting such spoofed documents.

Computers being relatively new and all, perhaps it isn't that bad to think that most of the world is still computer illiterate even if they think otherwise because of their ability to use point-and-click interfaces designed to be used even by illiterate young children.

What I think is needed is better computer education.

As to where this expectation for "From" to be validated comes from, I imagine it's something we've grown accustomed to from our use of centralized services. It would be really bad if a message on Facebook or Twitter could be spoofed, but those services are centralized, so restricting their users equates to properly protecting their users. Email, however, is decentralized. That's a good thing, and the proper way to do authentication in an decentralized service without making it more centralized can only be by non-spoofable signatures and not by trusting validations from independent service providers.

FWIW you can inbox mails from spoofed @gmail addresses on gmail.

At this point, none of the mainstream email websites or applications even show the From address, just the name that came on the email, or what matches from your address book. So, I fully expect people to get mail from [email protected] with a From name vaguely related to me and assume I sent it.

You should just send an email impersonating their CEO to their IT telling them to fix it ;)

That will definitely work

I'm sad to hear that but it seems to be true. I understand they have legacy stuff to support but it seems negligent for a company that exclusively deals in email to ignore something like this.

https://www.fastmail.com/help/technical/senderauthentication...

This!!

I reported the same problem to posteo.de in March 2016 and still have not received a satisfactory answer, though it seems they have some counter-measures in their webmailer nowadays. The fun part was that as a "no logs" privacy-oriented provider, they were not even able to track who sent them a complaint from their own support address ¯\\_(ツ)_/¯

As a comparison: at disroot.org I found the same problem, and it took them a few hours to repair their postfix configs.

Do you have any reference for this issue?

This freaks me out too, and it turns out it's true: here's a mention on their Bug Bounty page [1]:

"Email spoofing bugs do not qualify. We are quite aware that users can set arbitrary From addresses on emails, that our SPF records allow arbitrary hosts to send email as our domains, and that our DMARC policy is not enforcing passes. These policy decisions are by design, and we track the actual sender in a separate header."

[1] https://www.fastmail.com/about/bugbounty.html

It's not entirely clear to me what they could do about it. Since they are an email provider, they probably don't have control over the networks their customers send email from, and what else their customers do with their domains.

Someone could decide to forward their other mail to their fastmail account. Should they then potentially risk email their other customers send to that address? DMARC headers tries to solve this, but the world is dirty, mailing list software suck, and their they would have to take the blame for problems outside their control.

I can understand the decision. They could probably do something to show good intentions, like flagging suspicious email and making sure their own email software shows appropriate warnings, but it's never going to be perfect.

They could configure their MTA to rewrite the From: header so that the value matches the authenticated user and that the sender users the Reply-To: header to redirect replies instead.

They need to provide the ability to use SMTP servers other than their own for @fastmail.com users.

SPF, DKIM and DMARC do not provide authentication of non-envelope headers like From: and To: etc, unless they are specifically included, but there is no way to publish that you require those headers as part of the DKIM signature.

Exactly. This is also what makes SPF and friends a bit of a pointless exercise. Even if they had global unanimous support end users don't really care about the envelope from anyway.

Stopping phishing is hard. End users mostly are fooled by a little padlock in their web browser, and that's a much simpler trust model. Eliminating email dressed up as web pages would probably do more to combat that than authenticated sender models ever will, but nobody really wants that.

I think the thing that is concerning to me is not so much that users don't care about the envelope from, so much as it is that other email providers' anti-spam measures may block my email if some spammer start spoofing me. Then, poof! I can't email any gmail accounts anymore.

Is there anything in the email headers that shows the authenticated user? My preference would be that email providers rewrite the From: header to match the authenticated user and that the sender uses the Reply-To: header to direct replies to a destination of their choice.

Not good enough, as many email clients show both of these fields. The whole idea why people use this is to send and receive with one address only, even if you've authenticated with another.

I believe most email clients will default to using the Reply-To: header to determine the value of the To: header in the reply, so if both headers are specified and even if the email client displays both of them, then the recipient would have a chance to determine whether the email is authentic or not.

Fastmail includes a header - decodable only by Fastmail - that can identify the sender account. And IP address if sent through SMTP.

What is the reason for allowing this? Laziness?

They would need to make some tie between sasl authentication and what FROM: headers you're allowed to use. I don't know what MTA they use, but there are MTAs that have that feature. It's controlled_envelope_senders in postfix. I assume other MTAs have similar features.

It sounds kind of lazy to me. Though I'm sure they would get lots of complaints if they turned it on...some mailing list software depends on spoofing, for example. Or web based "contact us" forms. So perhaps it's just to avoid lots of support tickets.

The reason is probably that nothing can stop the successful spoofing of the From header. DKIM is a signature for authenticating a domain, however that domain does not have to match the domain in the From header.

Take a look in Gmail at a signed email and you’ll see a “Signed by” field in its header info, with a domain name as a value.

Also the SPF setting has nothing to do with the From header either.

In other words the “From” value cannot be protected, unless you sign your email with PGP or S/MIME.

That's tripe.

They know who authenticated to the SMTP server, so they could enforce that the From address is who it was authenticated by. Otherwise, they basically act as an open relay.

Sending from multiple From addresses is a common use case. I send from at least 4 different email addresses all hosted by fastmail in the same account. Having to create different logins to authenticate each sender would be a huge pain.

Plus it's not a unique problem to fastmail.

Gmail requires that you prove ownership of an email address by clicking a link in an email before letting you choose it as a From: address. I think this is a good compromise.

You can also take a blacklisting approach, where it's open-by-default and users shall be able to restrict any domain to properly authenticated users only. That way, it is purely a security enhancement for those who want it (like me).

I demonstrated this behavior to eggsampler after discovering it quite a long time ago by messing around with HTTP payloads in their web interface - it's wild to me that FastMail will use the DKIM private keys from an entirely different FM account to sign your messages.

Unlike eggsampler, I won't be ditching them, but I hope that FM reconsider their policy eventually. That they have awarded themselves the privilege of a "green tick" on their own official emails while throwing everybody else to the wolves is slightly ironic.

Presumably they could require that the from address is one your authenticated user is allowed to use, right?

I'm not certain, maybe there's a technical reason they can validate account credentials but not map credentials to addresses/aliases. Doesn't instill confidence either way.

Just to make it clear, is this true if you use your own domain, or just if you use any of Fastmail's domains?

Seems to be just Fastmail domains but there might be some setup involved for custom domains. See their docs

https://www.fastmail.com/help/technical/senderauthentication...

If I understand this correctly, you need to be managing your own DNS (not letting Fastmail do it), and you probably need to set p=reject in your DMARC so that non-fastmail servers can't spoof your addresses.

And if Fastmail allows Fastmail user A to spoof Fastmail user B, then the above still only protects you against non-Fastmail customers.

I have received a spoofed email from my own domain, so I believe it's not just Fastmail domains but any custom domain on an account.

Do you host your custom domain with Fastmail? I may have misread but the article seemed to suggest you could potentially setup dmarc via the DNS page or whoever you host with.

The From header has always been spoofable. It's just most ISPs (and Google) chose to disallow it to address low-hanging fruit in the fight against spam.

But anyone can set up their own postfix/qmail/sendmail server and put anything they want as the From.

Or am I misunderstanding the issue here?

The difference is that using another fastmail account to spoof [email protected] will make the email look much more legitimate (DKIM and SPF wise) to other servers than when it comes from your random.emailserver.domain.foo.

...wow. Do you have any recommendations for alternatives?

Use GPG if you're concerned about authenticity. It's the only way. What you describe is not a problem with Fastmail, it's a problem with basic communication without cryptography.

The problem is if any email service did this you'd start trusting the "from" field and that is wrong. Do not trust the from field. It's as simple as that.

> after a trial realized that Gmail does many things well, except for being a good email service.

This.

I remember back when Gmail was new and hot. It was unlike any other email service out there, and ridiculing people for using inferior email-solutions could to a certain extent be justified.

While other webmails were slow, had constantly reloading pages and what not, Gmail was fast. It was amazingly fast. Gone where the 5 minutes making the webmail work for you. You just sent the email and you were done. Just like that. Back then, this was unheard of.

These days though? Everyone is still pretending like GMail is the only game in town, when I think they have one of the worst webmail-interfaces out there. And it's slow. Oh god it is slow. And god forbid you try to load it in a browser not Chrome, because then it just grinds to a complete halt.

So yeah. Happy Firefox-using FastMail-customer here. You couldn't get me back to GMail even if you paid me.

The main thing gmail offered back then was a frickin GB of email storage. (Which spawned a host of other things, like a FUSE filesystem backed by Gmail.) No other free provider was even close! Hotmail offered email measured in 10s of MB and I'm sure Yahoo was similar.

(I got my first gmail account in 2004.)

Yeah, the UI wasn't bad, but there was less email back then and I didn't (still don't) really mind being served HTML repeatedly instead of some "AJAX" application, which is what I remember the technique being called. (It used to be the latency to the server was poor and JS hid that; now, on 2-3ms fiber, it seems that the JS actually introduces a lot more latency than it hides.)

Hotmail provided just 2MB of space when gmail launched on 01 Apr 2004. They increased it to 250MB in June 2004.

source: https://www.pcworld.com/article/116657/article.html

I used Yahoo Mail at the time, which had a limit of 6MB (and IIRC that had been an increase at some point). Soon after GMail came out they upped that to 250MB. Searching now I find an article saying this happened December 2004. I seem to remember it happening closer to the GMail announcement though but I could be wrong.

Does FastMail let you have complex conditions in filters though? One huge value of Gmail for me is that I can have arbitrarily complex nested conditions to filter mail using a formula. I've been looking for even more flexible filtering (e.g. custom scripts) and yet I have not even come across anything on par with it.

fastmail lets you write complete scripts for filtering using the Sieve programming language. https://www.fastmail.com/help/technical/sieve.html

Sieve is great. I highly recommend it over, say, procmail, or Outlook filters (especially Outlook Web Access).

Isn't procmail dead?

What does dead mean to you? It still compiles and you can install it from various binary repositories.

It's not even maintained and the official site seems long gone. How do you see this as alive?

Holy cow, I will have to look into this. Thanks a ton!!

filters cannot be applied retroactively, however.

be sure to write your filters before receiving anything. Especially important if you're importing your email for the first time... and insanely annoying if you want to debug such an advanced filter.

as always with fastmail: It has great features... but always with a massive caveat.

Ooooof, wow, thanks for the heads up. There's no way that's going to work... I edit my filters and apply them retroactively... There's no way I can set them in stone the first time. :( is there any email service that doesn't have this limitation?

Its not on FastMail, its on Sieve. It is a hook that runs on receiving. To my knowledge if you want Sieve this is the only option. I use it with Protonmail and it is the same way. I also run it on my own mailserver.

One nice thing, for me at least, is it runs prior to the email ending up in your inbox and I am uses to Outlook rules were rules execute post arrival.

Sieve is an RFC email language. There's no reason Sieve recipes couldn't be applied to a corpus of existing email; that's an implementation detail of FastMail. Sure, it isn't necessarily the same as pre-receive (for example, anything you discarded the first time isn't going to show up again, and any manipulations made the first time aren't going to undo themselves). But it could be done; it's not really Sieve's problem.

Wouldn't using something like https://github.com/lefcha/imapfilter also be an option?

It would be awesome if some day there was a "jmapfilter". I think JMAP would be really efficient for this use case.

Most of my filters are simple searches. And if you can search, you can apply it retroactively.

Also FastMail’s search works for any email header so it can be more potent than that of Gmail.

I wonder why can’t they add a checkbox to apply the rules retroactively. Seems to be simple enough.

I considered FM a while back but... you pay per account! $50/account no less! I separate my email into three accounts across two domains and my wife does the same and I have kids who'll have their own email addresses at some point.

I can't even begin to consider using it at the price point I presume I'd be in.

I use a single account for 5 domains, with multiple aliases per domain.

For IMAP folders you can set a default identity and email in a folder stays in that folder without cluttering Archive, like in Gmail. So in effect you can do much with a single account.

You can have all the domains under one fastmail account per user (I have ~8 domains, and ~20 users). But yes, you still have to pay for each person

Check out migadu.com; They price their plans according to how many emails you anticipate to send.

$30 for a smaller inbox though. I have all my email since 90s in there and it all still fits just fine.

For people reading along: $50/yr gets you 25 GB; $30/yr gets you 2 GB. I'd guess 2 GB would work just fine for most people.

OTOH, my relatively new gmail account has >4 GB in it. Other accounts have 0.8 and >3 GB; none of these were used for file storage (FUSE) or anything like that.

https://www.fastmail.com/pricing/

I wonder, maybe I then just don't receive that much email? I did a quick count in the folders view, there's currently about 35k emails which take up about 1.7G of space.

If I read their pricing page correctly, you have to be on the $50 plan to use your own domain name.

> Also from what I understand JMAP should be friendly for mobile usage.

I read the FM blogs and I remember them mentioning that low battery consumption was one of the design goals.

The JMAP site [0] has:

> JMAP is designed to make efficient use of limited network resources. Multiple API calls may be batched in a single request to the server, reducing round trips and improving battery life on mobile devices.

[0]: https://jmap.io/spec-core.html

> Also from what I understand JMAP should be friendly for mobile usage. They kept notifications out of it, you're supposed to implement notifications using whatever the mobile platform provides. Interacting via JMAP is via plain HTTP requests, which is super cool.

Sounds actually not cool. Is there really no standardized way to do notifications? The world consists not only of shitty mobile walled gardens which insist on or strongly favor their proprietary implementations.

Using what is provided by mobile operating systems is the standard. FastMail is decoupling JMAP from notifications because it's a sound architectural decision for that reason.

If you want good battery life, there is no alternative to the mobile notifications provided by the platform, because otherwise you have to always keep your own connection open to your server.

please don't spread misinformation - abusing long live socket connections is what drain the battery - having one open and managing it in sane manner is quite battery efficient. Google brainwashed everyone to force them to use their push service, which is just plain awful... (and requires open connection... sic!)

That's simply not true if implemented correctly. Maintaining an open connection yourself has at most minimal impact on battery life. See for example Conversations (XMPP client) which is able to do this just fine on Android.

> ...Gmail does many things well, except for being a good email service.

Gmail/Gsuite seem to be good email services from my perspective as lay user and occasional admin. Can you expand on why you think they are not good email services?

Here's a few things:

- constantly changing things around. UI gets less intuitive for every release.

- slower for every release

- violates IMAP standard by re-using IDs across tags/IMAP folders, risking actual data loss. Example: if you in a real email-client try to delete a email from a single folder, you will also delete this email from all other folders it has been "tagged" in.

- similar IMAP issues with sent emails. Hard to track sent emails from email-client, unless you allow the email-client to explicitly save a copy to sent-emails folder. But then you suddenly have duplicate emails in the web-UI.

- Makes an open standard (internet email) proprietary.

- Hell to integrate with: See above.

I'm sure I could go on, but really. If you still consider GMail best in class, the only possible explanation is that you haven't seen anything else.

The messed up deletion behavior baffles me to this day. The stock mail app on iOS will behave correctly if you muck with the Gmail POP/IMAP settings and turn off 'Archive' in MobileMail, but I have zero confidence that this will work on macOS because Apple pays less attention to the desktop and Gmail don't give a crap if actual client applications work correctly.

They just assume everyone uses the web interface.

> They just assume everyone uses the web interface.

More likely, they want you using their app and their web interface, and merely tolerate third party apps. For now.

Google wants you in the Googleverse forever.

I’m not a fan of Gmail either, mostly because it lacks push vis iOS Mail (which Fastmail supports, so it is possible), and its non-standard tagging system doesn’t not play well with any third-party client that does not take extraordinary steps to accommodate it. Folders are better. Its proprietary apps are terrible and its web interface is weird, unintuitive, ugly, and slow.

I find it's "non standard" tagging system is a massively superior model for managing email. I really wish there were alternatives that did similar, and a protocol like IMAP or JMAP that assumed the tagging based model underneath.