Kurt Hackenberg wrote in <zinqav87xkbv7...@rain.cave>: |On Fri, Apr 19, 2024 at 03:41:40PM -0400, Derek Martin wrote: |>On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote: |>> It's odd to me that, since OpenPGP and S/MIME both support MIME |>> encapsulation that the draft standard wouldn't use a separate MIME part |>> to handle the protected headers vs. stuffing it at the top of the |>> message body, which just seems kind of kludgy at best. |> |>This also seems like a perfectly cromulent approach, and again better |>than the proposed one which puts nonstandard headers in a place where |>no standard says they can be. [Or perhaps the correct wording would |>be, "...which nonstandardly puts standard headers in a place where no |>standard says they should be."] | |Are you both thinking of defining a new MIME type to hold only the |protected headers? I thought of that. It seems cleaner...I see no |mention of that in the draft we're talking about, not even to reject |it. I suppose old mail readers wouldn't know what to do with that new |body part. They might display it if it's a subtype of text. | |Turns out an earlier way to protect headers was added in S/MIME 3.1. |It puts the whole message, including the header section, in a body part |of type message/rfc822, and wraps a crypto body part around that. So |the message contains a copy of itself, sort of.
There is also draft-melnikov-smime-header-signing(-02 i have) on top of this. |The draft calls that mechanism "wrapped". The draft wants to replace |that with this header-stuffing thing because "legacy" mail readers are |sometimes confused by the wrapped message. The draft says |header-stuffing is less likely to confuse mail readers that never heard |of either scheme. Regarding the topic itself, i see those h"eaders duplicated into the signature-protected MIME header"s more and more often, it seems some mailers can this produce regulary for some time. The MUA i maintain needs at least two more years to get there, but all in all i would wish that this mechanism of header duplication would become a RFC by itself, maybe someone should talk with Daniel Kahn Gillmor, i think it was, to split that part out. (I have not kept the draft locally after reading it.) |>MIME header blocks are for MIME-specific metadata; even if no mail |>clients actually break due to this, it still feels gross. | |Agreed. I do not, actually. Especially since it already is actively used. The question always is "how do receivers act upon this", of course, and this especially means the graphical, even browser-based monsters which users cannot configure, more, which have uneducated -- or better say "unaware" -- user bases. Those clients, and i do not even know how well GMail or Outlook (or Apple Mail) can deal with S/MIME or PGP signed or even encrypted (hmm..) email, would have to take and treat the secured headers as the real ones. But, quite the opposite, you hear statements of participants on user complaints like "i cannot [click-]open your attachment" and such for PGP etc detached signatures etc etc etc. (You also hear "please use > for quoting, my mailer does not understand your |", even though the leading whitespace was the very first quotation method ever used (in a RFC), and is still standardized in POSIX .. whatever.) |I would like to hold off on this until the draft becomes an RFC, if \ |it does. --End of <zinqav87xkbv7...@rain.cave> --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)
