Derek Martin wrote in <20240425190214.ga19...@bladeshadow.org>: |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.
You talk to the wrong person given that other people added that mechanism and put it into practical use. (And regarding this -- i think this works out fine. Except for dumb clients like mine which do not get the thing and do not map those headers into the place of the main ones. Yet.) |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. Sure. Anyhow it is plain that bugs are everywhere. In January i have written a RFC 5322 parser and looked around a bit (not mutt), and found not a single parser without problems. Then since February DKIM, and here you are. Also we have gained too many RFCs in the last one or two decades, and every little one invents new rulesets, instead of building upon either *822 or 2045, like the ones before them. This unfortunately even includes DKIM. |> 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 You can expect anything in it is what is said. Of course, MUAs which do not understand maximally visualize those header lines in addition to the main ones (what mine does), or totally ignore them (what i expect graphical ones to do). That is not "undefined behaviour". |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. You make problems when there are none. |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). Not undefined behaviour. In the sense of ISO C undefined at least. Their meaning is simply not defined in this context, so you either ignore them or show them (in configurable parts), but by no means would you treat them as a replacement to the main header instances. Where is the problem? |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 having a RFC which only defines that -- in the sense of the Melnikov etc draft's i have posted, would be a good thing. But these protected header duplicates have nothing to do with autocrypt as such. Unfortunately the S/MIME and PGP worlds seem to be enemies or what, it would make very much sense to define this for both, and say that in a signed message container header duplicates etc etc. Imho, that is. |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. --End of <20240425190214.ga19...@bladeshadow.org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
