Thank you for your replies and suggestions. Let me reply one by one. > 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. Looking from the outside, headers are left intact (except for Content-Type), but the message body gets replaced. So is this a brand new email? Yes and no, depending on how you look at it. 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? I would expect, breaking the verification chain means breaking the trust? 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? > Or if you're outbound, then you can sign as the sending domain and you just > start from scratch with DKIM2 - the fact that it was signed coming to you is > just your choice for authentication, you could also have it come in via > SMTP-SUBMISSION or whatever works for your environment. Right, outbound is not a problem. > DKIM2 doesn't care about the bits where either the start or finish of your > mail flow is same or related organisation, because you can verify the message > flow out-of-band. > > And you can't be an encryption gateway in the middle of a mail flow between > unrelated parties. What even is that. If you don't have a relationship with > either the sender or the recipient, then who verifies the legitimacy of the > keys you're using? Why shouldn’t that be so? After all, it’s more or less like just another MTA hop. So works the same by publishing the DKIM key in the DNS records. Or am I misunderstanding your point? > But you can't do useful spam filtering without looking inside the message, so > the only plausible approach is what Bron said, use the encrypted message as a > tunnel and the recipient checks the DKIM2 chain after it unwraps it. And you > better do some heavy filtering before you encrypt and relay or nobody's going > to > be willing to unwrap it. That’s correct, spam detection needs to be done before the encryption. However, the filtering in terms of moving the spam message to a quarantine or spam folder needs to be done by the backend mailserver. So perhaps the conclusion is that the backend mailserver needs to trust our mail filtering and DIM verification anyways. Back to the subject, I’d suggest that the RFC sheds some light on how null recipes are supposed to be processed. I struggle to understand this text If it is impossible to regenerate the body of the message, because it was changed on the outgoing path and a "null recipe" means that the previous version cannot be reconstructed then the body MUST be removed from the third part of the DSN and a text/rfc822-headers MIME part must be supplied. ..and the text around it. I suggest that some example would be helpful here. Also, I’m not sure if the described procedure is for forwarders only and would possibly not apply for my encryption scenario. Thanks Metin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
