On Wed, Apr 24, 2024 at 01:07:10AM +0200, Steffen Nurpmeso wrote: > Sirius via Mutt-dev wrote in > |I would worry less about the users and more about breaking clients. The > |method of "be liberal about what you receive and conservative about what > |you send" is apt. Being standards-compliant is safe. > > Ah, do you know about any one client which fails on headers it > does not understand,
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. 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." 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. -- 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
