Re: MS vs. pop and imap
Pete Resnick <presnick@qualcomm.com> Sun, 30 May 2004 17:32 UTC
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4UHWswu045163; Sun, 30 May 2004 10:32:54 -0700 (PDT) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4UHWs6W045162; Sun, 30 May 2004 10:32:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4UHWrej045155 for <ietf-smtp@imc.org>; Sun, 30 May 2004 10:32:54 -0700 (PDT) (envelope-from presnick@qualcomm.com)
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.4); Sun, 30 May 2004 12:32:53 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com (Unverified)
Message-Id: <p0700110bbcdfc62210c6@[216.43.25.67]>
In-Reply-To: <1899927310.20040530095032@brandenburg.com>
References: <933985834.20040515013625@brandenburg.com> <2147483647.1084809195@nifty-jr.west.sun.com> <756569575.20040529113229@brandenburg.com> <p07001107bcdebe6a41d8@[216.43.25.67]> <01LAP28BIA9U00005R@mauve.mrochek.com> <1899927310.20040530095032@brandenburg.com>
X-Mailer: Eudora [Macintosh version 6.1a16]
Date: Sun, 30 May 2004 12:32:49 -0500
To: Dave Crocker <dcrocker@brandenburg.com>
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: MS vs. pop and imap
Cc: ned.freed@mrochek.com, Chris Newman <Chris.Newman@sun.com>, ietf-smtp@imc.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
On 5/30/04 at 9:50 AM -0700, Dave Crocker wrote: >>Final delivery is a well defined action that takes place before POP >>comes into the picture. > >As I said, that is the current view, yes. However it is not the >original view of its role. I don't buy it, and none of the text you've pointed to indicates it. >The very first POP specifications used the word "access", so that >would seem to support the position that delivery is pre-POP. Right. >Worse, the model did not have the concept of a message store, as an >independent component, so it was difficult to talk about this point. >A module was either a UA or an MTA. Posting and Delivering were the >actions between them. No. I disagree completely. Think about the UA's pre-POP. Things like /bin/mail and ELM. They acted on the MS to read messages, delete messages from the store, move messages to different places, and reply to messages. Remember, all messages were delivered to a single MS (at the time, "the spool") where a UA could manipulate those messages. They had no part of delivery to that spool. (Posting is different; more on that later.) >In any event, POP was definitely for _moving_ messages from the >server to the client. Sort of, but not precise enough for the point: POP was for moving messages from the machine where the MS lived to a UA which, for the first time, was on a different machine. Using "client" and "server" clouds the issue here. They are a "POP client" and a "POP server", but they were not "mail transport servers". >Note that the current spec observes the change/addition of retention >on the server: I don't see anything in that quote from 1939 sec. 8 that supports your point. POP back to 1081 always had the DELE command. The only operational change the quote points out is that, unlike traditional UAs like /bin/mail, where users usually got things out of the mail spool and put them into private disk space, people started using POP to leave lots of stuff in the mail spool as permanent storage. That doesn't change the MS as separate from UA model. >As for the question of "delivery" versus "access" in the sense that >we mean it today, going back to by RFC1081 (1988): > >rfc1081> Introduction >rfc1081> >rfc1081> On certain types of smaller nodes in the Internet it is often >rfc1081> impractical to maintain a message transport system (MTS). For >rfc1081> example, a workstation may not have sufficient resources (cycles, >rfc1081> disk space) in order to permit a SMTP server and associated local >rfc1081> mail delivery system to be kept resident and continuously running. >rfc1081> Similarly, it may be expensive (or impossible) to keep a personal >rfc1081> computer interconnected to an IP-style network for long amounts of >rfc1081> time (the node is lacking the resource known as "connectivity"). >rfc1081> >rfc1081> Despite this, it is often very useful to be able to manage mail on >rfc1081> these smaller nodes, and they often support a user agent >(UA) to aid >rfc1081> the tasks of mail handling. Of course, you skip the key next sentence: To solve this problem, a node which can support an MTS entity offers a maildrop service to these less endowed nodes. The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. A "maildrop service" *is* the MS. Old UAs used to access the MS directly and that POP is provide distant UAs the ability to access the MS remotely. That model is completely apparent in 1081. >...folks seem to be missing my distinction between POP's original >intent versus current usage. Not at all. Speaking for myself, I think you're just mistaken about original intent. See above quote from 1081. I agree that the model at that time wasn't precise, but if "maildrop service" doesn't mean the same thing as "Message Store" in the way we've been talking about it, I don't know what else it could mean. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
- Re: MS vs. pop and imap Eric A. Hall
- Re: Internet Mail Architecture draft Valdis.Kletnieks
- Re: MS vs. pop and imap Cyrus Daboo
- Re: MS vs. pop and imap ned+ietf-smtp
- Re: MS vs. pop and imap Dave Crocker
- Re: MS vs. pop and imap (alternate response) Dave Crocker
- Re: MS vs. pop and imap (alternate response) Hector Santos
- Re: MS vs. pop and imap (alternate response) Pete Resnick
- Re: MS vs. pop and imap Eric A. Hall
- Re: MS vs. pop and imap (alternate response) Cyrus Daboo
- Re: MS vs. pop and imap (alternate response) Pete Resnick
- Re: MS vs. pop and imap ned+ietf-smtp
- Re: MS vs. pop and imap (alternate response) Dave Crocker
- Re: MS vs. pop and imap Pete Resnick
- Re: MS vs. pop and imap Dave Crocker
- Re: MS vs. pop and imap ned+ietf-smtp
- Re: MS vs. pop and imap Hector Santos
- Re: MS vs. pop and imap Cyrus Daboo
- Re: MS vs. pop and imap Pete Resnick
- Re: Internet Mail Architecture draft Eric A. Hall
- Re: Internet Mail Architecture draft Dave Crocker
- Re: MS vs. pop and imap Eric A. Hall
- Re: Internet Mail Architecture draft Eric A. Hall
- MS vs. pop and imap Dave Crocker
- Re: Internet Mail Architecture draft Cyrus Daboo
- Re: Internet Mail Architecture draft Dave Crocker
- Re: Internet Mail Architecture draft Dave Crocker
- Re: Internet Mail Architecture draft Eric A. Hall
- Re: Internet Mail Architecture draft Chris Newman
- Re: Internet Mail Architecture draft Dave Crocker
- Re: Internet Mail Architecture draft Paul Overell
- Internet Mail Architecture draft Dave Crocker
- Re: MS vs. pop and imap Keith Moore
- Re: MS vs. pop and imap Valdis.Kletnieks
- Re: MS vs. pop and imap (alternate response) Dave Crocker
- Re: MS vs. pop and imap (alternate response) Tony Finch
- Re: MS vs. pop and imap (alternate response) Dave Crocker
- Re: MS vs. pop and imap Tony Finch
- Re: MS vs. pop and imap Tony Finch
- Re: MS vs. pop and imap (alternate response) Tony Finch
- Re: MS vs. pop and imap Dave Crocker
- Re: Internet Mail Architecture draft -- consensus… Richard O. Hammer
- Re: MS vs. pop and imap John C Klensin