diff options
author | David Llewellyn-Jones <david.llewellyn-jones@jolla.com> | 2019-03-25 07:49:34 -0400 |
---|---|---|
committer | David Llewellyn-Jones <david.llewellyn-jones@jolla.com> | 2019-04-04 06:57:57 +0000 |
commit | 4c0d7776811ab2b261a672ad748e739cec62becf (patch) | |
tree | 71fe6a00a3367fc07df26bff58435af735625159 | |
parent | 2e146e56182c1de46bb20a61272296443c9eb0ee (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.cpp | 9 |
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 } |