IETF Logo Mail Archive

Re: POP3 protocol question

Ned Freed <NED@sigurd.innosoft.com> Wed, 19 October 1994 02:17 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10867; 18 Oct 94 22:17 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10863; 18 Oct 94 22:17 EDT
Received: from PO5.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa24427; 18 Oct 94 22:17 EDT
Received: (from postman@localhost) by po5.andrew.cmu.edu (8.6.9/8.6.9) id WAA18149; Tue, 18 Oct 1994 22:00:35 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Tue, 18 Oct 1994 22:00:33 -0400 (EDT)
Received: from po2.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.Mid7p3200UdaAaSE5s>; Tue, 18 Oct 1994 21:58:29 -0400 (EDT)
Received: from sigurd.innosoft.com (SIGURD.INNOSOFT.COM [192.160.253.70]) by po2.andrew.cmu.edu (8.6.9/8.6.9) with ESMTP id VAA09843 for <ietf-pop3+@andrew.cmu.edu>; Tue, 18 Oct 1994 21:58:12 -0400
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #2001) id <01HIFD1EJGHC8ZEKJJ@SIGURD.INNOSOFT.COM>; Tue, 18 Oct 1994 18:56:46 -0700 (PDT)
Date: Tue, 18 Oct 1994 16:06:44 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: POP3 protocol question
In-reply-to: Your message dated "Mon, 10 Oct 1994 12:50:14 -0400 (EDT)" <781807814.29505.0@nifty.andrew.cmu.edu>
To: Chris Newman <chrisn+@cmu.edu>
Cc: POP3 IETF Mailing List <ietf-pop3+@andrew.cmu.edu>, Jerome Chan <yjc@po.cwru.edu>
Message-id: <01HIFKLW0MA08ZEKJJ@SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
References: <aabeb23a03015006c552@[129.22.240.99]>, <aabeb23a03015006c552@[129.22.240.99]>

> RFC-821 (SMTP) allows one to _send_ mail.  POP3 has no reason to
> duplicate this functionality.

The only argument for XTND XMIT and similar facilities that I somewhat agree
with is when you're using POP (or IMAP) directly over something like a serial
line (possibly with some sort of lightweight error correction and possibly
not). Like it or not, some environments just don't have the option of using
TCP/IP everywhere, SLIP and PPP notwithstanding.

The counter, of course, is that these are protocols specified for use over
TCP/IP and that issues that arise with other transports and their limitations
are not relevant. Its a shallow argument, in that it appeals to procedure
to justify a technical decision, but it is valid nevertheless.

It would therefore be appealing to have a "one port" protocol to use for email,
but just because its appealing is no real it has to come to pass.

				Ned

v2.23.0 | Report a Bug | By Email