Re: POP3 behavior on broken tcp connection

[John Gardiner Myers <[e-mail]>]

Mark Crispin <[e-mail]> writes:
> There are two interpretations:
> 1) POP deletions set a per-message mailbox flag, which other applications can
>    see and respect.  Only an operation such an a POP QUIT or an IMAP EXPUNGE
>    will actually destroy the messages.
> 2) POP deletions set a per-message session flag, which other applications will
>    never see.  This session flag governs the behavior of the QUIT command of
>    that session.

Presently, I implement (2).  I'm leaning towards thinking the
specification should require (2) if it doesn't already.

> The biggest drawback with (1) seems to be that most POP clients soil their
> pants when they find that messages are pre-deleted at startup. 

I think pre-deleted messages should be prohibited by the spec.

> For this
> reason, I found myself compelled to make initially deleted messages be
> invisible through a mapping table; you can get at such messages with IMAP but
> not with POP.

This is reasonable.  My POP3 implementation simply chooses to
ignore the IMAP \Deleted flag altogether.

> Either way, this POP client screwup has the effect that a POP QUIT
> can destroy many more messages than the POP client is aware of; POP QUIT does
> a c-client expunge which destroys all deleted messages.  The only way I can
> think around it is to undelete the invisible messages temporarily, expunge,
> then redelete them.  But there's a window of vulnerability in this due to
> timing races....

My implementation's expunge routine can take a function pointer which
is called to decide which messages to remove.  The POP3 server
supplies a function that ignores the IMAP \Deleted flag, instead
basing its decision soely on the per-session POP3-deleted state.

-- 
_.John G. Myers		Internet: [e-mail]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up