Repository navigation
Reject control characters in IMAP commands #143921
Description
Activity
If there is someone familiar enough with IMAP to review this, please do.
Otherwise I need a bit more detail, since I'm not that familiar with IMAP, and both the RFC and the code are quite complex. Can you cover how the RFC makes non-printables (other than space) illegal in 'commands', and how that relates to the imaplib implementation of _command? I scanned the RFC and code for a bit, and while my gut says your PR is correct, it isn't obvious by any means.
- added a commit that references this issue
on Jan 20, 2026 - added a commit that references this issue
on Feb 13, 2026 13 remaining items
I think the broad check should be reverted and replaced with a narrow one.
It rejects all of
0x00–0x1Fand0x7F, but only CR, LF, and NUL are actually unsafe (command injection / binary truncation). TAB and the other control characters are validQUOTED_CHARs per RFC 9051, and such a mailbox name can be returned by the server viaLIST, so the client must be able to send it back — as a quoted string — inSELECT,STATUS, etc. Rejecting it withValueErrormakes imaplib unable to operate on a folder that legitimately exists, which is a regression.The narrow check keeps the security fix without over-rejecting:
_control_chars = re.compile(b'[\x00\r\n]')
This is only the safety guard, though. Handling characters that are legal but need quoting — space,
",\, as well as TAB — requires proper argument quoting, which is what #152703 (gh-40038) restores. Without that, those arguments still aren't sent correctly; a blanket control-character reject is the wrong layer to solve this at.- added 4 commits that reference this issue
on Jul 5, 2026 Hi there. Is this fix planned for 3.10, 3.11 or 3.12?
Linked PRs