Messages to nine.testrun.org are rejected with valid SPF

[ell1e]

Messages to nine.testrun.org appear to be rejected even with valid SPF:

Final-Recipient: rfc822; [[email protected]](mailto:[email protected])
Original-Recipient: [rfc822;[email protected]](mailto:rfc822;[email protected])
Action: failed
Status: 5.7.1
Remote-MTA: dns; nine.testrun.org
Diagnostic-Code: smtp; 554 5.7.1 No valid DKIM signature found

This seems like a problem, because from my experience no major provider including even the occasionally picky GMail require DKIM but only either DKIM or SPF as far as I know. Therefore, people will be unable to use DeltaChat when normally, their e-mail would work fine in that situation. Since SPF seems like it would likely suffice unless there's a man-in-the-middle at the ISP level, at which point PGP seems like the better defense than DKIM, I'm personally also confused why this requirement has much benefit on a technical level (but don't trust me on this, just my two cents).

• Operating System (Linux/Mac/Windows/iOS/Android):

• Delta Chat Version: Desktop v1.46.8 Core v1.142.12 SQLite 3.45.3 electron 30.3.1 node 20.15.1

• Expected behavior: e-mail is accepted when SPF is valid, even when there's no DKIM.

• Actual behavior: e-mails are rejected even with valid SPF

• Steps to reproduce the problem: use an e-mail server that uses SPF but not DKIM

• Screenshots:
  

• Logs:

[missytake]

First of all, that DKIM signatures are required is the expected behavior for chatmail servers (like nine.testrun.org), see https://github.com/deltachat/chatmail?tab=readme-ov-file#email-authentication

I don't remember 100% what the arguments were, just that your arguments were considered as well. In general, the discussion was centered around "let's make From forgery as hard as possible, even if it breaks compatibility with some classic email servers". The priority use case of chatmail servers is chatting, not email; and users expect from chatting that they can rely on the other side being who they claim to be, and senders can not simply forge the From header. Whether this is enforced or not is not dependent on DKIM of course, not even on SPF or DMARC; but it's the best indicator we have, and it's a necessary premise that at least the domain part of the From header is correct, even if the localpart/username is not enforced to belong to an authenticated account.

The email ecosystem has tried to fight From forgery for decades with SPF, DKIM, and DMARC, to limited success. The result is that many DMARC policies have p=none, SPF softfail policies, and don't really give us the guarantee we'd like to see. DKIM is the mechanism which is closest to what we want; if there is a valid DKIM signature, we can be sure that the server which sent is allowed to send emails for this domain.

(In the beginning we experimented with other policies around DMARC, but we quickly realized that if DKIM is correct we can ignore what SPF says, and if DKIM is missing we can not rely on SPF. The only thing DKIM was missing that DMARC provided was the adkim parameter which checks whether the From domain == the DKIM signature, and we simply require this in an additional step, instead of relying on DMARC, which can also specify to ignore whether From domain and DKIM signature match.)

Yes, this breaks interoperability with some other email servers, but then again this interoperability is already limited, as chatmail accounts can not send out unencrypted emails for example. Compared to that, DKIM is set up automatically for chatmail servers, and usually just works out of the box. Our hope is that this motivates admins to add proper DKIM setups; we can allow ourselves to make this hard requirement, because 100% interoperability with email is not expected from chatmail anyway.

Adding DKIM is not super hard, and I can recommend https://www.learndmarc.com/ as a test site which does a great job at both explaining the concepts around DMARC and helping admins to configure their server correctly. Then again I have to admit I also co-manage a server which does not DKIM-sign^^ If you manage the server in the issue, and need help with setting it up, drop me an email at [email protected] :) it might take some days for me to respond, but I'd be happy to help.

[ell1e]

I do manage the mail server, but I still don't quite see the point. Why not use SPF hard fail and PGP instead? SPF hard fail seems to be the standard by now for many providers, I don't see many soft failing on this these days. I didn't setup DKIM because every extra option risks maintenance trouble down the line, and it's simply not required in practice for any normal use of e-mail that I've encountered so far (while SPF is). Based on this, I think making DKIM a hard fail is a bit strange in a system that uses PGP anyway, unless your plan is to have two separate worlds of people using chatmail that can chat to each other, and the others "outside", with no interoperability.

[link2xt]

Primary reason chatmail servers don't support SPF is avoiding complexity. chatmail only runs OpenDKIM and does not make complex decisions combining the results of various authentication mechanisms. Other email servers allow either SPF or DKIM because they run a spam filter such as rspamd that does this by default.

Since SPF seems like it would likely suffice unless there's a man-in-the-middle at the ISP level,

SPF by itself is insecure because it verifies HELO identity of the server which is not part of the message and is not available for the IMAP client. It is trivial to bypass existing SPF implementations such as OpenSPF and spf-milter by specifying the domain you own in the HELO command and then forging the From: header that is not checked by SPF.

DMARC solves this by requiring "identity alignment", i.e. that HELO identity that is verified by SPF is the same (in case of strict identifier alignment) as the From header. So one way to support servers using SPF would be to require that DMARC produces a "pass" result (and not just no "fail" result, because for gmail.com, outlook.com, fastmail.com and many other providers that specify p=none policy in their _dmarc TXT record anyone can easily make DMARC produce no result). This however increases complexity a lot as we would either have to use unmaintained OpenDMARC or much more complex rspamd or implement our own software on top of SPF and DKIM validators.

at which point PGP seems like the better defense than DKIM, I'm personally also confused why this requirement has much benefit on a technical level (but don't trust me on this, just my two cents).

