5 ms·

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 serv

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.

navlelo 8y ago
What is the reason for allowing this? Laziness?
- eggsampler 8y ago
  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.
- tyingq 8y ago
  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.
- bad_user 8y ago
  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.
  - richardwhiuk 8y ago
    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.
    - sitharus 8y ago
      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.
      - bscphil 8y ago
        Presumably they could require that the from address is one your authenticated user is allowed to use, right?
      - shawnz 8y ago
        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.
        regecks 8y ago
        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.
stefanfisk 8y ago
Do you have any reference for this issue?
- willj 8y ago
  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 https://www.fastmail.com/about/bugbounty.html
  - xorcist 8y ago
    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.
    - u801e 8y ago
      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.
      - rswail 8y ago
        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.
aepiepaey 8y ago
Just to make it clear, is this true if you use your own domain, or just if you use any of Fastmail's domains?
- Riverheart 8y ago
  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.html https://www.fastmail.com/help/technical/senderauthentication...
  - eggsampler 8y ago
    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.
    - Riverheart 8y ago
      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.
  - bscphil 8y ago
    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.
bad_user 8y ago
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/ 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.
- eggsampler 8y ago
  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 bad_user@fastmail.com" 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.
  - bad_user 8y ago
    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.
Riverheart 8y ago
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.html https://www.fastmail.com/help/technical/senderauthentication...
u801e 8y ago
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.
- distances 8y ago
  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.
  - u801e 8y ago
    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.
- forgottenpass 8y ago
  Fastmail includes a header - decodable only by Fastmail - that can identify the sender account. And IP address if sent through SMTP.
hiccuphippo 8y ago
You should just send an email impersonating their CEO to their IT telling them to fix it ;)
- brongondwana 8y ago
  That will definitely work
mehrdadn 8y ago
...wow. Do you have any recommendations for alternatives?
athenot 8y ago
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?
- m4lvin 8y ago
  The difference is that using another fastmail account to spoof someone@fastmail.com 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.
m4lvin 8y ago
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.
black-tea 8y ago
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.

navlelo 8y ago

What is the reason for allowing this? Laziness?

eggsampler 8y ago
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.
tyingq 8y ago
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.
bad_user 8y ago
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.
- richardwhiuk 8y ago
  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.
  - sitharus 8y ago
    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.
    - bscphil 8y ago
      Presumably they could require that the from address is one your authenticated user is allowed to use, right?
    - shawnz 8y ago
      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.
      - regecks 8y ago
        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.

stefanfisk 8y ago

Do you have any reference for this issue?

willj 8y ago
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 https://www.fastmail.com/about/bugbounty.html
- xorcist 8y ago
  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.
  - u801e 8y ago
    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.
    - rswail 8y ago
      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.

aepiepaey 8y ago

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

Riverheart 8y ago
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.html https://www.fastmail.com/help/technical/senderauthentication...
- eggsampler 8y ago
  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.
  - Riverheart 8y ago
    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.
- bscphil 8y ago
  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.

bad_user 8y ago

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/ 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.

eggsampler 8y ago
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 bad_user@fastmail.com" 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.
- bad_user 8y ago
  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.

Riverheart 8y ago

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.html https://www.fastmail.com/help/technical/senderauthentication...

u801e 8y ago

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.

distances 8y ago
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.
- u801e 8y ago
  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.
forgottenpass 8y ago
Fastmail includes a header - decodable only by Fastmail - that can identify the sender account. And IP address if sent through SMTP.

hiccuphippo 8y ago

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

brongondwana 8y ago
That will definitely work

mehrdadn 8y ago

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

athenot 8y ago

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?

m4lvin 8y ago
The difference is that using another fastmail account to spoof someone@fastmail.com 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.

m4lvin 8y ago

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.

black-tea 8y ago

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.