Confusion around UID with imap, potential bug

[Nicklas Avén]

Hello all

I am trying to automate some handling of incoming emails and found cUrl
to be a nice way of doing it.

But I ran into some problems which might be me misunderstanding, but
after several hours of trying to understand I have to ask.

From what I understand the imap-protocol have 2 different identifiers
of an email. 

1) UID
https://tools.ietf.org/html/rfc3501#section-2.3.1.1

2) Message Sequence Number Message Attribute
https://tools.ietf.org/html/rfc3501#section-2.3.1.2

With curl if I want to fetch the subject of a mail I do something like:
curl --url
"imaps://the.web.server/INBOX;UID=53956;SECTION=HEADER.FIELDS%20(SUBJEC
T)" 

The problem is that UID is not sent to the server as UID (point 1
above) but instead according to point 2 above.

According to this link this is not correct:
https://tools.ietf.org/html/rfc5092#section-9

UID=20 
in the url should translate to
UID FETCH 20 

which makes the fetch command switch to fetching UID instead of that
Message sequence number.

As I read this part:
https://tools.ietf.org/html/rfc5092#section-6

it is also quite clear that "uid=xx" should be "UID FETCH xx"

If I am right about this and not just mistaken, I don't know what is
the best way to solve it.

I mean changing the behavior is easy:

diff --git a/lib/imap.c b/lib/imap.c
index 942fe7d1e..7cf4d17f4 100644
--- a/lib/imap.c
+++ b/lib/imap.c
@@ -692,12 +692,12 @@ static CURLcode imap_perform_fetch(struct
connectdata *conn)
 
   /* Send the FETCH command */
   if(imap->partial)
-    result = imap_sendf(conn, "FETCH %s BODY[%s]<%s>",
+    result = imap_sendf(conn, "UID FETCH %s BODY[%s]<%s>",
                         imap->uid,
                         imap->section ? imap->section : "",
                         imap->partial);
   else
-    result = imap_sendf(conn, "FETCH %s BODY[%s]",
+    result = imap_sendf(conn, "UID FETCH %s BODY[%s]",
                         imap->uid,
                         imap->section ? imap->section : "");
 




But it would cause a hard breaking change. If people are relying on the
behavior of today they will get just the wrong email from what they
expect.

From what I read in the links above there is also no option for the url
to actually use the message sequence number, which could be usable too.

Not being able to get emails based on the persistent idmakes it hard to
keep track of what emails I have processed and what I haven't processed
as long as I cannot control all deletion of emails in the mail box.

So, in summary, 2 questions:

1) Am I right that something is wrong here?
2) What to do about it?

Now I am running a patched version which makes things very confusing
for me since it just changes the meaning of UID=


Thanks a lot for cUrl!

ATB

Nicklas Avén






-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/et

[Daniel Stenberg]

...

Post by Nicklas Avén
But it would cause a hard breaking change. If people are relying on the
behavior of today they will get just the wrong email from what they expect.
From what I read in the links above there is also no option for the url to
actually use the message sequence number, which could be usable too.

...

Post by Nicklas Avén
1) Am I right that something is wrong here?

I think you might be, others have pointed out this in the past as well.

Post by Nicklas Avén
2) What to do about it?

Let's fix it. I propose we come up with a way to tell libcurl to use the old
way, or vice versa.