Steffen Nurpmeso wrote in <20240119235632.VOlkKoIX@steffen%sdaoden.eu>: |Dave Crocker wrote in | <54bcc79e-2cec-4c49-8a5c-0ef64db68...@dcrocker.net>: ||On 1/19/2024 6:51 AM, Al Iverson wrote: ... ||[.]does not have a know ||solution. | |There would be a RFC 6376 backward compatible "solution" with |per-receiver-domain DKIM-Subsignature that fixates the SMTP |recipients for a particular address. | |Ie include a flag in the DKIM signature that signals this new |methodology, and instead of transferring one email to all |receiving domains, send per-receiver-domain instances that contain |a DKIM-Subsignature header field that includes envelope receivers |especially for this receiver domain. | |Then an upgraded DKIM verifier on the receiver side could, |announced by the flag in the DKIM signature, ensure that only |those receivers which are included in the DKIM-Subsignature are |actually addressed, and any bad actor that tries to replay the |message can be detected since it does not include the |DKIM-Subsignature that verifies against the DKIM key of the |original sender.
I am not truly the right person to write a draft, because of my english and my problems to stick within a fixed scaffolding. Also the "idea" i hm developed did not had any feedback, except by Jesse Thompson, who gave a very good suggestion; .. which is ok, but i personally do not feel very confident to create a standard without feedback from people which drive software which would need to be adopted to comply. Especially, and mostly, actually, the forking of the message is something that does not happen today. In order to send per-receiver-domain message copies, a milter must adjust the return list to one receiver domain, and, as necessary, recreate the message to send it to the remaining receiver-domains; these copies then, well, either have to undergo "the same procedure", *again*, or require a special M[TS]A entry point that is fed with ready-to-takeoff message copies. All this is doable, but it is, as far as i know, not done today. How can i -- and that is especially i, who never wrote an IETF draft -- create a standard draft that requires such a new or modified processing pipeline, without any feedback; no improvements, no disagreements, no agreements. That is not much. Also i have very few spare time, i do not get paid for this either, and diving into writing a draft requires time. Maybe even weeks. Having said all that, maybe in Spring i could find some cycles to look into the IETF scaffolding framework. But like i said last year, i do not need to see my name on some standard document (even in the THANKS apartment i feel uncomfortable), i would prefer to write software in the little time i have. But i mean i could also simply take an existing draft, and place in there the few paragraphs that are necessary to describe the idea: it is not much, actually. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
