GeezerVison

Under the compat32 policy, Message.items() yields a Header object (not a str) for any header carrying 8-bit data. You can assign that back with msg[name] = value, but msg.add_header(name, value) — documented as equivalent — raised TypeError: sequence item 0: expected str instance, Header found, because it always did SEMISPACE.join(parts). So the natural "copy every header" loop breaks:

for h, v in oldmsg.items():
    newmsg.add_header(h, v)   # TypeError on a Header value

Fix: when no extra parameters are passed, add_header() now stores the value the same way __setitem__ does, so a Header (or str) is stored unchanged — matching the documented equivalence. None still becomes ''. The parameterized branch is left as-is: it has to build a string, and silently stringifying an unknown-8bit Header would corrupt its bytes to U+FFFD, so it still raises there.

Added a regression test and a versionchanged note. ./python -m test test_email passes.

Disclosure: I used AI assistance writing this; I've reviewed the change and can explain it.

• Issue: email.message.Message.add_header behavior differs from Message[header]=v #151454