My sent-mail folder is on an IMAP resource. After sending an e-mail I always obtain a popup NO UID STORE Invalid parameter: +FLAGS ( 61FF ) It seems like some parameter to the UID STORE command is missing (to be precise the UID of the uploaded message). Here is part of an IMAP transscript, starting directly after the message data that has been uploaded: S: A005284 OK APPEND completed [ APPENDUID 1322069043 4410 ] C: A005285 SELECT "Sent Items" S: * 188 EXISTS S: * 1 RECENT S: * OK [ UIDVALIDITY 1322069043 ] S: * OK [ UIDNEXT 4411 ] S: * FLAGS ( \Answered \Flagged \Deleted \Draft \Seen ) S: * OK [ PERMANENTFLAGS ( \Answered \Flagged \Deleted \Draft \Seen \* ) ] S: A005285 OK SELECT completed [ READ-WRITE ] C: A005286 UID STORE +FLAGS (\SEEN $SENT) S: A005286 NO UID STORE Invalid parameter: +FLAGS ( 61FF ) C: A005287 SELECT "INBOX" The IMAP server is Novell Groupwise 2012.
I may be affected by a similar issue. I have my "sent mail" on the IMAP server and after sending a message it appears in the "sent mail" folder for 1 second and then disappears from the IMAP server. How do I collect an IMAP transcript to determine if I'm affected by the same issue?
set the environment file KIMAP_LOGFILE to some logfile with path, and re-start akonadi
environment variable, sorry
I found a slightly suspect IMAP sequence, but I'm not familiar enough with the protocol to determine if this is the cause of my problem or not: C: A000084 APPEND "Sent" (\Seen $SENT) {1214} S: A000084 BAD Invalid flag specified C: A000085 SELECT "Sent" S: * 391 EXISTS S: * 0 RECENT S: * OK UID validity status [ UIDVALIDITY 8742276 ] S: * OK Predicted next UID [ UIDNEXT 394 ] S: * FLAGS ( \Seen \Deleted \Answered \Forwarded \Redirected \Flagged \Hidden \Draft $MDNSent ) S: * OK Permanent flags [ PERMANENTFLAGS ( \Seen \Deleted \Answered \Forwarded \Redirected \Flagged \Hidden \Draft $MDNSent ) ] S: A000085 OK SELECT completed [ READ-WRITE ] C: A000086 UID STORE +FLAGS (\Seen $SENT) S: A000086 BAD Invalid sequence specified C: A000087 EXPUNGE S: A000087 OK EXPUNGE completed C: A000088 SELECT "Sent" S: * 391 EXISTS S: * 0 RECENT S: * OK UID validity status [ UIDVALIDITY 8742276 ] S: * OK Predicted next UID [ UIDNEXT 394 ] S: * FLAGS ( \Seen \Deleted \Answered \Forwarded \Redirected \Flagged \Hidden \Draft $MDNSent ) S: * OK Permanent flags [ PERMANENTFLAGS ( \Seen \Deleted \Answered \Forwarded \Redirected \Flagged \Hidden \Draft $MDNSent ) ] S: A000088 OK SELECT completed [ READ-WRITE ]
(In reply to comment #4) > I found a slightly suspect IMAP sequence, but I'm not familiar enough with > the protocol to determine if this is the cause of my problem or not: > C: A000084 APPEND "Sent" (\Seen $SENT) {1214} > S: A000084 BAD Invalid flag specified this is afaik the reason why your mail does not exist on the server, the APPEND command fails. No idea why. > C: A000085 SELECT "Sent" > S: * 391 EXISTS > S: * 0 RECENT > S: * OK UID validity status [ UIDVALIDITY 8742276 ] > S: * OK Predicted next UID [ UIDNEXT 394 ] > S: * FLAGS ( \Seen \Deleted \Answered \Forwarded \Redirected \Flagged > \Hidden \Draft $MDNSent ) > S: * OK Permanent flags [ PERMANENTFLAGS ( \Seen \Deleted \Answered > \Forwarded \Redirected \Flagged \Hidden \Draft $MDNSent ) ] > S: A000085 OK SELECT completed [ READ-WRITE ] > C: A000086 UID STORE +FLAGS (\Seen $SENT) > S: A000086 BAD Invalid sequence specified this is the same error as I have above, the UID STORE command is missing the actual uid. I don't know if these are related. In my case the e-mails do end up in the sent-mail folder.
The problem with unsupported flags should be solved in KDE 4.11.3 (see bug #278082 for reference). The problem with UID STORE without UID is known (I think there's another report about it somewhere), but I just seen it happen to me with a GMail account, so I'll look into it soon.
Git commit 498d6678f478bd1bd9bdc944bb790f6b16b7ade4 by Dan Vrátil. Committed on 30/10/2013 at 15:46. Pushed by dvratil into branch 'KDE/4.11'. Wait for changes from resource to be written to Akonadi before marking change as processed This fixes a problem with invalid RIDs after inter-resource moves. When there is an another changeReplay for the just moved item scheduled in the new parent resource, the item will have invalid RID (or rather RID assigned to it by the previous parent resource). It's because the ItemModifyJob dispatched from ResourceBase::changesCommitted() with the new RID is not finished yet when the next task is dispatched, and so the item in resource's EntityCache is not invalidated and the resource will use it instead of the updated one. By waiting for the ItemModifyJob dispatched from changesCommited() to finish before marking the change as processed and dispatching next task we make sure that in case the next task involves the same item the change will be stored in Akonadi and the item will be invalidated in local caches, forcing the resource to fetch the item again from Akonadi before starting the task. This fixes 'Invalid uidset' error reported by IMAP resources after the MailDispatcher agent moves the mail from local Outbox to remote Sent folder and updates it's flags. Related: bug 324807, bug 314964 FIXED-IN: 4.11.3 M +11 -5 akonadi/resourcebase.cpp http://commits.kde.org/kdepimlibs/498d6678f478bd1bd9bdc944bb790f6b16b7ade4
*** Bug 324804 has been marked as a duplicate of this bug. ***