Re: POP3 behavior on broken tcp connection

Michael D'Errico <Mike@software.com> Fri, 03 June 1994 20:45 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11430; 3 Jun 94 16:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11426; 3 Jun 94 16:45 EDT
Received: from PO5.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa18251; 3 Jun 94 16:45 EDT
Received: (from postman@localhost) by po5.andrew.cmu.edu (8.6.7/8.6.6) id QAA25359; Fri, 3 Jun 1994 16:19:09 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Fri, 3 Jun 1994 16:19:05 -0400 (EDT)
Received: from po2.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.AhvszeW00UdaJMA05t>; Fri, 3 Jun 1994 16:17:48 -0400 (EDT)
Received: from rome.software.com (rome.software.com [198.17.234.2]) by po2.andrew.cmu.edu (8.6.7/8.6.6) with ESMTP id QAA22555 for <ietf-pop3+@andrew.cmu.edu>; Fri, 3 Jun 1994 16:17:27 -0400
Received: from rome (rome.software.com [127.0.0.1]) by rome.software.com with ESMTP id AAA9030 for <ietf-pop3+@andrew.cmu.edu>; Fri, 3 Jun 1994 13:07:20 -0700
To: POP3 IETF Mailing List <ietf-pop3+@andrew.cmu.edu>
Subject: Re: POP3 behavior on broken tcp connection
Date: Fri, 03 Jun 1994 13:07:19 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Michael D'Errico <Mike@software.com>
Message-ID: <19940603210720.AAA9030@rome.software.com>

I agree with Marshall that no messages should be deleted because
of a broken connection.

If we add the UIDL command as proposed, the problems of having
a connection break are solved along with the previously noted
problems related to LAST and the "Status:" hack.

I could probably add UIDL to my POP server in about a half hour
so I'm all for it.  Does anybody see it as being difficult to
add to theirs?

The following hypothetical scenario shows how UIDL can be used
by a client to figure out that it has already seen a message in
case it isn't obvious to someone:

	[client connects and logs in]
	C: STAT
	S: +OK 2 3826
	C: UIDL
	S: +OK
	S: 1 19940603172145.AAA8293@ANDREW.CMU.EDU
	S: 2 19940603180614.AAA8463@mx1.cac.washington.edu
	S: .
	C: RETR 1
	S: +OK
	...
	S: .
	C: DELE 1
	S: +OK
	C: RETR 2
	S: +OK
	...
	[connection dies]

later....

	[client connects and logs in]
	C: STAT
	S: +OK 4 8477
	C: UIDL
	S: +OK
	S: 1 19940603172145.AAA8293@ANDREW.CMU.EDU
	S: 2 19940603180614.AAA8463@mx1.cac.washington.edu
	S: 3 19940603180924.AAB8502@nic.cerf.net
	S: 4 19940603181503.AAA8771@rome.software.com
	S: .
	C: DELE 1
	S: +OK
	C: RETR 2
	S: +OK
	...

Notice that the client can immediately recognize that it has
retrieved the first message and can delete it immediately.


Michael D'Errico
mike@software.com