On Thu, Apr 25, 2024 at 11:07:30PM +0200, Alejandro Colomar wrote: > 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.
Who are you to decide what the most important clients are? If my favorite mail client is impacted, then that's the most important client of all... TO ME. One of Mutt's longstanding core development principles is to stick to the robustness principle (Postel's Law). In particular "be conservative in what you emit." This is not that. Kevin is the maintainer, so he can do what he wants, but I think accepting this feature violates Mutt's original development philosophy. > 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. Virtually no one uses this feature, so again, the lack of evidence is all but meaningless. But sticking to good software design principles does matter, even in the absence of documented cases of nonconfirmity to good software design principles causing actual problems. > That's a bit contradictory to another section of the same RFC: I've read the RFC, I know what it says. I already noted in previous messages that adding the headers is ALLOWED by the RFC. But it historically hasn't been something that is generally done, and just because something CAN be done doesn't mean it SHOULD. Any time you change the input data to a program in an unexpected way, a bug is the LIKELY consequence. I gave some legitimate examples of the sorts of bugs that are LIKELY due to this implementation due to its implementers not expecting that behavior. There have been two alternatives suggested that do not suffer from this problem, or any other as far as I can tell. Either of those would seem obviously better, and while I have no use for them, I would have no objection to them. They don't even require a new standard (although you certainly should draft and submit one anyway)--all the specification required is already part of either RFC 822 or the MIME standard RFCs... You probably would need to register a new MIME type with IANA or whatever, to distinguish the signature from that of the message body, but I imagine that's easier than writing a whole new RFC and getting it approved. > I think RFC 2045/2.4 specifically allows that as an extension. Allows it, technically, maybe... but it does not DEFINE it. Particularly with regard to the content of messages it generates, Mutt implements standards. Or at least historically it did. This is not that. > And the draft that has been mentioned here is the document for > documenting the extension. But again, it's not a standard, it's just a specification. A standard is a specification that has been reviewed and accepted by either a designated standards authority, or by the associated community generally. This document is neither. -- 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
