Steffen Nurpmeso wrote in <20250625213240.gZD9-WIX@steffen%sdaoden.eu>: |Bron Gondwana wrote in | <5a73ab9e-a77a-4837-9cc7-2578ef727...@app.fastmail.com>: ||Just out of interest[.] ||[.]This is the resulting message - which still[.] ... |Out of interest: .. you could retry your test with the word |"Dankeschön" (ö=U+00F6), which is, well, the actual German word to |use. From guessing i would think your approach then already |becomes noisy (you leave the 7-bit clean world), whereas (AC)DC |only spits out some more base64 bytes.
And even then this is in large parts synthetic, to reiterate this. Even though most people now use rich text aka HTML email, so it is already in MIME, and most often even multipart format; it still heavily depends upon mailing-list configuration, how and if additions, and even content-transfer reencodings happen. A real-life example. Two days ago i sent a message to a mailing-list, which does not add footers, which does not tag Subject:, but which still rewrites From: in "the via style"; it was a reply to a message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable because it contained "It’s about all" (’=U+2019). It was addressed to me, so i replied to it like that. Since the quote contained U+2019 i sent it out as Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable which caused quite a lot of |>|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= lines also because of contained equal-signs =. This was munged by the list to Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit so quite some changes on that front. Funnily his reply to this was again Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable and it came like this over the list, because (it seems), some longer lines had to be folded via quoted-printable > | It=E2=80=99s about all file descriptors that have FD_CLOFORK set after= fork but so the 8-bit conversion did not kick in. Well, at least the character set front stabilized upon UTF-8; even latin1 and cp1252 i do not see that much no more, otherwise back and forth character set conversion could also kick in (at times). I mean, it is all ok, but these examples are synthetic, at least in my world (often). So *i* think this is maybe fine as an example in a RFC, but they do not aid in revealing problems or anything, as they do not even try to detect or address corner cases. --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
