Message.Download suddenly fails?

Topics: Help requests, Issues
Apr 11, 2014 at 5:48 PM
Hello,

We have been using Message.Download() to download the full message, including the one text/plain attachment that comes with the messages we're processing.

This worked like a charm for months, but suddenly stopped working today. The call to Download() just fails now. Attachment.Download() still works, but our compiled, deployed code uses Message.Download().

Our email provider (Rackspace) said they did make some changes to their system between yesterday and today, but they seem clueless to help me with this subtlety. What would cause Message.Download() to suddenly fail when an email has a single, text/plain attachment (under 2K bytes), but which would still work with Attachment.Download()?

I'm really hoping to find a solution that doesn't involve redeployment! :-)

-Tim
Apr 11, 2014 at 6:13 PM
Ok, I decided to try setting reloadHeaders to "true" (instead of leaving it at the default value of "false") and things worked again.

What could have happened on Rackspace's side to suddenly require this change? Is there any way I can avoid redeploying to implement this extra parameter call?
Coordinator
Apr 11, 2014 at 9:37 PM
Hi Tim,

I could guess that this issue hangs together with the ContentType header, as its value is being used when downloading the message. However, to say for sure, I need one or two mor hints, such as the kind of exception being thrown or, a full stacktrace.

Can you provide me with some more details on how the method is failing?

Greets,

Pavel
Apr 12, 2014 at 1:04 AM

Hi Pavel,

It's not throwing an exception - the method call is just returning false. Does that help?

-Tim

Coordinator
Apr 12, 2014 at 9:45 AM
Hi Tim,

hm, the method can only return false if the server returned a BAD COMMAND or a NO response.
However between the fetch with headers and without them, is minor difference, and should not lead to such failure. If you could somehow provide me with a log of server responses, I could say more.

Best regards,

Pavel
Apr 12, 2014 at 12:24 PM
I'd be happy to provide a log! Just tell me how to capture it... :-)

-Tim

Coordinator
Apr 12, 2014 at 1:19 PM
Hi Tim,

ImapX uses System.Diagnostics.Debug class to write a log, first of all you need to create a listener that will catch the log in your application and write it to file:
Debug.Listeners.Add(new TextWriterTraceListener(@"C:\users\public\test.txt"));
Debug.AutoFlush = true;
then, as you create the client, set the IsDebug property to true:
var client = new ImapClient();
client.IsDebug = true;
you can send the log to info@imapx.org. Don't forget to remove the sensitive data such as the e-mail address and password you use for authentication. It should be at the beginning of the log.

Greets,

Pavel
Apr 14, 2014 at 9:36 PM

Hi Pavel,

I hate to admit it, but I cannot get this Debugging method to work. I cut and pasted your code AS IS, and it compiles just fine. I checked in my Visual Studio project settings (I'm doing this test as a Console App), but it just will not write anything to a file. I even messed with app.config and then tried to send the output to the console window, but I NEVER get any debugging info. So, finally, I have to ask for help here - what silly thing am I forgetting to do? I have read a few different places on how to do this, but again, I'm new to this method of debugging, so I must just be missing something. Any help you can offer?

-Tim

Coordinator
Apr 14, 2014 at 10:34 PM
Hi Tim,

sorry, forgot to mention it, to get it working, you need a version of ImapX which is compiled with the DEBUG flag being enabled in the project properties. To make it easy, I compiled the latest version for you: download

If you still get no output, let me know.

Greets,

Pavel
Apr 15, 2014 at 6:23 PM

Hi Pavel,

Ok, that worked.

I added some special markers before and after the call to Download so I could find it in the debugging text. Here's what I get:

***

IMAPX21 UID FETCH 392 ()

IMAPX21 BAD Error in IMAP command UID FETCH: FETCH list is empty.

***

This resulted from a call to Message.Download(ImapX.Enums.MessageFetchMode.Full)

Does this tell you what you need to know? I can still send you the log file as you indicated, but as it will take a lot of redacting to get sensitive info out, I wanted to see if this told you what you needed already.

-Tim

Coordinator
Apr 15, 2014 at 7:56 PM
Edited Apr 15, 2014 at 9:24 PM
Hi Tim,

thank you! Now I see what the problem is, will tr yto fix it tonight or tomorrow morning.

Greets,

Pavel

UPDATE: The issue should be fixed now, you can take a look at the latest code.