The IMAP RFC explains in prosa that authentication can be aborted by the client using "*\r\n". However, there is no syntax rule for this.

emersion/go-imap#571 (comment)

emersion/go-imap#571 (comment)

Offending implementation: smtp-n.global-mail.cn

See emersion/go-imap#540

Observed in: Exchange (outlook.office365.com:993)
Reported: No
Status: Unknown
Comment: None
Proposed solution(s):
    Consume the trailing space (making sure not to reproduce the defect.) Implemented in https://github.com/emersion/go-imap/pull/541, https://github.com/duesee/imap-codec/pull/468, and [Ruby](https://bugs.ruby-lang.org/issues/13649).

* STATUS INBOX (MESSAGES 0) 
                           ^
                           |
                           Extra whitespace

emersion/go-imap#589

Offending implementation: mailo.com

+ Rm9vbw== could be interpreted as Fooo (base64) or just Rm9vbw== (text).

See https://github.com/hteumeuleu/email-bugs

Found by @mjl-

CHANGEDSINCE 0 was sent for an account on a mail server that was update to support CONDSTORE (did not have the CONDSTORE extension before). CHANGEDSINCE should have been omitted from the command.

mod-sequence-value = 1*DIGIT
                      ;; Positive unsigned 63-bit integer
                      ;; (mod-sequence)
                      ;; (1 <= n <= 9,223,372,036,854,775,807).

Observed in: iPhone Mail (16.5.1)
Reported: Yes
Status: Open
Comment: None
Proposed solution(s): None

Ref emersion/go-imap#612

Offending implementation: https://www.dynadot.com

See emersion/go-imap#561

GMail does this:

T2 LOGIN "[email protected]" "password"
* CAPABILITY IMAP4rev1 CHILDREN UNSELECT LITERAL+ NAMESPACE XLIST UIDPLUS ENABLE ID IDLE MOVE
T2 OK LOGIN Completed.

Instead of this:

T2 LOGIN "[email protected]" "password"
T2 OK [CAPABILITY IMAP4rev1 CHILDREN UNSELECT LITERAL+ NAMESPACE XLIST UIDPLUS ENABLE ID IDLE MOVE] LOGIN Completed.

This behavior is problematic because the RFC says that once a LOGIN command has completed, the cached capabilities must be cleared by the client.

Offending implementation: imap.gmail.com

IMAP's ID command allows (), and nil to encode an empty parameter list:

id-params-list = "(" [field-value *(SP field-value)] ")" / nil
field-value    = string SP nstring

Some servers don't recognize both variants.

Observed in: Nemesis (GMX, Web.de, ...), and Exchange (See https://github.com/modern-email/defects/issues/12#issuecomment-1845491532)
Reported: No
Status: Unknown
Comment: None
Proposed solution(s):
    Don't send an empty ID command. Note: Proxies may require extra attention!

RFC 2971 uses ...

id_params_list ::= "(" #(string SPACE nstring) ")" / nil
    ;; list of field value pairs

... to define the parameter list.

I believe that ::= should be = (according to the current ABNF definition) and that # means "separated by whitespace"¹ (according to the examples).

Question: Does # mean 1* ("at least one") or * ("zero or many")?

¹ I saw it described in other contexts as "separated by comma".

Offending implementation: Nemesis, Exchange

Status responses in IMAP MUST have a non-empty text (and preceeding space).

resp-text = ["[" resp-text-code "]" SP] text
text      = 1*TEXT-CHAR
TEXT-CHAR = <any CHAR except CR and LF>

It was observed that Gmail has neither the SP nor the text when using HIGHESTMODSEQ.

Observed in: Gmail (Sep. 27, 2023)
Reported: Yes
Status: [Open](https://issuetracker.google.com/issues/289877509)
Comment: The examples in RFC 7162 are wrong, see [errata](https://www.rfc-editor.org/errata/eid5055).
Proposed solution(s):
    Wait for Gmail to fix it (or comment on issue)
    Replace with a sentinel value and log warning (implemented in [imap-codec](https://github.com/duesee/imap-codec))
    Discard, but make sure not to reproduce the defect

https://todo.sr.ht/~soywod/pimalaya/201

djc/tokio-imap#154

Offending implementation: mail.163.com

An IMAP server tells the number of lines in a message using the body-fld-lines ABNF rule:

body-fld-lines = number
number         = 1*DIGIT
                   ; Unsigned 32-bit integer
                   ; (0 <= n < 4,294,967,296)

According to the standard, negative values are not allowed. Still, Dovecot was observed sending -1 breaking parsing.

Observed in: Exchange/Dovecot (unknown)
Reported: No
Status: Unknown
Comment: Also see https://github.com/emersion/go-imap/issues/534
Proposed solution(s):
    Accept -1, emit warning, and rectify to 0 (implemented in [imap-codec](https://github.com/duesee/imap-codec))

mjl-/mox@96774de

Offending implementation: Windows Mail

See djc/tokio-imap@0aeb02e

Greeting { kind: Ok, code: None, text: "[FOO] ..." }

... will result in ...

* OK [FOO] ...

... and be interpreted like ...

Greeting { kind: Ok, code: Foo, text: "..." }

And ...

Greeting { kind: Ok, code: None, text: "[...]" }

... can't be expressed.

Given the following malformed message:

Date: Sat, 17 Aug 2024 12:21:18 +0000
From: "Bàd" <from@localhost>
To: "Wrȯng" <to@localhost>
Subject: All is wrong?

Too bad.

When fetching the envelope associated to this message from Proton Bridge, it returns a FETCH containing envelope address with not allowed bytes inside quoted strings, which leads to imap_next error Received malformed message.

I did the same test with Gmail, Outlook, Posteo and even 163, they all encode correctly the sender. Proton Bridge seems to send back envelope addresses as they are in the original message.

CC @duesee

Server replies successfully, but the untagged FETCH line lacks RFC822 part. A workaround is to fetch BODY[] instead.

Found in the wild: snapshot at archive.org | original

existing MUA workarounds

• meli fixed in v0.8.7 meli/meli@197132c https://git.meli-email.org/meli/meli/commit/197132cca0901aac4c3204fd2f7691baf02b6edf

See djc/tokio-imap@0b6c551

https://github.com/jonhoo/rust-imap/blob/5d0d2f9723b626770ffeab7e334ded67ae94fd7e/src/client.rs#L472

https://github.com/mjl-/mox/issues/101

Offending implementation: Outlook, koreanair.com

See more info here: http://web.archive.org/web/20240805063128/https://git.meli-email.org/meli/meli/issues/463/ | https://git.meli-email.org/meli/meli/issues/463

existing MUA workarounds

• mutt and mu4e:

  https://isync.sourceforge.io/mbsync.html#RECOMMENDATIONS

  When using the more efficient default UID mapping scheme, it is important that the MUA renames files when moving them between Maildir folders. Mutt always does that, while mu4e needs to be configured to do it:

  (setq mu4e-change-filenames-when-moving t)

• meli PR https://git.meli-email.org/meli/meli/pulls/464

• Roundcube
• FairEmail
• See https://github.com/mjl-/mox/issues/80