Skip to content

gh-49680: Add translate_line_endings parameter to imaplib.IMAP4.append#152775

Open
serhiy-storchaka wants to merge 2 commits into
python:mainfrom
serhiy-storchaka:imaplib-append-translate-newlines
Open

gh-49680: Add translate_line_endings parameter to imaplib.IMAP4.append#152775
serhiy-storchaka wants to merge 2 commits into
python:mainfrom
serhiy-storchaka:imaplib-append-translate-newlines

Conversation

@serhiy-storchaka

@serhiy-storchaka serhiy-storchaka commented Jul 1, 2026

Copy link
Copy Markdown
Member

IMAP4.append() rewrote every bare CR or LF in the message to CRLF
(MapCRLF.sub(CRLF, message)) before sending it as the APPEND literal.

But an IMAP literal is "a sequence of octets (including CR and LF)"
(:rfc:3501), and the protocol framing -- the octet count and the
trailing CRLF -- is handled separately by _command(), so rewriting the
payload silently corrupts the caller's message (for example, content with
intentional bare CR or LF, reported back in 2009).

This adds a keyword-only translate_line_endings parameter. It defaults
to True, preserving the previous behavior; passing False sends the
message literal exactly as given.

smtplib is intentionally left unchanged: it transmits the message as
CRLF-terminated lines in the DATA command (:rfc:5321), where
normalization is required for correct framing -- unlike an octet-counted
IMAP literal.

Pass False to send the message as an exact sequence of octets, without
rewriting bare CR or LF to CRLF.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@read-the-docs-community

read-the-docs-community Bot commented Jul 1, 2026

Copy link
Copy Markdown

Documentation build overview

📚 cpython-previews | 🛠️ Build #33405647 | 📁 Comparing ccf900a against main (34503f3)

  🔍 Preview build  

3 files changed
± c-api/module.html
± library/imaplib.html
± whatsnew/changelog.html

Read the APPEND literal by its octet count and verify that a serialized
email message with bare LF is sent verbatim when translate_line_endings
is false.  Document using email.policy.SMTP for that case.

Co-authored-by: harjoth <harjoth.khara@gmail.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant