New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IMAP custom requests always use the LIST response handler #536
Comments
Parsing isn't done for custom IMAP requests iirc. Should it be? That's the question I guess. To your report though the data is received but remains part of the headers. You can either issue effectively the same command using an IMAP URL or parse the headers. This has come up before. Some commands there may not be any alternative other than go custom and parse the header data. Also note there is a known bug with IMAP where long lines are truncated (knownbugs #90). I recall I did take a look at both of those issues at different times but they were too complicated to fix in the time I had. cc to Steve (@captain-caveman2k) in case he's still interested. So for your example you should be able to do the same thing as Steve showed to me in that thread: curl_easy_setopt(curl, CURLOPT_URL, "imaps://imap.gmail.com:993/INBOX/;UID=9/;SECTION=HEADER.FIELDS%20(DATE%20FROM%20TO%20SUBJECT)");
curl_easy_perform(curl); and read from the body. You will need a recent version of curl (I forget how recent -- just use the latest version). Or if you have to... curl_easy_setopt(curl, CURLOPT_URL, "imaps://imap.gmail.com:993/INBOX");
curl_easy_setopt(curl, CURLOPT_CUSTOMREQUEST, "FETCH 9 BODY[HEADER.FIELDS (DATE FROM TO SUBJECT)]");
curl_easy_perform(curl); and read from the header which would be like * 9 FETCH (BODY[HEADER.FIELDS (DATE FROM TO SUBJECT)] {90}
Date: Thu, 19 Nov 2015 14:42:05 -0800 (PST)
From: <foo@bar.com>(foobar)
Subject: qux
)
A004 OK Success then parse that |
Related discussion on the mailing list. Note that the URL alternative above does not work if you need UID based actions. |
@jay - I took a look at knownbugs #90 last year but it was beyond my understanding of the pingpong layer so I backed out my changes at the time - Its still on my todo list but a little further down that what I'm currently working on :( |
As for this issue... I'm aware of the limitations of the IMAP interface, as discussed on the mailing list in the links above, and would like to sort them out or assist someone that is up for the challenge - I'm unfortunately focused on other stuff at the moment. |
Bug: #536 Reported-by: eXeC64@users.noreply.github.com
I hear you Steve. I've moved this to known bugs for now. |
Thank you - it certainly won't get forgotten but it just may take me a while to get around to it, especially when you consider the posts in those links are two years old :( |
Using a custom request such as
FETCH 9 BODY[HEADER.FIELDS (DATE FROM TO SUBJECT)]
yields only the following response data.* 9 FETCH (BODY[HEADER.FIELDS (DATE FROM TO SUBJECT)] {147}
The 147 bytes of actual data are not retrieved/handled. This stops any kind of custom
FETCH
request from being useful, as in many cases the actual response data is simply inaccessible through libcurl.The text was updated successfully, but these errors were encountered: