IDK if you already do this, but one way to help mitigate the “a MitM messing with the key headers” is if there happens to be DKIM, in which case you can check it 
(I guess you can tell that I’m starting to learn a tiny and dangerous amount about email and about security and is being an obnoxious armchair cook but I can’t not send it, juuuuust in case there’s a good idea that you’ve missed.)
we are already working on it, it’s a problem we identified during our automated email address porting project, but it is harder than one might think, also because it depends heavily on the providers to implement it (we don’t have the resources to implement it client-side right now and we don’t even know if it’s possible at all client side, because provider could (and do) change their keys regularly).
I think DKIM is implemented at DNS/SMTP level and there is no need to add something in Delta chat. The message delivery is done by mail servers and they work according to configuration (including DKIM).
Someone can MitM between your own server and you, which a Delta Chat–side DKIM-awareness could stop. Not for every message but for situations where they’re like “uh I lost my key this is a new phone please resend”
It is best to use DC with a chatmail server. These support DKIM. Many major email providers now do this as well.
Chatmail servers support and require DKIM. See also recent discussion on GitHub:
Delta Chat as an email client does not know anything about DKIM and is not going to check DKIM signatures directly as it requires querying DNS records and we try to avoid any connections other than configured IMAP and SMTP server. DKIM is also not designed for being checked by the client because by the time user comes online DKIM signature of old delivered message may become invalid due to key rotation. RFC 6376 explicitly says that “message archiving is not a design goal”.
Delta Chat however does not depend on the server supporting DKIM. It’s nice to have some authentication for the From: field and not allow anyone to put fake messages into your 1:1 chats because this will make the chat unusable, but this is not going to trick you into chatting with someone else, especially if you get a green checkmark on a chat with “setup contact” protocol.
Does Delta Chat check the Authentication-Results header of the server and whether that contains an SPF fail or DKIM fail from the SMTP? E.g. it could display a warning if the Authentication-Results header doesn’t contain a DKIM pass, or if no DKIM was found at all.
The checkmark verification doesn’t really seem to cover the real world use case of “does this e-mail even come from that account it claims to be from”.
We tried to parse Authentication-Results in the past, but dropped this idea because it is impossible to know if the server adds Authentication-Results or if this header was received together with an incoming message. I think Authentication-Results is only useful for passing the results between filters within a single server, e.g. by removing all Authentication-Results headers, then adding SPF and DKIM results, then passing them to DMARC filter or something like that.
Protecting against From: spoofing is what the server should do. If email server does not protect against email address spoofing, the best thing to do is to switch to another server.
Don’t most e-mail servers not protect against that because it breaks mailing lists?
because it is impossible to know if the server adds
Authentication-Results
You could make it an option at least, for SMTP servers that always add it.
Mailing lists that don’t modify the mails do not break DKIM, so emails authenticate successfully. The other option mailing lists have if they do modify the mails is to rewrite the From: header with the mailing list address. In both cases emails will authenticate successfully.
If mailing lists don’t rewrite the From: header, they don’t need to add their own DKIM signature. They just need to forward the mail as is, including the original DKIM signature from the sender. If the sender does not sign messages with DKIM, then there is no way to authenticate forwarded message and it should be rejected.
Sadly, this isn’t how mailing lists often behave, so many people will be forced to use hosters allowing invalid DKIM. But there’s usually “Authentication-Results” which Delta Chat could check.
because it is impossible to know if the server adds Authentication-Results
You could make it an option at least, for SMTP servers that always add it.
Just as an additional note, if you fail on either any “Authentication-Results” header found that isn’t dkim=pass or a missing DKIM signature, I think it would be safe from any outside meddling for most mail servers. And for the remaining ones that never add this header, you wouldn’t degrade security, if I’m not mistaken, since any spoofed e-mail would otherwise have been quietly accepted anyway.
Does that make any sense? Sorry if some of the above is incorrect, I’m not an expert.