@gordonmessmer tests are failing (see Details links under Some checks were not successful section). Would you mind to continue working on the PR, please?

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

I'll look at it again, yes. I'm getting odd results from updated tests, so some additional work is still needed...

Tests look like they're passing, but trying this on a live IMAP server fails, because the server actually receives:

LLFC3 APPEND INBOX UTF8 (~{63}\r\n

... when Sam suggested that it should receive:

LLFC3 APPEND INBOX NIL NIL UTF8 (~{63}\r\n

But that's probably a larger bug in the imaplib module, and not directly related to this change.

@warsaw, @maxking (as active e-mail experts)

I've asked Sam to chime in. The RFC calls those arguments optional. Based on its behavior, it seems that Courier expects them to be specified as NIL when they are not provided, rather than left out entirely.

I added a commit for consideration. Transforming None to "NIL" is RFC-compliant (which is consistent with the intent of this PR). Tests pass, and this works with Courier IMAP.

The NIL requirement may be a bug in Courier (ironically also caused by UTF8 support), so the "imaplib: transform None into "NIL"" patch might not be needed.

Everything else looks good, I think.

Sam released a new version of Courier, and I've verified that the None->NIL transformation is no longer necessary, so I've backed it out.

Please let me know if there's anything I can do to help move this forward.

This PR is stale because it has been open for 30 days with no activity.

Please let me know if there's anything I can do to help move this forward.

This PR is stale because it has been open for 30 days with no activity.

All commit authors signed the Contributor License Agreement.