HN Explorer

Tell HN: Fastmail is leaking internal routing email address/username with teams

83 points by throwawayfm ↗ HN
Using throwaway...

Fastmail is leaking the distribution mail address/username via the X-Resolved-to header.

Now, normally this wouldn't be such a big problem, but when someone (needs to) forward(s) the original email as attachment, the internal email addresses are revealed, which is many cases is your Fastmail username. In my opinion this is a security / data leak. Fastmail's "fix" is to manually remove the X-Resolved-to form the email source. Of course this is ludicrous because:

1) People in your team would never do that, and non-technical people wouldn't even know how to.

2) It's easy to forget.

3) It changes the email, so any signature will not be valid anymore, marking it as corrupted.

I asked to escalate the issue when support couldn't reproduce (not sure why not, as my screenshots were clear, and their KB article explains that these headers exist). Even though it has been "escalated" to the "Support Lead - customer/technical" the "solution" still is to remove the header manually.

The header is of no use for Fastmail's customers, and is probably only used to Fastmail's internal routing for the team-mailbox-feature. It actually makes me second guess if JMAP is even properly designed. I'm very disappointed by the way this has been handled, as I clearly described why this is an issue.

Over the course of two weeks:

  Reply 1:
> The X-Resolved-To header is only added to incoming emails to Fastmail, hence only you will be able to see this header. It is not applied to outgoing emails, that is the X-Resolved-To header is not passed along when forwarding an email or replying to an email.

> However, I have shared your suggestion with our development team as a feature request. Please note that we're unable to offer any timeline as to if or when this feature could be implemented.

  Reply 2:
> I'm afraid I was unable to reproduce the issue you are seeing. When forwarding an email as an attachment and later checking the headers of the attached email, I could not find the X-resolved-to header nor was my Fastmail username mentioned in the headers.

> Therefore, could you please share a screenshot of the issue?

> On the other hand, I understand that your Fastmail username will be exposed when sharing a screenshot of the email headers. Therefore, I recommend refraining from doing so. If needed, you could copy-paste the headers to a Word doc, remove the X-resolved-to header and then share the screenshot.

  Reply 3:
> I’ve escalated your ticket to a Tier 2 agent, as they are best suited to assist with this issue. Please note that if you have a complex issue, or if they’re handling a large number of tickets, response time may be longer.

  Reply 4:
> I’ve escalated your ticket to a Tier 3 agent, as they are best suited to assist with this issue. Please note that if you have a complex issue, or if they’re handling a large number of tickets, response time may be longer.

  Reply 5:
> Unfortunately there is currently no way to remove the X-Resolved-to header if you forwarding the raw form of the email. You will need to manually remove the header, by downloading the email, opening it in a text editor and then attaching the email again. Note that, the email authentication is checked against the email and not the attached ones, so that shouldn't fail the sending email authentication. However, if you are doing any checksum against the original email content, then yes that would fail because of change in headers. I am sorry, but there is currently no work around to this

25 comments

[ 3.7 ms ] story [ 62.1 ms ] thread
nickphx
If I understand this correctly.. someone that you communicate with via e-mail may potentially see your username for the email provider you're sending mail from? Why is that an issue?
aendruk
I may send mail as a pseudonym but log in to Fastmail using my full name.
dewey
That sounds like a process where it's very easy to slip up and if that's something to be concerned about in your threat model maybe you should not be doing that in the first place.
layer8
They can now phish you using your Fastmail username.
throwawayfm
If "support@yourdomain.com" internally is sent to timcook@apple.com, people will know. If it's sent to nickphx+support@fastmail.com, your personal email address, name, and login are leaked.
slau
Your username is not a secure part of the authentication process. In most companies, people’s username is easily guessable, or even public information.

I feel you’re making a very massive issue out of something that is… not?

Yes, sharing the full headers of your emails will reveal some information, potentially even personally identifiable information.

k_roy
I think you are missing the point by a mile.

Their whole spiel is about "privacy first". https://www.fastmail.com/privacy-first-company

I don't even use my @fastmail.com address. I have like 6 domains that I use for various things, and a single domain for one-time/throwaway/order emails via 1Password integration.

I just verified every time I send an email, my main @fastmail account is attached in every email.

I don't care about people knowing my email, but security isn't the point or even the concern.

If I'm using an alias, I don't want account A associated to account B, especially for a service I'm paying for to keep my email out of the hands of Google.

