1

I have the list of unique keys of unseen emails and my current logic is to process it in one session/connection. However, sometimes server[rebex] crashes and sends an error *

Rebex.Net.ImapException: The server has closed the connection.

at below point.

  • client.GetMailMessage(unique_key); //get information of particular email from unique key

Here, it will mark particular email's status seen though it generates an error. So, next time if I try to get information of unseen emails this particular unique key email will be missed.

Here, I have explored some possible ways

  1. To mark that error email unseen.
  2. Again create connection for that particular email and fetch information from that.
  3. Make IMAP client singleton and whenever it crashes, create a new one.

Are there any more optimized solutions? Thanks

Deep Jadia
  • 111
  • 1
  • 9
  • (3) - Using the Imap object as singleton - would not help at all. The IMAP protocol is session-based and once a session ends or fails, it's not possible to resume it. Even when you reconnect the same instance of Imap object, the new session will be independent from the previous one. – Lukas Pokorny Feb 21 '18 at 10:05
  • True, that's why I am using unique keys so that I can use it in different sessions. I will handle that scenario when the session will expire but what is the actual session timeout? – Deep Jadia Feb 21 '18 at 10:14

2 Answers2

4

You can prevent GetMailMessage from marking email as seen using Imap object's Settings.UsePeekForGetMessage option:

var imap = new Imap();
imap.Settings.UsePeekForGetMessage = true;
...

Once you actually decide to mark the email as seen, use SetMessageFlags method:

imap.SetMessageFlags(unique_key, ImapFlagAction.Add, ImapMessageFlags.Seen);
Lukas Pokorny
  • 1,449
  • 12
  • 12
1

The classic response is to mark messages as processed after processing instead of before.

Which may lead to problems if a processing a particular message leads to a crash. One doesn't want to reconnect and immediately run into the same problem. So perhaps keep a record of when you last tried, and try messages oldest-first.

arnt
  • 8,949
  • 5
  • 24
  • 32