Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes

Steffen Lehmann <lehmann@strato-rz.de> Wed, 09 February 2011 13:19 UTC

Return-Path: <lehmann@strato-rz.de>
X-Original-To: morg@core3.amsl.com
Delivered-To: morg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98223A69C3 for <morg@core3.amsl.com>; Wed, 9 Feb 2011 05:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.416
X-Spam-Level:
X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzpUNUccMgIv for <morg@core3.amsl.com>; Wed, 9 Feb 2011 05:19:20 -0800 (PST)
Received: from fredda.webgods.de (fredda.webgods.de [192.166.196.83]) by core3.amsl.com (Postfix) with ESMTP id ACEFF3A69B9 for <morg@ietf.org>; Wed, 9 Feb 2011 05:19:19 -0800 (PST)
Message-ID: <4D5293EB.3060509@strato-rz.de>
Date: Wed, 09 Feb 2011 14:17:31 +0100
From: Steffen Lehmann <lehmann@strato-rz.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Timo Sirainen <tss@iki.fi>
References: <4D4ACA2A.3080401@strato-rz.de> <1296844981.18488.385.camel@hurina> <4D4DBCD3.6000307@strato-rz.de> <97BC70CA-027E-4DE9-A16C-80ACF9A40883@iki.fi>
In-Reply-To: <97BC70CA-027E-4DE9-A16C-80ACF9A40883@iki.fi>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Cc: morg@ietf.org
Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes
X-BeenThere: morg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Messaging Organization <morg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/morg>, <mailto:morg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/morg>
List-Post: <mailto:morg@ietf.org>
List-Help: <mailto:morg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/morg>, <mailto:morg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Feb 2011 13:19:20 -0000

  On 06.02.2011, at  22:00, Timo Sirainen wrote:
> On 5.2.2011, at 23.10, Steffen Lehmann wrote:
>
>>> So, the client would just remember the value after the "OK". The server
>>> can use whatever value it wants there, but one simple possibility would
>>> be to just use a hash(all UIDLs).
> ..
>> But doing it using the ID as proposed raises a couple problems:
>>
>> Hashes are no unique value.
> It wouldn't have to be a hash. It was just an example.
>
>> A better way would be, the client tells the sever the tuple of
>> message-number/UIDL of the very last message it knows.
> A server implementation would be free to use that as the ID as well. It has one problem though: message UIDLs are not guaranteed to be always unique (even POP3 RFC mentions this), so this has the potential of missing changes in some situations. So I'd prefer that there was no enforcement of a specific format for the ID to allow more flexible server implementations. I doubt it's too much to ask for clients to store one extra string for it.
I agree. Using an ID offers most flexibility regarding server's
implementation.

>>  +LASTREAD: The time when the message was read the very last time.
>> In POP3, a message is to be considered as "read" after a successful RETR
>> command has been issued for that message. Reading a message with the TOP
>> command shall not mark a message as "read", even if all body lines were
>> read.
> Clients might become disconnected before RETR is complete. Server wouldn't then necessarily know if message was fully received by the client. Would that still be a successful RETR?

The server has, for my opinion, five options, when the
FIRSTREAD/LASTREAD values could be set:

1. After a  successful RETR command (just before the server sends the
terminating "." line).
2. After a  successful RETR command (just after the server has sent the
terminating "." line).
3. After a  successful RETR command, when the server receives the next
valid command,
4. After a  successful RETR command, when the server enters the UPDATE
state.
5. On behalf of the client, using any new "set" command.

All five options have a time window, each of different duration, when
something may happen, resulting in a FIRSTREAD/LASTREAD value not
representing the actual state.

Option 1:
- The client might crash before finishing message processing.
- The server might crash after it has updated the FIRSTREAD/LASTREAD
value, but before it has sent the terminating "." line.

Option 2:
- The client might crash before it has finished message processing.
- The server might crash after it has sent the terminating "." line, but
before it has updated the FIRSTREAD/LASTREAD value.

Option 3-5:
- It doesn't guarantee the client has read the message (the client could
have sent the next/QUIT/"set" command before finishing message
processing; PIPELINING could be used).
- The server might crash before the next command arrives.

Unfortunately, there is no reliable option.

But the FIRSTREAD value could be used by clients to make a decision like
"don't retrieve messages which are marked as 'already read'". Using the
FIRSTREAD value in this manner could result in never-read messages (if
the server has updated the FIRSTREAD value, but the client crashed).
On the other hand, If a FIRSTREAD values was not updated due to a server
crash, and a client has a rule like "delete never-read messages after xx
days", this could delete a message, although this message was read.
Therefore, I think,  it would be better not to introduce a FIRSTREAD
value, and to leave the UNREAD value as it is.

With the UNREAD value, things are not this dramatic as with FIRSTREAD. I
prefer option 1. Option 1 ensures, that  the UNREAD value will be
updated in any case. Even if the server has updated the UNSET value, but
the client has never seen the message (i.e. due to a crash), the updated
UNREAD value indicates that someone is still interested in this message.

The text

"The +UNREAD Flag requests to add the number of whole days, since the
message was read for last time, to the extended scan listing."

should be changed to

"The +UNREAD Flag requests to add the number of whole days, since the
message was tried to read for last time, to the extended scan listing."

-- Steffen