imaplib module IMAP4.append() unexpected response BAD Command Error

[yuy]

BPO	33225

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2018-04-04.17:40:42.714>
labels = ['extension-modules', 'type-bug']
title = 'imaplib module IMAP4.append() unexpected response BAD Command Error'
updated_at = <Date 2018-04-04.17:40:42.714>
user = 'https://bugs.python.org/yuy'

bugs.python.org fields:

activity = <Date 2018-04-04.17:40:42.714>
actor = 'yuy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2018-04-04.17:40:42.714>
creator = 'yuy'
dependencies = []
files = []
hgrepos = []
issue_num = 33225
keywords = []
message_count = 1.0
messages = ['314945']
nosy_count = 1.0
nosy_names = ['yuy']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33225'
versions = ['Python 3.6']

[yuy]

part of bytestring in message in .append() includes 'text-align: center;\r\n}</style><!--[if gte mso 9]><xml>'

append always fails on such messages with
abort: command: APPEND => unexpected response: b'}</style><!--[if BAD Command Error. 10'

Some spam emails includes this in body. I pipe incoming emails to spamassassin and pipe back stdout to be appended to spam mailbox. This type of failures always causes IMAPS connection to be closed.

I can reproduce this every time. IMAP server is Microsoft Exchange I believe

[serhiy-storchaka]

The reported tail }</style><!--[if … is exactly the text after a \r\n in the message body, which suggests the server read the APPEND literal line-by-line and parsed the rest as a command rather than consuming the declared octet count.

One plausible cause is gh-78319: before it was fixed, imaplib sent 8-bit APPEND data in a plain {N} literal instead of the RFC 6855 ~{N} literal8, which a strict server can reject and then resynchronize by lines. That fix landed in 3.13+ (GH-9436).

Could you check whether this still happens on a current Python (3.13 or later)? If it does, please share more details: the full traceback, whether UTF8 was enabled, and the exact message bytes (or a minimal reproducer).