[15characterslon]

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

[upofadown]

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.

[brewmarche]

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

[upofadown]

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.

[brewmarche]

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.

[upofadown]

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.

[brewmarche]

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.

[brewmarche]

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

[brewmarche]

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.