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