imap search doesnt seem to catch new messages

Question

Im using the following code to catch NotSeen messages in my gmail hosted inbox.

using (Imap client = new Imap()) {
    client.Connect("imap.gmail.com", 993, SslMode.Implicit);
    client.Login("user", "password");
    client.SelectFolder("Inbox");

    while (true) {
        ImapMessageCollection messages = client.Search(ImapSearchParameter.NotSeen);
        foreach (ImapMessageInfo message in messages) {
            MailMessage got = client.GetMailMessage(message.SequenceNumber);
            Console.WriteLine("subject: {0}", got.Subject);
            Console.WriteLine("flags: {0}", message.Flags);
        }
        if (stop)
            break;
        Thread.Sleep(TimeSpan.FromSeconds(5));
    }
    client.Disconnect();
}

Works fine, dumps subject of all Unread messages and marks them as read. But it only works for the first iteration in the while loop, second run of the loop does not catch any new messages when I send them from a separate webclient.

Any idea what im doing wrong?

Answer 1

I was able to reproduce the same behavior using my Gmail account. Unfortunately, it looks like you are not doing anything wrong and that this is a Gmail issue.

I added a GetFolderInfo call to your code and this is the log I get using the Imap's LogWriter property:

2013-05-24 17:16:27.644 INFO Imap(1)[1] Command: R00008 STATUS Inbox (MESSAGES RECENT UNSEEN UIDNEXT UIDVALIDITY)
2013-05-24 17:16:27.950 INFO Imap(1)[1] Response: * STATUS "Inbox" (MESSAGES 98 RECENT 0 UIDNEXT 372 UIDVALIDITY 623096772 UNSEEN 0)
2013-05-24 17:16:27.951 INFO Imap(1)[1] Response: R00008 OK Success
2013-05-24 17:16:27.952 INFO Imap(1)[1] Command: R00009 UID SEARCH UNSEEN
2013-05-24 17:16:28.267 INFO Imap(1)[1] Response: * SEARCH
2013-05-24 17:16:28.267 INFO Imap(1)[1] Response: R00009 OK SEARCH completed (Success)

2013-05-24 17:16:33.269 INFO Imap(1)[1] Command: R0000A STATUS Inbox (MESSAGES RECENT UNSEEN UIDNEXT UIDVALIDITY)
2013-05-24 17:16:33.823 INFO Imap(1)[1] Response: * STATUS "Inbox" (MESSAGES 99 RECENT 0 UIDNEXT 373 UIDVALIDITY 623096772 UNSEEN 1)
2013-05-24 17:16:33.824 INFO Imap(1)[1] Response: R0000A OK Success
2013-05-24 17:16:33.825 INFO Imap(1)[1] Command: R0000B UID SEARCH UNSEEN
2013-05-24 17:16:34.204 INFO Imap(1)[1] Response: * SEARCH
2013-05-24 17:16:34.204 INFO Imap(1)[1] Response: R0000B OK SEARCH completed (Success)

2013-05-24 17:16:39.207 INFO Imap(1)[1] Command: R0000C STATUS Inbox (MESSAGES RECENT UNSEEN UIDNEXT UIDVALIDITY)
2013-05-24 17:16:40.018 INFO Imap(1)[1] Response: * STATUS "Inbox" (MESSAGES 99 RECENT 0 UIDNEXT 373 UIDVALIDITY 623096772 UNSEEN 1)
2013-05-24 17:16:40.019 INFO Imap(1)[1] Response: R0000C OK Success
2013-05-24 17:16:40.020 INFO Imap(1)[1] Command: R0000D UID SEARCH UNSEEN
2013-05-24 17:16:40.491 INFO Imap(1)[1] Response: * SEARCH
2013-05-24 17:16:40.491 INFO Imap(1)[1] Response: R0000D OK SEARCH completed (Success)

The "STATUS" command properly reports "UNSEEN 1" after the message arrived, but "SEARCH" still returns an empty list, which is obviously incorrect.

Fortunately, a workaround for this is quite simple. Unselecting the folder and selecting it again makes the SEARCH work again. This can be used in conjunction of GetFolderInfor method which is actually able to detect new messages. Adding this to your while loop (prior to Search method call) solves the issue:

                ImapFolder info = client.GetFolderInfo("Inbox");
                if (info.NotSeenMessageCount > 0)
                {
                    client.UnselectFolder();
                    client.SelectFolder("Inbox");

                    ImapMessageCollection messages = client.Search(ImapSearchParameter.NotSeen);
                    ...
                }

                ...

Answer 2

Thanks - Your fix works just fine.

I have just tested my code on SurgeMail and it has the same problem as gmail.

client.Search(ImapSearchParameter.NotSeen)

does not find unseen messages after the initial call. folder must be reselected first.

Comments

Thanks for letting us know! I was thinking about a possibility of adding a workaround for this, but it looks like doing the unselect/select operation automatically might introduce more problems than it would solve, unfortunately.