ImapClient methods hang forever

Aspose.Email Product Family
1

Hello,


if there is a problem on the server side, but even if I just enter the wrong password for the email account, ImapClient.ListMessages(1) which I use to test connection to the email server blocks probably indefinitely (I left it for over 10 minutes), even the FetchMessage that has an int Timeout just hangs. It should behave as Pop3 does, which throws an exception for GetMessageCount after a while with incorrect credentials, server down, etc. Even finding a workaround is extremely difficult as any call to Disconnect/Dispose that I have in my cleanup logic will hang as well… This is another very serious issue, and I can’t help feeling like a part-time unpaid Aspose QA over the last several months…

Martin
2
Hi Martin,

Thank you for sharing your concern with us.

I was able to reproduce this issue at my end using the latest version of Aspose.Email for .NET 4.3.0 and have logged it as NETWORKNET-34426 in our issue tracking system for further investigation by our development team. Once there is any information available in this regard, we'll update you here via this thread.

We are sorry for the inconvenience caused to you.

3

The issues you have found earlier (filed as NETWORKNET-34426) have been fixed in this update.

This message was posted using Notification2Forum from Downloads module by Aspose Notifier.
4

Hi Kashif,

I tested it with this code:

var imap = new ImapClient(“[imap.gmail.com](http://imap.gmail.com/)”, 993, @“myemail@gmail.com”, “wrongpassword”) { EnableSsl = true };

var message = imap.ListMessages(1);

and though doesn’t hang forever anymore, it still hangs for over 30 seconds before I get that exception, that is still unacceptable, when I know in earlier versions than 4.3.0 it threw that exception almost immediately. I hope this cane be “fixed” better.

Martin

5

Hi Martin,


I have re-tested this issue with the latest as well as previous versions. The old version takes almost 10 seconds to raise an exception while the latest version takes approximately 30 seconds to raise the same exception. I have logged these findings against the linked ticket with this thread and will update you here once there is an update available in this regard.