Hi Derek, 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."]
How would a program differentiate between a body whose contents are header-field-like? Header fields must go in a structured area. MIME was designed precisely for that purpose: allowing header fields in the body of a message, by structuring the body to have other header areas. The only viable alternative is the patatt(5) way: using the message header, no need for MIME. However, inertia seems to be using MIME. > MIME header blocks are for MIME-specific metadata; even if no mail > clients actually break due to this, it still feels gross. Yes, the > MIME spec says other fields can appear there and should be ignored (so > long as they don't start with "content-") but having standard message > headers in multiple places unexpectedly still runs the risk that > insufficiently carefully implemented clients will get confused. mutt(1) has been doing it since 2018. That's not like 1970, but it's already a decent time frame that other projects can do the same thing. Moreover, Memory Hole, later autocrypt, and now the IETF proposed draft, all use this mechanism. So we can say it's de-facto standard, even if it's not yet standard. Cheers, Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
