How do I check which messageinfo is updated?

0 votes
asked Feb 27, 2014 by MPA (140 points)
edited Feb 27, 2014

If I use Imap.CheckForUpdates, I seem to recieve the Notification-event when a message changes flags (read-unread). This event however does not tell me which message that has the change. Do I really have to iterate through all messages on the server to spot the changed message?

Also, I only seem to receive the Notification-event when I make a call to CheckForUpdates with a rather long timeout. Is this intended behaviour, that I have to kind of make a blocking call in a thread?

Applies to: Rebex Secure Mail

1 Answer

0 votes
answered Feb 27, 2014 by Tomas Knopp (58,890 points)
edited Feb 27, 2014


no you do not have to iterate over the list of messages to find out which one changed the state. The following code will parse the SequenceNumber of the message which changed between unread/read state:

    static void imap_Notification(object sender, ImapNotificationEventArgs e)
        if (e.Notification == ImapNotification.MessageInfo)
            // parse the sequence number from the response
            string parameters = e.Response.GetLines()[0].Parameters;
            string[] parts = parameters.Split(new char[] { ' ' });

            int sequenceNumber;
            if (Int32.TryParse(parts[0], out sequenceNumber))
                // remember the sequence number if it was parsed succesfully
                _sequenceNumber = sequenceNumber;

        Imap imap = new Imap();
        imap.Login("username", "password");


        // register event handler
        imap.Notification += imap_Notification;

        // IDLE
        if (imap.CheckForUpdates(30000))
            // a MessageInfo notification was received, and we have sequence number
            if (_sequenceNumber != -1)
                imap.GetMessage(_sequenceNumber,  @"C:\myData\mail.eml"); // do something with the sequenceNumber - here I download the message.


We will add a better support for this task in one of the future releases.

Regarding the second question about blocking call. This is by design of the IMAP protocol. You can always call Abort and end the blocking CheckForUpdates/IDLE command immediately.

However, the timeout length should not have impact on the fact whether the server sends the notification or not. But in fact if the server will not do within a short timeout, you will probably need to use a longer one... Instead of waiting 1 long timeout, you could use 10x short timeout. The result should be the same.