summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDavid Llewellyn-Jones <david.llewellyn-jones@jolla.com>2019-03-25 07:49:34 -0400
committerDavid Llewellyn-Jones <david.llewellyn-jones@jolla.com>2019-04-04 06:57:57 +0000
commit4c0d7776811ab2b261a672ad748e739cec62becf (patch)
tree71fe6a00a3367fc07df26bff58435af735625159
parent2e146e56182c1de46bb20a61272296443c9eb0ee (diff)
Decrease exists count on EXPUNGE
According to the IMAP spec (RFC3501), EXPUNGE messages indicate a decrease by one in the number of messages on the server, and the server doesn't have to notify the client of this decrease with a separate EXISTS message (from Section 7.4.1): > The EXPUNGE response also decrements the number of messages in the > mailbox; it is not necessary to send an EXISTS response with the new > value. Moreover an EXISTS message cannot be used on its own to indicate that the number of messages has reduced (from Section 5.2): > Special rules exist for server notification of a client about the > removal of messages to prevent synchronization errors; see the > description of the EXPUNGE response for more detail. In particular, > it is NOT permitted to send an EXISTS response that would reduce the > number of messages in the mailbox; only the EXPUNGE response can do > this. Currently when messageserver receives an EXPUNGE message it doesn't decrease the number of messages recorded in the 'exists' count. This can cause the number recorded by the client and server to become desynchronised, because some server implementations don't send an EXISTS directly after an EXPUNGE (which is consistent with the spec as summarised above). This can cause problems when using IDLE connections, because an EXISTS message sent on an IDLE connection will only trigger a new mail event if the number of messages indicated by the server is greater than the number recorded by the client. Therefore if the server sends an EXPUNGE message that isn't followed by an EXISTS message, the client will record a higher 'exists' value than the number on the server. When a new message arrives at the server, the server will notify the client with an EXISTS message, which the client will then erroneously ignore. This change fixes the issue by decreasing the 'exists' variable by one every time an EXPUNGE message is received. Change-Id: I00495bb83776f2320754d58ae0ec4b091f90c182 Reviewed-by: Damien Caliste <dcaliste@free.fr> Reviewed-by: Matthew Vogt <matthew.vogt@qinetic.com.au> Reviewed-by: Christopher Adams <chris.adams@jollamobile.com>
-rw-r--r--src/plugins/messageservices/imap/imapprotocol.cpp9
1 files changed, 8 insertions, 1 deletions
diff --git a/src/plugins/messageservices/imap/imapprotocol.cpp b/src/plugins/messageservices/imap/imapprotocol.cpp
index 630b16ed..4df62a57 100644
--- a/src/plugins/messageservices/imap/imapprotocol.cpp
+++ b/src/plugins/messageservices/imap/imapprotocol.cpp
@@ -1401,10 +1401,17 @@ void SelectedState::untaggedResponse(ImapContext *c, const QString &line)
int start = 0;
QString temp = token(line, '(', ')', &start);
c->setPermanentFlags(temp.split(' ', QString::SkipEmptyParts));
+ } else if (line.indexOf("EXPUNGE", 0, Qt::CaseInsensitive) != -1) {
+ quint32 exists = c->exists();
+ if (exists > 0) {
+ --exists;
+ c->setExists(exists);
+ } else {
+ qWarning() << "Unexpected expunge from empty message list";
+ }
} else {
ImapState::untaggedResponse(c, line);
}
- // TODO consider unilateral EXPUNGE notifications
}