Steffen Nurpmeso wrote in <20230810223346.-xlaq%[email protected]>: ... |Murray S. Kucherawy wrote in | <CAL0qLwaLuNbwbnB4NLrMbqxP=qdisrvnxvprjf8p+dkgjtw...@mail.gmail.com>: ||On Wed, Aug 9, 2023 at 3:14 PM Steffen Nurpmeso <[email protected]> \ ||wrote: ... ||> And when a mailing-list or so changes fields, it could create ||> a "DKIM-Backup: h1=b1, h2=b2, .." where b1 could be base64 encoded ||> (gzip compressed), so that the original values could be restored. | ... ||Even if you could revert header field values to their signature-time ||content, it's what's there now that gets shown to the user. So if \ ||I have a | |DKIM is never about the user, no?
That was much too harsh, i apologise for this. |This is only meant for that reputation you all talk about. |You can climb up that ladder, and if you find someone fooling |around, you can downrate the bad guy. | ||DKIM-Backup field that lets the original DKIM-Signature validate, but the ||new Subject has a spam URL in it, then I'm using that signer's domain to ||show you content they didn't intend. || ||It's the same problem, isn't it? | |No. Yes, this is tricky, you are of course right. But different to today you _could_ verify the original message. Like in earlier times, where a letter was put in an envelope, then sealed, then put in further sealed envelopes (along its journey), you can find the original sealed letter in the innermost envelope. I think this is a value by itself, letting aside anything else. With that user interfaces _could_ be designed which give opportunities to let users decide on reputation. Like this DKIM signed messages from [email protected] that where sent from [email protected] not only validate technically, but seem to be proper from a human point of view. This is also new. It cannot be helped, never? If a mailing-list resends messages which are OpenPGP or S/MIME signed, the only sane other way would be to MIME enwrap the inner message, which then stays a constant. With the more and more common "protected headers" you even have at least three levels of headers, only the innermost of which, the protected ones, can truly be trusted to have been written by the sender. But unfortunately MIME is not the approach DKIM has taken. So isn't it unfair of yours to cite the above? On the internet history list the letter-in-letter and user interface of this came up years ago, to which you, maybe, likely, refer even. By then i think the discussion revealed that Apple Mail cannot even properly display PGP signatures, but that "there is only an icon at the bottom", or similar. So the problem you refer to seems to be a user interface problem. But, please again, with the "envisioned" approach, if [email protected] sends a DKIM "v2" message to [email protected], and that validates the message, and DKIM "v2" signs it, and sends it to me, i could then truly verify technically the original message that [email protected] wrote, which is a completely new thing. With a better interface differences could be shown. (And even if only via multiple instances, where older are style-technically made outstanding compared to the actual one.) So with that users could put reputation themselve, which is also new; add onto that "spam" button a "no-reputation" one. In the end i think user interfaces somehow have to deal with the "protected" headers of PGP and S/MIME as that get more and more common. DKIM would then be just one more addition. But the technical foundation to make this possible with DKIM would exist. Ciao from Germany! And apologies again for the rude tone. --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 [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
