It appears that Metin Savignano <[email protected]> said: >Thank you for your replies and suggestions. Let me reply one by one.
tl;dr I think we understand what you want to do, and DKIM2 can't do it. >> Surely you'd just wrap the entire DKIM2-signed email with encryption? If >> not, then you're either creating a brand new email and your >gateway is implicitly trusted, so NULL recipe or just an >Authentication-Results header and no DKIM2 at all. > >Not sure if I understand what you mean by „entire mail“. When encrypting, most >headers and the message body gets encrypted, and >that block replaces the message body while most headers are left intact (like >From and To). There are slight variations of that >approach, but most of the time, that’s how it works. That is indeed the traditional approach but it's pretty lame since it exposes all the metadata in the headers. S/MIME lets you put the entire meessage in a message/rfc822 MIME part, encrypt that, and send it along with dummy headers, so the real message gets unwrapped by the recipient. See RFC 8551 sec 3.1. You might as well do that, see below. >And yes, if the backend mailserver is configured to always trust the gateway, >we have no problem. However, with DKIM2, as I understand >it, the gateway can achieve trust through its DKIM signature, which is an >advantage because it would not require a specific >configuration of the backend mailserver. > >Now my questions is, with a null recipe, the receiving server can no longer >verify the original content (and there is no way around >this, because everything else would render encryption useless), so how is this >situation conceptually coped with? You can't. The whole point of DKIM2 is to let you look back through all of the message modifications. We have a somewhat similar situation with Proofpoint-style security gateways which rewrite URLs and remove message parts. They do not want the recipient to be able to see the previous version of the message other than via what the rewritten URLs provide. They're why we have null recipes. >The only way out of this dilemma would be to have the receiving email client >check the DKIM of the original message after it has >decrypted the message. However, DKIM is supposed to be implemented by the >server, right? Yup, and that's where useful spam filtering happens, too, which is a problem if you don't trust your mail operator as you often don't. So as I said, unless you have an existing relationship with the recipient server, your best hope is to send mail that looks squeaky clean to the server, fully authenticated and provoking very few user complaints. Since you are not the originating system, you can't apply a DKIM signature that aligns with the original From: header so you can't get DMARC alignment that way. But you can put your own From: on a wrapped message with your own domain and add a signature that aligns with that. While the DKIM2 angle is new, none of the other issues are and it would be a good idea to see what other people have done. I'd suggest talking to Daniel Kahn Gillmor <[email protected]> who's active in the IETF and has done more thinking about this than anyone else I know. R's, John _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
