On Fri, Apr 19, 2024 at 10:10:13PM +0200, Alejandro Colomar wrote: > 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?
You're missing the point: All software has bugs. This would be a bug, but it's forseeable that mailers would have this bug. For example, if the header parser you implement differentiates where to put the headers it's parsed based on what the header is--i.e. standard header vs. mime header, it may add the header to the wrong object, and now you have two subjects, two from headers, etc... They are both headers, valid headers, that should be treated as headers--it just got the context wrong based on the name. In most cases this bug would be completely innocuous--and perhaps even beneficial (e.g. because it simplified the parser)--because mime header blocks typically should not have RFC 822 headers in them. Except now you've added a reason why they might. Depending on what the borked client does next, this could inject further broken e-mail into the thread causing problems for everyone on it. Does this bug exist anywhere? Does any similar bug exist anywhere? I don't know, but it's forseeable that such bugs may exist. Should you always avoid implementing functionality that might interact with a bug? No... but if you can find a better design that is far less likely to interact with bugs, you should probably use that instead. > 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. I don't think you can... I've never heard of Memory Hole, nor until this conversation had I heard of autocrypt. Outlook's long line parsing can be called a defacto standard, because it's used by millions, perhaps even billions of users every day. These ain't. And even if they were, just like Outlook's long line parsing, defacto standards are often very bad standards. And also, autocrypt DOES NOT use existing standard headers, so it doesn't put standard headers in the MIME block. That's an important distinction which would not trigger any bug like the one I described above. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
