Re: POP3 behavior on broken tcp connection

John Gardiner Myers <jgm+@cmu.edu> Fri, 03 June 1994 17:24 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08831; 3 Jun 94 13:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08827; 3 Jun 94 13:24 EDT
Received: from ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa13054; 3 Jun 94 13:24 EDT
Received: (from postman@localhost) by andrew.cmu.edu (8.6.7/8.6.6) id NAA06651; Fri, 3 Jun 1994 13:17:10 -0400
Received: via switchmail; Fri, 3 Jun 1994 13:17:10 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.IhvqJAq00WBw0=PE5v>; Fri, 3 Jun 1994 13:16:01 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr7/jm36/.Outgoing/QF.chvqIwK00WBw076axi>; Fri, 3 Jun 1994 13:15:40 -0400 (EDT)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 3 Jun 1994 13:15:38 -0400 (EDT)
Message-ID: <shvqIuC00WBw876aka@andrew.cmu.edu>
Date: Fri, 03 Jun 1994 13:15:38 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers <jgm+@cmu.edu>
To: POP3 IETF Mailing List <ietf-pop3+@andrew.cmu.edu>
Subject: Re: POP3 behavior on broken tcp connection
In-Reply-To: <aa14de0601021016d0e2@Untitled>
References: <aa14de0601021016d0e2@Untitled>
Beak: Is

The current situation, where some servers remove deleted messages on a
broken connection and other servers don't, is not safe.  We have to
resolve this ambiguity one way or the other.

Steve Dorner has presented a pretty sound technical reason why the
ambiguity should not be resolved such that messages are not deleted.
The only other way I can see to resolve his concern is to add an
"expunge" type command.

I have yet to see any objections to removing deleted messages fleshed
out properly.  As previously mentioned, disks can die after the QUIT
command is sent.  A robust client need not send DELE commands until it
has the messages safely checkpointed.

I personally prefer solutions which leave the protocol smaller and
simpler.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up