OpenPGP does not have inherent mechanisms to verify that the key belongs to the email address or a domain. This would require depending on public key infrastructure such as trusted keyservers that associate addresses to keys. Delta Chat does not use keyservers and we want to avoid chatmail servers having to deal with user keys or even have access to them.

---

SPF has other problems such as not working with mailing lists. If you don't implement DKIM signing, users of your mail server cannot send messages to mailing lists because relaying breaks SPF authentication unless you essentially allow the mailing list server to send messages in your name by listing its IP address in the SPF record.

Required DKIM authentication also allow to put a DNAT or reverse proxy in front of the chatmail server port 25. You can even expose port 25 of chatmail server to the Tor network and allow delivering mail to chatmail over Tor or any other proxy if connecting to the chatmail server directly is not possible, achieving result similar to using onionmx.

We might later want to adapt chatmail for scenarios of long term DNS failures and cache DKIM keys. DKIM keys are associated to the "selector" and can essentially be cached indefinitely because you are supposed to create a new selector (could be a timestamp) if you rotate DKIM keys. Caching SPF policy in a similar way is not possible.

Having to indefinitely support legacy SPF mechanism for email authentication is similar to supporting remote shell protected by TCP wrappers instead of migrating to SSH. It is less secure and prevents all the possibilities that result from not depending on having a fixed IP address for the sender side.

Since every email server need to have a DKIM verification support anyway to support relayed (over mailing lists or otherwise) messages, it should be as well possible to run a DKIM signing software there. Whether you have OpenDKIM or rspamd, enabling DKIM signing is a matter of configuring already installed software.

[link2xt]

I would close the issue as "not planned" because it is very unlikely that anyone will work on supporting SPF, but feel free to continue the discussion here. Everyone in the chatmail project or subscribed to this issue will receive notifications in any case.

[ell1e]

Nothing you do seems like it would work well to assume safely the OpenPGP key is actually a valid one for that user. If you wanted to improve that, I think it might be a good idea to show the key id here:

And to allow accessing a recently used OpenPGP list for a user here:

And to show a big visible warning if the OpenPGP key for a message from a user differs from the key used for the previous message from that user, if you're not doing that already.

As for SPF, you could if you wanted just check the SPF entry for the FROM address host as well in case DKIM isn't available. I realize that's not the spec, but you'd only be allowing more mails to pass through, not less. Thanks to envelopes, I don't think it breaks any properly configured mailing lists. I've not seen that happen, at least.

The complexity argument you mention sadly also applies on the sender side, e.g. DKIM is very complex to set up for me and in my opinion doesn't help with making OpenPGP much better, so I don't bother. I can't imagine I'm the only one.

[ell1e]

For what it's worth, I'm not really asking that you check SPF but rather that you don't enforce DKIM. However, I realize in practice that might be the same, since it seems like many big providers want either SPF or DKIM to be present and working which seems like a reasonable baseline.

[link2xt]

We avoid talking about the keys or key IDs in Delta Chat user interface, let alone that users will compare raw key fingerprints. We already show an info message when Autocrypt key changes and show a really big warning if user has previously set up a contact by scanning an invite QR code: https://delta.chat/en/2023-11-23-jumbo-42
We don't expect users to know about key fingerprints and understanding the details of having an identity key and encryption key in OpenPGP.

[ell1e]

