Hacker News Reader

Comment by moedersmooiste | Hacker News Reader

Also went looking for an alternative and moved everyting to mailbox.org...

Be aware that Mailbox.org allows any user to send emails as ("from") any other user via SMTP and these emails will look legit since they pass SPF and DKIM checks. Many consider this a security issue.

There was a quite lengthy discussion about this in their forum but they deleted it since. They refused to fix it. Archive.org still has it. Content is in German (sorry):

https://web.archive.org/web/20210123192856/https://userforum...

I did not know this, I moved to mailbox.org in December.

Surely they'll only allow that if they pass the auth and the domain belongs to your account?

No, they don't do that check, that is the problem.

I don’t think they can implement such a check without breaking changes.

And that's why we shouldn't fix bugs anymore? https://xkcd.com/1172/

Fixing this would only affect users who send emails "from" other users email addresses, basically users who commit fraud.

Oh wow, do you perhaps have more details on the current situation? The CEO’s response is from 4 years ago.

I also don’t fully understand the reasoning. Having an open SMTP server that doesn’t restrict senders is one thing, but attaching DKIM without further checks is another.

AFAIK they still refuse to acknowledge the problem. But since they deleted the forum thread, how would I know.

What they said in the forum doesn't make much sense. Yes, anyone in the wold can send emails with any address as "from". The big difference is that those emails won't pass SPF and DMARC checks.

If I wanted to use them, I would need to configure SPF and DMARC for my domain so that their mail servers pass those checks. At this point I would expect their mail servers only to allow sending "from" my domain when my account is used.

Note that just about any major mail provider does this check (e.g. Google). It is industry standard. It is crazy that they even refuse to acknowledge this. I'm working in this field and this is basic knowledge. I just don't get how they can do this professionally and not understand what the problem is. The only explanation I have is that for some reason it would be hard for them to fix and so they try to ignore it / make it disappear by deleting the forum thread.

Also they use the same DMARC key for all customers, which is weird. Usually each customer gets it's own DMARC key.

I assume you mean DKIM where you wrote DMARC. A DMARC check results in a pass when at least one of SPF or DKIM is aligned, i.e. SPF alignment alone is enough. Which makes this situation even worse because a custom domain user of mailbox.org obviously will have mailbox.org’s SMTP server in the SPF record.

It seems this issue was acknowledged 2 years ago: https://userforum-en.mailbox.org/topic/anti-spoofing-for-cus...

Edit: re the shared keys you mentioned I agree. If they had per-user DKIM keys that were only usable after successful SMTP authentication (e.g. by encrypting them with credentials) that would solve the DKIM part of the issue AND even further improve the situation.

Anyone willing to spin up a mail server can do this. DKIM and SPF are only intended to establish the identity of the server. I don't know that there is any obligation on the part of someone running a mail server to police the "From:" address on an email in some specific way. Traditionally the "From:" address was considered informational. It generally represents the address that the sender considers "their" email address. A actual user identity is established by signing the email and is separate from the "From:" address.

Does mailbox.org even include the "From:" address in the DKIM signature?

Seems like it, I just sent an e-mail with it and it resulted in

  h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
    to:to:cc:mime-version:mime-version:content-type:content-type;

> Does mailbox.org even include the "From:" address in the DKIM signature?

According to the spec, the “From:” field must be included in every DKIM signature.

https://datatracker.ietf.org/doc/html/rfc6376#section-5.4

If you’re using DMARC the from and the DKIM signature must be aligned or it doesn’t pass. Simply passing any DKIM check isn’t enough.

Mailbox.org has a DMARC policy of "reject". So receivers that enforced DMARC and did "domain alignment" would reject the email. Does that make what mailbox.org does with the "From:" address OK?

Not if they are still signing it with the private key for the domain.

If an email is sent with a From of @bob.com and DKIM signed using the private key for bob.com…it’s from bob.com.

As others said, DKIM always includes "from". And almost none of the emails I get are S/MIME or PGP signed.

Like you said: SPF and DMARC only authenticate the server. It's up to the server to authenticate the user.

