34 lines
1.4 KiB
Plaintext
34 lines
1.4 KiB
Plaintext
MBOX-Line: From alexey.melnikov at isode.com Thu Jan 24 08:21:33 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Alexey Melnikov <alexey.melnikov@isode.com>
|
|
Date: Fri Jun 8 12:34:50 2018
|
|
Subject: [Imap-protocol] Courier bug(?)
|
|
In-Reply-To: <CAC4RtVAobTOjLdLH++_qp=HCtdZJne5Q7TUF_P=9J6a+gg2fmQ@mail.gmail.com>
|
|
References: <20130121144822.Horde.kbr5Y8IKwMlD1fH1Qun9hQ1@bigworm.curecanti.org>
|
|
<CAKHUCzwJ8xq7O8vGDHe0D9Jviac06o-QtePMhKYV7HzwzRPMPA@mail.gmail.com>
|
|
<1358846428.12608.2.camel@hurina>
|
|
<CAC4RtVAobTOjLdLH++_qp=HCtdZJne5Q7TUF_P=9J6a+gg2fmQ@mail.gmail.com>
|
|
Message-ID: <51015F8D.8020300@isode.com>
|
|
|
|
On 24/01/2013 15:51, Barry Leiba wrote:
|
|
>> Assuming it was unilaterally sent FETCH and not a normal reply for
|
|
>> setting the \Seen flag by UID FETCH BODY[], I agree.
|
|
> I contend that it doesn't matter *why* the server sent the flags
|
|
> response.
|
|
|
|
Indeed.
|
|
|
|
> The flag change was caused by the FETCH BODY, but the fact
|
|
> is that your UID FETCH command did not *ask* for FLAGS, so there's
|
|
> *no* requirement that the server send the flags as part of that
|
|
> response. And once you detach it that way, the server can do what it
|
|
> wants.
|
|
>
|
|
> If, as a client, you want to head off this situation, the way to do it
|
|
> is to ask for FLAGS in addition to BODY.
|
|
|
|
An alternative is to keep message numbers for the duration of a UID
|
|
FETCH and correlate multiple FETCH responses that way.
|
|
|
|
|