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

Timo Sirainen <> Sun, 06 February 2011 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6FC43A69DA for <>; Sun, 6 Feb 2011 13:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.999
X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y92tjD2O3tpn for <>; Sun, 6 Feb 2011 13:00:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 293363A69AE for <>; Sun, 6 Feb 2011 13:00:29 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTP id 538C7FA8A4F; Sun, 6 Feb 2011 23:00:29 +0200 (EET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Timo Sirainen <>
In-Reply-To: <>
Date: Sun, 6 Feb 2011 23:00:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <1296844981.18488.385.camel@hurina> <>
To: Steffen Lehmann <>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Messaging Organization <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Feb 2011 21:00:31 -0000

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.

>  +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?