After sending a mail I get the following error from my IMAP resource: »Store failed, server replied: A000685 BAD Error in IMAP command UID STORE: Invalid uidset« Sometimes the mail gets stored, sometimes not. What is bad about the error message is that a user has no idea what to do with it. Reproducible: Always
I can confirm this. Having same problem. Additionally, I'm loosing the sent mail, which is painful in my case. I tried a trick: set the "sent folder" to local folder, then a filter to local folders to move message to the imap "sent" folder. Local store worked, but same result on filter action. Mail lost. I tried to move message by dragging from local folder to imap. Same result: message lost. The only case when I not loose message if I drag within same imap account. This issue started since I upgraded to 4.11 (from 4.10). these are the error messages: Append failed, server replied: A000097 NO Error in IMAP command received by server. Store failed, server replied: A000099 NO Error in IMAP command received by server. or Store failed, server replied: A000068 BAD Error in IMAP command UID STORE: Invalid uidset Of course, the imap server setup may be related. I have two account set up. First one producing the first set of error messages. I'm loosing all sent e-mail there. The second account producing the second message >sometimes<. So in this case - as the bug reporter said - sometimes working, sometimes not.
Could you please provide logs of IMAP communication? $ export KIMAP_LOGFILE=/tmp/kimap.log $ akonadictl restart This will log all IMAP communication into /tmp/kimap.log.* files. When you reproduce the problem, find the related file and upload it here. Remember to sanitize any sensitive data.
Created attachment 82762 [details] kimaplog Here is the imap log (thanks for pointing out this feature). It has both type of the error messages. You will see, one of the "Sent" folder has constantly 720 messages. Somehow I only see that body of test message which I sent via that server which actually working (mostly), but making the second type of error. The only sign about the lost message I found (in kimap.log.3407.3 for example) is: C: A000019 APPEND "INBOX.Sent" (\Seen $SENT) {426} S: A000019 NO Error in IMAP command received by server. There is an other log file from another session where you see a working filter action actually moving message inside the mailbox (not loosing these messages).
After upgrading to KDE/Kmail 4.11.2, I get the message "Store failed, server replied: A000099 NO Error in IMAP command received by server." whenever I try to send a message. However, the message is in fact stored in my sent-mail folder on the server. I am not using any filters. And I can drag items from other IMAP servers into the present one, with no errors. So my issue may be a different one than Daniel Vrátil. Besides the kmail box, I have control of the IMAP server, so I'm available for debugging if needed.
Ian, could you please provide the same information as requested in comment #2?
Created attachment 82944 [details] kimap log Attached is the requested log. KDEPIM randomly decided to retrieve headers from a bunch of years-old messages which should definitely be in the cache, so I removed everything between the CAPABILITIES command and the APPEND command. Let me know if you need something that's missing here.
Created attachment 83011 [details] The log of the reproduced problem here, same KDE version
Yeah, looks like we are sending UID STORE command without any UID to modify. I think there's a bug report about this already somewhere
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 323762, bug 314964 FIXED-IN: 4.11.3 M +11 -5 akonadi/resourcebase.cpp http://commits.kde.org/kdepimlibs/498d6678f478bd1bd9bdc944bb790f6b16b7ade4
Thank you! I'll test soon with the update release.
Since KDE4.11.x I'm experiencing similar problems: sent mail isn't always stored but simply vanishes. I don't know when exactly it started, as normally one wouldn't always check the sent folder after sending a mail; the mail should simply be there. The problem occurs often, but not always, which makes it harder to track. One test revealed this bit of log, when sending a test-mail: C: A000004 SELECT "Sent" S: * FLAGS ( \Answered \Flagged \Deleted \Seen \Draft $MDNSent KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $FORWARDED $TODO $WATCHED $IGNORED account $SENT $ATTACHMENT $REPLIED ) S: * OK Flags permitted. [ PERMANENTFLAGS ( \Answered \Flagged \Deleted \Seen \Draft $MDNSent KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $FORWARDED $TODO $WATCHED $IGNORED account $SENT $ATTACHMENT $REPLIED \* ) ] S: * 1445 EXISTS S: * 0 RECENT S: * OK UIDs valid [ UIDVALIDITY 1176506943 ] S: * OK Predicted next UID [ UIDNEXT 1973 ] S: * OK Highest [ HIGHESTMODSEQ 524 ] S: A000004 OK Select completed. [ READ-WRITE ] C: A000005 UID STORE +FLAGS (\Seen $SENT) S: A000005 BAD Error in IMAP command UID STORE: Invalid uidset Noteworhy: this was at the start of the log. It seems as if the mail never got stored at all. Also, I did see the message in the sent folder, which was the current selected folder when sending the mail. However, when I switched to inbox and back to sent, the message was gone. The mail itself is correctly sent and arrives at the destionation. Currently I use KDE Version 4.11.3 from Kubuntu's updates PPA. I believe it is a regression, but I'm not quite sure, as I've switched to KDEPIM recently, and as said, one doesn't always checks the sent folder...
I just made the error to reply an e-mail using KMail, and sure enough, my message vanished into thin air after sending. Should I reopen the bug? And is there a way to enable logging more permanently?
(In reply to Randy Simons from comment #12) > I just made the error to reply an e-mail using KMail, and sure enough, my > message vanished into thin air after sending. Should I reopen the bug? And > is there a way to enable logging more permanently? I'd certainly like to see the bug re-opened, as I'm hit but this repeatedly. Currently using 4.12.5 Here the message I actually sent is not in the log. C: A000003 SELECT "Sent" S: * FLAGS ( \Answered \Flagged \Deleted \Seen \Draft $FORWARDED $SENT $ERROR $REPLIED $SIGNED $ATTACHMENT $ENCRYPTED $INVITATION $QUEUED ) S: * OK Flags permitted. [ PERMANENTFLAGS ( \Answered \Flagged \Deleted \Seen \Draft $FORWARDED $SENT $ERROR $REPLIED $SIGNED $ATTACHMENT $ENCRYPTED $INVITATION $QUEUED \* ) ] S: * 17258 EXISTS S: * 0 RECENT S: * OK UIDs valid [ UIDVALIDITY 1138124926 ] S: * OK Predicted next UID [ UIDNEXT 17892 ] S: * OK Highest [ HIGHESTMODSEQ 950 ] S: A000003 OK Select completed ( 0.002 secs ) . [ READ-WRITE ] C: A000004 UID STORE +FLAGS (\Seen $SENT) S: A000004 BAD Error in IMAP command UID STORE: Invalid uidset
I'm still seeing this in 4.13.2.
The last few months I haven't encountered this issue anymore. I have no idea whether this is because a change in KMail, or a change in the server of my provider (postfix, unknown version), or perhaps I now simply am patient enough and wait for KMail to be done with all sending and moving stuff after sending a mail, i.e. I wait for the progress indicator to disappear after it reached 100%, before selecting another folder or mail. Currently I'm using kmail 4.13.97 from Kubuntu-backports.
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present? If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.