(2) "FETCH [seq] (FLAGS BODY[] FLAGS)" returns a FETCH response with the obvious three items in that order. The first FLAGS is (). The second flags is (\Seen).
This is alright, provided that \Seen is in fact a session-only flag.
It isn't, and the modification is permenant
The only requirement is that all the FETCH data be returned.
As a result of the above, "FETCH seq (FLAGS BODY[] FLAGS)" is equivalent to "FETCH seq BODY[]".
This ought to be the case, but it isn't, because it doesn't consolidate and it doesn't notify. The FETCH response, in fact, is of the form "FLAGS () BODY [] {XXX} ... FLAGS (\Seen)", which I found quite funny, given BODY.PEEK[] worked and I wasn't going to have to think of something else.
A workaround for the first two this is to BODY.PEEK[] even in EXAMINE mode, or to send FLAGS before BODY[]. Either would have worked around the bug, but only the former would have avoided changing \Seen.
So the mail store can return the data without setting the flag.
The first workaround is the only effective one. The second workaround can only be trusted if you fetch the flags in a prior command.
I'm going with both, just in case.
Potential workarounds for (3) are more drastic.
It sounds like the mail store is one with a "once set never cleared" \Seen flag. I've heard of such mail stores; they aren't compliant with the spirit of IMAP, but they are compliant with the letter. Put another way, this is bad behavior but not prohibited behavior.
Sure. Now that I think about this a little more this behavior is really, really gross, but not strictly speaking noncompliant. The real issue is changing \Seen in EXAMINE--this change is permenant. The fact that it changed for the local session is unfortunate and I should have used BODY.PEEK[], but the servers I've tested with in the past did not apparently set \Seen for messages fetched with BODY[] under EXAMINE.
Tim