slau
I was mainly responding to OP’s claim that this is “a security leak”. Likewise, from OP, I mainly understood that this was only an issue when giving a third party the headers of emails you have received.

However, you (and other commenters) appear to be indicating it’s also in the headers of all sent emails?

I’ve been using Fastmail for nigh on a decade, however if this turns out to be true, I may accelerate my migration towards Migadu.

reilly3000
Migadu and don’t look back
k_roy
This is a bit of an interesting take from: https://www.migadu.com/procon/

"We could enable 2FA on the webmail, but IMAP/POP/SMTP accesses remain unprotected which beats the purpose. We are working on solution here which will allow sand-boxing a username/password pair to a webmail use only."

That's an incredibly misguided sentiment

dejan
Why?
k_roy
Because it's the difference between someone gaining access to a single mailbox versus the whole config.
dejan
I think you're reading that wrong. It's an issue with the protocol. IMAP/SMTP as implemented in most clients do not support 2FA. You can add 2FA on your own on the webmail, but you could still circumvent it by using the protocol directly. It's not a Migadu-specific thing.
[deleted]
(comment deleted)
wrboyce
How did you verify this? That isn’t the issue being reported, the header is attached to your inbound mail.
throwawayfm
It is. I'm using custom domains, but my username email is private and NEVER used or known.
rlpb
> ...but my username email is private and NEVER used or known.

This feels like an architectural flaw to me. If it's supposed to be private, then why is it available to send to on the public Internet, in a way that you are now therefore sensitive about?

throwawayfm
That's the whole issue.. I don't use that email address for email, and I don't want it leaked.
poyu
I’d agree this kinda defeats the purpose of using custom domains and aliases. Because ideally no one should be able to get to your original Fastmail account. I saw this too while snooping around in the headers, not sure what to think of it but it’d be great if this is completely hidden from outgoing emails.

Just to clarify, in Fastmail, you have the option to add alias email addresses to your Fastmail account. It's like in Gmail where you can add a "+" or "." after your primary email's local part, and it will still get delivered to your original Gmail inbox. This is like that but you can assign any addresses to forward to your original Fastmail account. They even advertise this as a privacy feature[0] (though I'm not sure if they have different treatment than Aliases[1])

What OP was saying is that Fastmail internally adds an email header that reveals your original Fastmail account during a process to route your emails. This header will be presented if you then reply to an incoming email sent to an alias or masked address, thus leaking your original email to the receiver.

[0]: https://www.fastmail.help/hc/en-us/articles/4406536368911-Ma...

[1]: https://www.fastmail.help/hc/en-us/articles/360060591073-How...

brongondwana
Your comment here is factually incorrect - the "X-Resolved-To" will not be present anywhere in the email if you Reply, or with a regular Forward.

It will only be present if you "Forward as Attachment" an email which was sent to your alias or masked address, which adds the raw MIME message as an attachment - including all headers.

(the OP did get this correct)

poyu
I just checked, and you’re right. Thanks for pointing this out!
Wool2662
I can only recommend addy.io (formerly annonaddy.com) I have been using it for years for aliases and it just works, is opensource and can even be self hosted if so inclined. For like 10 dollars a year you can use a custom domain, which is absolutely worth it.
apeters
Signatures are still valid when removing X headers. They would need to be explicitly signed; they aren’t.

I don’t think that’s an issue really. Perhaps you are putting too many emotions into it because they turned you down? It’s not as big as you think it is imo.

Good to know anyway.

throwawayfm
I didn't know about the headers. No, I'm not emotional because they turned me down. I just don't like leaking this information at a certain point.

It's something they can and should fix.

LinuxBender
Unfortunately there is currently no way to remove the X-Resolved-to header

It sounds like the wrong people are looking into this. Most MTA's have a way to drop a header. To your point this is something they could/should do on their outbound MTA's. In Postfix this would be done in /etc/postfix/header_checks and might look something like

    /^X-Resolved-to:.*/         IGNORE
All outbound email servers sending to the general internet should absolutely drop all headers that contain internal routing and infrastructure information. If it's important for auditing or debugging it can simply be logged in syslog, ELK or whatever logging mechanism of their choice is preferred. If their outbound servers do not support this then this should be a feature request. Postfix also has content filters but I like the flexibility of header and body checks.

    # Log to syslog
    /^X-Resolved-to:.*/         WARN

    # then drop
    /^X-Resolved-to:.*/         IGNORE