@philcowans

You're right, this is weird and I'm not entirely sure what's going on. I was able to get it to fail with some combinations, pass with others, and thought I had it figured out until I tried some other cases and those contradicted what I thought I'd established.

As to what's going on - I have a guess, but I'm not confident about it. I think it might be triggering only when an #rfc2047 -encoded segment of the header field value either exceeds the message's policy's line length limit, or in some way crosses over that boundary (such as having leading unencoded ASCII without a whitespace break that would allow the line to fold before the encoded segment).

If this is the case, it looks like a bug to me, too. If it's still happening with the most recent version of Python, I'd say it needs fixing. I haven't tried anything past 3.11.x right now.

Only showing up using the EmailMessage class vs Message class is explainable; there are slight differences, and one is for legacy code compatibility.

Weird.

#Python #email #EmailModule #EmailMessage #encoding #encoded

Meine Fresse, wieso muss ich nem Hersteller Mails erklären... Jetzt die x Mails zum Ticket so beendet

"machen Sie das Ticket einfach zu. Ich denke, Microsoft und Google raten die Codierung nicht nach RFC 2047 codierter Mails, u.a. beim Betreff. Das macht die Mails dann nicht korrekt, aber wie gesagt, bin ich da Laie und mag falsch liegen. Im Endeffekt sind es ja nur interne Mails und wir können damit leben."

#rfc2047

@irtf I used to read RFCs at rfc-editor·org because #ietf·org is in an exclusive #walledGarden that blocks Tor users.

Today I wanted to read #RFC2047 but I couldn’t because apparently #rfc-editor·org has joined that same exclusive walled garden.

It’s reckless & irresponsible to restrict access to “open” standards. Please fix your shit. Nothing is worse than the standards org themselves being incompetent about openness & interoperability. This is an embarrassment!