Hi Derek, On Thu, Apr 25, 2024 at 03:02:14PM -0400, Derek Martin wrote: > Absence of evidence fallacy. For this to be a non-concern (logically > speaking) you would need to prove that NO client has this problem. > Proving a negative is not always impossible, but given the number of > clients in existence, it's pretty impractical. > > Now, how that leaves you IS NOT with conclusive proof that you should > not do it this way... but rather a strong suggestion that IF you can > find a good alternative that doesn't have the same potential weakness > (nor other worse tradeoffs), choose that instead.
While I don't have proof that no clients have major breakage with these header fields, I can say that the most important ones don't have major breakage. mutt(1) has been protecting many header fields for several years already (not by default, but you could enable it), and nobody has ever reported a bug, did any? The night sky is still up there and didn't fall on our heads. I guess mutt(1) users interact with every other major provider regularly even if in small numbers. > But I'm repeating myself now. > > > ok i have reread 2045 and it says [...] > > Largely irrelevant, because of what it does NOT say... For instance, > it does not describe what the behavior should be if standard RFC 822 > headers appear BOTH in a mime header block AND in the actual message > headers. This is what's known as undefined behavior. Therein lies > the path to non-interoperability--which Mutt intends (or, at least has > historically intended) to avoid. I've already described how such a > problem might arise in a previous message. Avoid forseeable > interoperability problems when possible. > > Also, what the RFC does explicitly state is that headers in the MIME > header block that do not begin with "content-" "CAN HAVE NO MEANING" > [emph. mine], and "may be ignored." That's a bit contradictory to another section of the same RFC: <https://www.rfc-editor.org/rfc/rfc2045#section-2.4> Any sort of field may be present in the header of an entity, but only those fields whose names begin with "content-" actually have any MIME-related meaning. Note that this does NOT imply thay they have no meaning at all -- an entity that is also a message has non-MIME header fields whose meanings are defined by RFC 822. Which clearly says they do have meaning; it's just that they don't have MIME-related meaning. Bascially I read that as saying that you can put mostly whatever you want, and MIME won't care about it; it will have the meaning that you or a different RFC want to assign to it. > It gives no indication that there > would be an exception to those conditions for headers that are > explicitly defined by RFC 822 (or its successors). Therefore any > processing of them that you do is at best ambiguous, i.e. again, > undefined behavior, and at worst violates the spec (because processing > them gives them meaning that the spec says they can not have). > > Which of course isn't to say that the standard can't be extended or > modified; but if you want to do that, then you should actually draft > the standard extension and get it approved, well before asking clients > whose central tenets include complying with standards (as Mutt's do) > to implement such extensions. The reasons to do that are to establish > whether the relevant community even values the extension, and whether > better alternatives may exist or be found. I think RFC 2045/2.4 specifically allows that as an extension. And the draft that has been mentioned here is the document for documenting the extension. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