Why not allow seeing that information with an advanced mode? And the info on key change sounds good, although I wonder if it also should be a warning unless the new key is signed by the old key. Does Delta Chat check that?

You may also want to consider something like threema, where any new user defaults to some "Yellow"/medium trust level and has a short fingerprint shown (which would be based on the OpenPGP key) and then needs to be manually marked "Green"/high trust by the user if marked as trusted. And whenever the key changes, it could go to "Red"/low trust.

All of those approaches sound more useful than DKIM blocks: I believe not even matrix which I would think is in many ways more paranoid than Delta Chat, downright rejects messages with invalid signatures or invalid sources. But this is what chatmail is effectively doing if no DKIM means block, rather than e.g. showing a warning but letting the message pass. I get the desire to verify the sender though, so I understand it on some level, but the average custom email account user won't have this level of verification either so I'm not sure if for the ecosystem as a whole this fits in well as it is now. So wouldn't the client need to assume DKIM was probably not checked?

Sorry if I'm missing some angles here, I'm not really an expert on any of this, I'm just trying to give some ideas.

[link2xt]

Why not allow seeing that information with an advanced mode?

It is not easily discoverable, but you can right-click on the chat and select "Encryption Info" option. It displays key fingerprints of all the chat members. A bit unreadable but I guess nobody discovered the bug because the feature is rarely used: deltachat/deltachat-desktop#4160

[ell1e]

Ah, very cool, thanks for the info! That's super useful, I like to verify and compare the keys in real life sometimes. Although I realize it'll go past most average users, which I agree is an issue.

[link2xt]

You may also want to consider something like threema, where any new user defaults to some "Yellow"/medium trust level and has a short fingerprint shown (which would be based on the OpenPGP key) and then needs to be manually marked "Green"/high trust by the user if marked as trusted. And whenever the key changes, it could go to "Red"/low trust.

We have some plans regarding improving the "verification" aspect e.g. at deltachat/deltachat-core-rust#5126, but adding more "web of trust" features and expecting users to assign trust levels to contacts based on manual fingerprint verification is not general direction I'd say.

[ell1e]

I did just make a UI proposal for better verification here, for what it's worth: https://support.delta.chat/t/feature-suggestion-manual-fingerprint-verification-securejoin-alternative-for-desktop-users/3276

I think focusing purely on QR codes isn't ideal, since some users don't use devices that can handle these. DKIM doesn't really solve that either, but it seems relevant to this discussion of general sender trust.

Edit: Delta Chat seems to have a really great UI though, in general. Congratz on that. I'm just trying to give some ideas here, since we're on the topic, which I hope will be useful for this cool chat client. Good work, it's a really promising project and it's great that it exists.

[link2xt]

DKIM is definitely not about verifying the user identity. We want user identity to be primarily associated with OpenPGP identity key and not with the email address. For chatmail accounts we even show the email address in less places as it is usually a random meaningless string anyway.

So wouldn't the client need to assume DKIM was probably not checked?

We don't depend on the From: forgery protection for identity verification etc., but just dropping any verification of the address on chatmail is not an option as it would allow very easily annoying users by sending the messages with the address of their other contacts in the From:, injecting invalid messages into their 1:1 chats that trigger huge key change warnings. This may happen with other email servers that don't do From: authentication, but then users can move to a server that has the checks, e.g. any chatmail server.

[ell1e]

Yeah that makes sense. I'll see if I can get DKIM to work, for what it's worth. But I'm hoping SPF as an alternative will at least remain a consideration, if only for access for others with their own email. The other person I know that runs their own email also hasn't DKIM enabled, so it seems like it's not the most popular among self-hosters.

[link2xt]

One more note in favor of DKIM: strict DKIM checks effectively prevents SMTP Smuggling as even if you can split the mail into two mails with this sort of bugs, both of them will have invalid DKIM signature and get rejected.

[ell1e]

It's not necessarily a bad idea. But since the client can use whatever e-mail address and "normal" e-mail addresses usually don't require DKIM on all incoming mail since that's not practical, Delta Chat probably shouldn't be designed to rely on this behavior of the SMTP server. But then I wonder why require it. As somebody suggested on the forum, one way to make this more consistent would be if Delta Chat was changed to actually check DKIM inside the chat client.

[ell1e]

After some poking around more, I think rejecting messages without DKIM is actually possibly a good idea. However, I think Delta Chat should also show DKIM status on the SMTP server's Authentication-Results header, including both if DKIM failed or is missing.