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.
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.
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.
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.
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.
https://www.fastmail.com/help/technical/senderauthentication...
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.
"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."
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.
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.
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.
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.
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.
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.
Plus it's not a unique problem to fastmail.
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.
https://www.fastmail.com/help/technical/senderauthentication...
And if Fastmail allows Fastmail user A to spoof Fastmail user B, then the above still only protects you against non-Fastmail customers.
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 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.
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.