Scenario: imagine your bank uses Mailbox.org to send emails. How would you verify that an email is legit? Any Mailbox user can send emails through Mailbox with your bank as "from" and all of these emails pass SPF and DKIM checks. Your mail server has no way to distinct a legit email from a fake one. This is why it's important that the server does this check (check that sender account and "from" match / are a valid combination).

Anyone that runs a mail server can generate emails with any "From:" address they want with a valid DKIM. The SPF works on the envelope address, not the "From:" address.

The actual complaint here is that mailbox.org is not policing the "From:" address and thus are providing such an ability to people that have not bothered to spin up a mail server on a domain they control.

Yeah, banks should sign their emails. I think that even Facebook does this if you give them a public key.

I’m sorry I don’t get the part about DKIM. I thought the DKIM signature would only be valid if the signing SMTP server has access to the private key matching the Header-From’s domain’s designated DKIM public key.

E: by valid I meant valid and aligned (according to DMARC), sorry

A sender can throw anything they want in the "From:" field and then sign it. The receiver does not have to agree. What would happen is that the receiver would see that the holder of the domain was different than the domain in the "From:" address and on the basis of bad "domain alignment" could reject the email.

I now think that the DMARC stuff is a red herring and would actually help make the current mailbox.org behaviour not all that problematic (they specify "reject" in their DMARC policy). The actual point of dispute is the lack of enforcement of the "From:" address domain.

Yes, lack of enforcement by mailbox.org on the Header-From when signing DKIM is the problem for DMARC IMO. It means I can’t trust a DMARC pass due to aligned DKIM.

Mailbox.org’s servers have access to 4 private keys as far as I know. These (I mean the matching public keys) are stated in mailbox.org’s DNS records. If you send from an @mailbox.org address you trust mailbox.org to do checking on the Header-From when signing it, as you have no control over which keys you state in DNS. This is the same situation as for any mail provider with a shared domain.

What’s even worse, when using mailbox.org with a custom domain they will have you state the exact same 4 keys in your domain’s DNS records for DKIM to work. There is no way to upload custom keys. So even someone with a custom domain has to trust mailbox.org to not sign strangers’ e-mails.

The DKIM key is in your DNS. Does mailbox.org provide a DNS service and somehow enforce what you put in there?

Added: Wait, how would that even work? You need to generate your own DKIM key.

No one is forcing me, but not using it would mean I can’t have DKIM signatures, wouldn’t it? As far as I know there are no mail clients that add the signature before sending it to the MSA, but I might be wrong.

Re the addendum: No, mailbox.org does not support own keys.

But since DMARC will also give a passing result with aligned SPF, the Header-From checker has not only to refer from adding a DKIM signature but actually reject the e-mail completely for DMARC to be reliable.

That’s a huge security issue! Geez.

If anybody realizes you’re using that service they can immediately impersonate you.

The email standards explicitly allow everyone to impersonate anyone. That’s why you should use S/MIME and PGP.

If you’re using DKIM to sign the outgoing message it’s a huge flaw if your service provider is signing other peoples emails with your key just because they included the domain. You authenticate to the server for a reason.

That's not true. SPF and DKIM were explicitly made to prevent email forging by authenticating the server, and the server is responsible for authenticating the user.

Please name even a single major mail provider that allows to send emails with arbitrary "from" headers.

https://datatracker.ietf.org/doc/html/rfc7208 https://datatracker.ietf.org/doc/html/rfc7489

I thought about how I would fix that retaining the catch-all feature they have. You can get mail from all non assigned names on your domain on the catch-all assigned account, if you enable that. You should also expect to be able to write from any of those non assigned names with this account. If your account is the only one connected to that domain, everything is ok. But if you let's say have 100 users-accounts on this domain, you could build a blacklist for the names that are assigned to other accounts (which would be cached, therefore could have delay), accept that the admin can impersonate all their users or lookup every assigned domain on each send. Am I missing something obvious?

I like them as well, especially their catch-all feature. But they increased prices for their cheapest custom domain plan from 1 to 3 euros per moth not so long ago. While I’m still grandfathered in, it doesn’t feel good. I know it’s not too much in absolute terms but the relative increase is steep.

I'll second that. It's the best choice if you want an EU-based company.

Reply on news.ycombinator.com