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
- POP3 behavior on broken tcp connection John Gardiner Myers
- Re: POP3 behavior on broken tcp connection Michael S. Shappe
- Re: POP3 behavior on broken tcp connection John Gardiner Myers
- Re: POP3 behavior on broken tcp connection John Gardiner Myers
- Re: POP3 behavior on broken tcp connection Mark Crispin
- Re: POP3 behavior on broken tcp connection Steve Dorner
- Re: POP3 behavior on broken tcp connection John Gardiner Myers
- Re: POP3 behavior on broken tcp connection John Gardiner Myers
- Re: POP3 behavior on broken tcp connection Steve Dorner
- Re: POP3 behavior on broken tcp connection Marshall Rose
- Re: POP3 behavior on broken tcp connection Steve Dorner
- Re: POP3 behavior on broken tcp connection Michael S. Shappe
- Re: POP3 behavior on broken tcp connection John Gardiner Myers
- Re: POP3 behavior on broken tcp connection Marshall Rose
- Re: POP3 behavior on broken tcp connection Steve Dorner
- Re: POP3 behavior on broken tcp connection Michael D'Errico
- Re: POP3 behavior on broken tcp connection John Gardiner Myers
- Re: POP3 behavior on broken tcp connection Steve Dorner
- Re: POP3 behavior on broken tcp connection John Gardiner Myers
- Re: POP3 behavior on broken tcp connection Steve Dorner