gh-49680: Don't rewrite CR/LF in imaplib APPEND literals

[harjothkhara]

IMAP4.append() rewrites every bare CR or LF in the message to CRLF (via MapCRLF.sub) before sending it. But an IMAP literal is a counted, opaque octet sequence ({N} + exactly N bytes), so the rewrite corrupts payloads that legitimately contain bare CR/LF — e.g. encoded headers or an already-serialized message — and desyncs the byte count from what the caller meant to send.

This patch makes append() send the message verbatim; _command() still owns the protocol framing (the {N} literal, the continuation handshake, the trailing CRLF).

Behavior change: callers that relied on the old normalization — notably EmailMessage.as_bytes(), which emits bare \n under the default policy — would now send those bytes unchanged and should ensure CRLF themselves (e.g. email.policy.SMTP). Whether treating the literal as opaque is the right fix, or another approach is preferred, is a maintainer call — see my comment below. The new tests read the exact {N} literal octets and assert byte-exact round-trips for a payload mixing \n, \r, and \r\n, and for a real EmailMessage.

Note for reviewers: the module-level MapCRLF regex is now unused. It's not in __all__ and isn't documented; I left it in place to keep the diff focused, but happy to remove it (with its own NEWS line).

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

• Issue: imaplib: must not replace LF or CR by CRLF in literals #49680

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #33170388 | 📁 Comparing 7e6bd8c against main (c2ca772)

  🔍 Preview build  

2 files changed

± library/imaplib.html
± whatsnew/changelog.html

[harjothkhara]

@sethmlarson would you mind weighing in on the behavior choice here? This PR makes append() send message bytes unchanged rather than normalizing bare CR/LF. Should we keep that behavior, or reject input that still contains bare CR/LF?

[serhiy-storchaka]

Thanks, this is a good PR!

For backward compatibility, I think the new behavior should be optional, with the current normalization kept as the default -- note that EmailMessage.as_bytes() emits bare \n under the default policy.

I accidentally opened a concurrent PR, #152775, before noticing yours. We can either close mine and you add an option like its translate_line_endings, or I keep mine and add you as a co-author. In both cases I'd like to carry over your tests.

Which do you prefer?

[serhiy-storchaka]

Suggested change

	.. versionchanged:: 3.16
	.. versionchanged:: next

[harjothkhara]

Thanks @serhiy-storchaka. Agreed on backward compatibility. Keeping normalization as the default and making verbatim opt-in is the right call, since EmailMessage.as_bytes() emits bare \n under the default policy.

Let's go with option B: keep your #152775, add me as co-author, and carry over the tests. No need to duplicate a clean PR that's ready to land. I'll close #151557 in favor of yours.

On the tests: please pull whatever is useful. Mine also read the exact {N} literal octets and check a byte-exact round-trip for a payload mixing \n, \r, and \r\n, plus one for a real EmailMessage. Happy to adapt those to sit next to your test_append_translate_line_endings if you want the extra coverage. Let me know if you want me to push anything.

[harjothkhara]

Closing in favor of #152775 (option B). See the discussion above.