BUG: wrong IMAP search query, returns 0 messages for UNSEEN, ALL etc on many servers

[alex-jitbit]

When connecting to many IMAP servers (mostly office365 and self-hosted Exchange) using MailKit - it returns zero messages when searching for NotSeen.

When testing with another library we used before (LimiLabs) - everything works perfectly.

I decided to trace the IMAP commands for both libraries and this is what I see:

MailKit (fails):

C: A00000007 NOOP
S: A00000007 OK NOOP Completed
C: A00000008 UID SEARCH RETURN () UNSEEN
S: * ESEARCH (TAG "A00000008") UID

Limilabs (works correctly)

C: 66210006 NOOP
S: 66210006 OK NOOP Completed
C: 66210007 UID SEARCH RETURN (ALL) UNSEEN
S: * ESEARCH (TAG "66210007") UID ALL 6500:6509,6511:6517,6519:6533,6535:6549,6551:6576,6578:6585,6587:6636

As you can see, MailKit asks for RETURN () UNSEEN instead of RETURN (ALL) UNSEEN

The worst part is I can't even search for ALL using MailKit b/c it asks for RETURN () ALL which also fails (has to be RETURN (ALL)).

P.S. Please fix this so we could finally migrate to MailKit. Meanwhile we rolled everything back to LimiLabs.

[alex-jitbit]

Similar question: https://stackoverflow.com/questions/64495738/mailkit-search-query-problems

[jstedfast]

The RFC in question is: https://tools.ietf.org/html/rfc4731

   If the list of result options is empty, that requests the server to
   return an ESEARCH response instead of the SEARCH response.  This is
   equivalent to "(ALL)".

In it, you can find the following example to illustrate the above rule:

Example:    C: A283 SEARCH RETURN () FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
            S: * ESEARCH (TAG "A283") ALL 2,10:11
            S: A283 OK SEARCH completed

I'll update MailKit to be explicit, but this is actually a bug in the mail servers (Exchange?) that failed to implement the specification correctly.

[alex-jitbit]

@jstedfast Thanks for the workaround! Yeah, I know this is most definitely a server bug, but what can I say... Welcome to the wonderful world of email :(

[jstedfast]

I've just uploaded a new 2.11.1 nuget package to nuget.org with the work-around

[jstedfast]

Welcome to the wonderful world of email :(

True, which is why I try to work around server bugs if there aren't any flaming hula-hoops involved ;-)