52 lines
2.3 KiB
Plaintext
52 lines
2.3 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Mon Nov 7 00:18:42 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:47 2018
|
|
Subject: [Imap-protocol] [noob] select & unseen?
|
|
In-Reply-To: <alpine.OSX.2.00.1111061650360.9034@hsinghsing.panda.com>
|
|
References: <C61A1BDF-03DD-4ED9-BFCA-C6183F07DD3E@mac.com><4EB72A0C.31264.813832F8@David.Harris.pmail.gen.nz>
|
|
<alpine.OSX.2.00.1111061650360.9034@hsinghsing.panda.com>
|
|
Message-ID: <1320653922.13384.140660995615489@webmail.messagingengine.com>
|
|
|
|
|
|
|
|
On Sunday, November 06, 2011 5:11 PM, "Mark Crispin" <mrc+imap@panda.com> wrote:
|
|
> On Mon, 7 Nov 2011, David Harris wrote:
|
|
> > Simple commonsense dictates that the
|
|
> > intention of the RFC must be that [UNSEEN] is mandatory *if the
|
|
> > mailbox contains any unread messages*, but that it *must* in fact be
|
|
> > *omitted* otherwise.
|
|
>
|
|
> David is correct; a little bit of common sense goes a long way. That seems
|
|
> to be lacking in certain individuals who, given a choice between a common
|
|
> sense answer and an absurd answer, invariably choose the absurd.
|
|
|
|
RFC 3501 says " If this is missing, the
|
|
client can not make any assumptions about the first
|
|
unseen message in the mailbox, and needs to issue a
|
|
SEARCH command if it wants to find it. "
|
|
|
|
That means there is NO WAY for the server to communicate "there are no
|
|
unseen messages in this mailbox" in an unambiguous way.
|
|
|
|
> Such was the UNSEEN response. RFC 4731 is a far superior mechanism
|
|
> (although it has its own warts). I would be very surprised if any client
|
|
> uses the UNSEEN response (its intended purpose was to position the view at
|
|
> the first unread message). The client that used it has to fetch the flags
|
|
> for all messages anyway for other purposes, so it doesn't need it any
|
|
> more.
|
|
|
|
Unfortunately, all these warts are required to be supported - and common sense
|
|
is a cop-out. There is no reading of RFC3501 which gives a correct answer to
|
|
this - hence my assertion that a fully complient server is required to
|
|
immediately disconnect any client issuing a "SELECT" for a mailbox which doesn't
|
|
contain unseen messages. They can always append a new message to the mailbox
|
|
and make sure they don't mark it seen if necessary.
|
|
|
|
Bron ( workarounds 'r' us )
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|
|
|