Re: [Off Topic] Need review for POP3 extension mechanism

At 2:58 PM -0700 7/23/98, Alexey Melnikov wrote:

>Imagine, for example, that server calculates the minimal EXPIRE value for all
>users and returns it in the unauthenticated state. Let user A have
>EXPIRE value
>equal to 0 and user B has EXPIRE >0 (5 for example). Described server
>will return
>EXPIRE 0 in unauthenticated state, but it will not be the truth for user B.
>I think that something like EXPIRE USER will help to solve such problem.

If user B's client does not do another CAPA after authenticating, it
might issue a warning if user B has LMOS set, something like "Warning:
your mail server might delete messages immediately".

I don't like the idea of CAPA returning EXPIRE USER, because that
forces the client to reissue CAPA after authenticating.  I could see
perhaps adding USER as an extra token after the value parameter (EXPIRE
5 USER) to indicate that the value might be inaccurate.   But remember
we're talking POP, not IMAP, here.  We want to keep things simple.  How
many servers are going to be operating in a mode such that there is a
number-of-days-per-user expiration policy, which for some users is 0
(immediate deletion) and for others is something else?  Is it worth
cluttering the protocol to be able to do something slightly better in
those few cases?

>One question about EXPIRE 0 : Am I right that all messages will be
>deleted after
>QUIT command. What happens if client disconnects without QUIT? How client can
>prevent messages from being deleted?

EXPIRE 0 means the server MAY delete messages immediately after QUIT.
In actual practice, I would expect message expiration to happen later
in most cases, such as overnight.  The QUIT issue is really no-win.  If
we say that servers can't delete unless the client sends a QUIT,
clients will simply not send QUIT (many don't anyway).  And why should
EXPIRE 0 be different from EXPIRE 1 or EXPIRE 30?

There are widely-deployed servers today which delete messages after a
DELE has been received for them, even if the client does not send QUIT
before the connection closes, even though this is a clear violation of
POP3.

Since there are always edge cases, maybe we should cut EXPIRE from the
draft, which means we live with the status quo, at least until a
replacement draft advances.  I tend to think that would be worse,
because we simply aren't going to be able to solve 100% of the
expiration cases without complexity that doesn't belong in POP.  But if
the consensus is that that's better, I'll do it.