Derek Martin wrote in
<20240425215214.gb19...@bladeshadow.org>:
|On Thu, Apr 25, 2024 at 10:22:16PM +0200, Steffen Nurpmeso wrote:
|> You talk to the wrong person given that other people added that
|> mechanism and put it into practical use.
|
|Yeah unfortunately, as Kevin admitted, this feature was never
|discussed here when it was implemented, so those who care about any of
|that are having the conversation now.
|
|But that doesn't matter... I was specifically responding to YOUR
|point, which was a logical fallacy. You seemed to be making a point
|that implied that if you aren't aware of clients that are negatively
|impacted, then it doesn't matter. That's bad logic.
So i really have no time for neither bikeshedding nor nitpicking,
but i quoted the standard, and there seems to be no
misinterpretation possible, for a simple brain like mine.
In email there is the main header, and that is anything that is
known; unless the agent is MIME capable, then it can interpret
multipart and "individual"-part sections. By themselves, or
recursively descending/unfolding (decryption etc).
Which, btw, mutt implements in the only sensible way (with an
object tree, last i looked).
In *no* way, unless explicitly enabled, can a MIME header
influence the main message header.
I want to remark and always say that i think it is an unfortunate
decision to implement DKIM and all that mess the way it is done,
since our forefathers went the
envelope-into-new-envelope-then-seak approach for centuries or
even milleniums, and if it would be like that, then we would have
no problem with signatures breaking because of mailing-list
footers or adjusted subjects, and all that.
|There's a difference between bugs caused by the implementer of the
|receiver failing to correctly implement what is normal and expected,
|and bugs caused by the implementer of the sender intentionally
|implementing behavior that is outside what is normal and expected.
|The former affects only the user of that software. The latter affects
|everyone else but the user of that software (at least potentially).
|Responsible developers should strive to avoid both, but the latter
|clearly has a more serious impact on more people, and exactly the
|wrong people. It is the whole reason the robustness principle exists.
|Outlook is famous for this sort of thing, and it's one of the reasons
|people hate Microsoft/Outlook.
|
|> (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.)
|
|You have no proof that this is true, among the hundreds if not
|thousands of e-mail clients that exist. That is the nature of
Yeah, i can plug one together with python modules or rust or what
in a minute that satisfies you. Maybe.
|undefined behavior. There's nothing special about that term in the
|context of ISO C or otherwise. And since there isn't any sort of
|official standard, it's probably rather unlikely that the majority of
|clients will ever addopt this. You can't call them dumb for not
|implementing a standard that doesn't exist.
|
|> 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".
|
|These are not the only possibilities, since again, the behavior is
|undefined. Headers could be incorrectly repeated (which could lead to
No one cares unless the signature breaks.
That, in general, is a GUI problem, again. And everybody,
especially the browser based ones, will not do the right thing
upon it, whatever this is.
For example, some years ago, the ("some") GNU people were sending
out emails with two from:s i think it was (i maybe have saved it
somewhere), it was deliberately wrong (i told them). This was
against the standard.
The email infrastructure delivered it :)
|additional bugs, since that also is outside the spec), the "wrong"
|version of the header could be the one the client uses. Or the
|structure you're using to hold the headers could overflow, causing
|memory corruption and/or crashes. Etc.. Those things might be
|unlikely or impossible to happen in the absence of the undefined
|behavior. It's hard to be robust against problems you didn't forsee,
|on account of them being well outside the norm.
|
|Undefined behavior is... undefined. When the input data deviates from
|what is expected, any variety of resulting bugs is LIKELY.
Interesting run, anyway.
--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)
