67 lines
3.0 KiB
Plaintext
67 lines
3.0 KiB
Plaintext
MBOX-Line: From mrc+imap at panda.com Wed Dec 7 09:13:01 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <mrc+imap@panda.com>
|
|
Date: Fri Jun 8 12:34:47 2018
|
|
Subject: [Imap-protocol] [noob] notification of deleted/expunged messages?
|
|
In-Reply-To: <1323259286.1981.140661008567313@webmail.messagingengine.com>
|
|
References: <A891B744-87A2-42A5-9A02-81E212A9AB2E@mac.com>
|
|
<80779123-5707-46B5-80E9-F90412A013BD@iki.fi>
|
|
<1323259286.1981.140661008567313@webmail.messagingengine.com>
|
|
Message-ID: <alpine.OSX.2.00.1112070846440.931@hsinghsing.panda.com>
|
|
|
|
On Wed, 7 Dec 2011, Bron Gondwana wrote:
|
|
> Nothing stopping you returning an error if someone tries to access the earlier messages
|
|
> of course - you just need to retain their "position" in the msgid list until the
|
|
> protocol allows you to send notice of the expunge.
|
|
|
|
Although a server is permitted to do that by the specification, it should
|
|
not.
|
|
|
|
Clients don't expect such errors.
|
|
|
|
It is MUCH better if the server keeps the message data accessible in the
|
|
session until such time as an EXPUNGE can be sent. My implementation calls
|
|
these "ghost messages", because their only existance is as ephemerons in
|
|
that session (new sessions do not see them) and only until that session
|
|
sends an EXPUNGE or is terminated.
|
|
|
|
Think of how horrible it would be if, while you had a file open, suddenly
|
|
read() were to fail because someone did an unlink() on the file.
|
|
|
|
This should not be a substantial burden on the server, although it may
|
|
require a bit more effort on the part of the server author to get it
|
|
right.
|
|
|
|
The convenience of a server author, to be able to do something quick and
|
|
dirty, should take second place to the need of a client author to have
|
|
reliable server behavior.
|
|
|
|
Also, in case you worry about ephemeral messages constipating your server:
|
|
|
|
No client should keep a server on the lurch with ephemerons for more than
|
|
a short period of time. A client may do several consecutive commands in a
|
|
pipeline without giving the server an EXPUNGE opportunity, but it should
|
|
NEVER go idle on the command stream before doing so.
|
|
|
|
In my opinion, it is alright for a server to protect itself from abusive
|
|
client behavior by disconnecting, etc. if it's stuck with ephemerons for
|
|
more than a reasonable amount of time. Given that IDLE explicitly disposes
|
|
of these, it's only an issue with a NOOP-polling client.
|
|
|
|
Most NOOP-polling clients do so every 1-3 minutes, and IMAP's maximum
|
|
inactivity period is 30 minutes. Certainly a client that wakes up at
|
|
minute 29, but does not allow an EXPUNGE opportunity, is abusive and
|
|
deserves to lose its session. 15 minutes as the maximum "let me get rid of
|
|
my ephemerons or I disconnect you" time is probably quite good enough.
|
|
|
|
Remember that this isn't an issue with IDLE; it's only for polling
|
|
clients. Most polling clients will not go idle that long since that would
|
|
be likely to provoke a NAT into disconnecting.
|
|
|
|
-- Mark --
|
|
|
|
http://panda.com/mrc
|
|
Democracy is two wolves and a sheep deciding what to eat for lunch.
|
|
Liberty is a well-armed sheep contesting the vote.
|
|
|