No, it really does no such thing. Final delivery is a well defined action
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.
While the historical role may be interesting in an academic sense, I have to
say I don't regard it as particularly relevant to the current exercise, which
is to document the current architecture, not one that's lost in the mists of
time, assuming it ever existed at all.
The very first POP specifications used the word "access", so that would
seem to support the position that delivery is pre-POP. However those
documents did not really talk about email models and no one was trying
to be so precise with the model and terminology, back then.
Even if I were to grant that ancient POP specifications are relevant (I don't),
they do not in fact support the reading you claim. For example, the
introduction to RFC 918 states:
The intent of the Post Office Protocol (POP) is to allow a user's workstation
to access mail from a mailbox server. It is expected that mail will be posted
from the workstation to the mailbox server via the Simple Mail Transfer
Protocol (SMTP). For further information see RFC-821  and RFC-822 .
To be sure, the word "access" is used here, but in the context of "access to a
mailbox server". Not "access to a delivery agent", "access to a message queue",
or anything similar. And the term "delivery" was in use at the time - it
appears throughout RFC 821, of course.
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 mailbox server along with a collection of mailboxes is pretty darned close
IMO. So the concept in some form dates back to at least 1984 in the RFC series.
module was either a UA or an MTA. Posting and Delivering were the
actions between them.
The word "deliver" does not appear in RFC 918. You'd think that if POP was
intended to be a delivery process the word would have come up at least once.
In any event, POP was definitely for _moving_ messages from the server
to the client.
Not exclusively it isn't. Again, if it were the option to leave mail on the
server would not exist. Instead there would be some form of transactional
handoff and there would be no need for unique identifers so clients
can tell what messages they have downloaded.
Note that the current spec observes the change/addition
of retention on the server:
rfc1939> 8. Scaling and Operational Considerations
rfc1939> Since some of the optional features described above were added to
rfc1939> POP3 protocol, experience has accumulated in using them in large-
rfc1939> scale commercial post office operations where most of the users
rfc1939> unrelated to each other. In these situations and others, users
rfc1939> vendors of POP3 clients have discovered that the combination of
rfc1939> the UIDL command and not issuing the DELE command can provide a
rfc1939> version of the "maildrop as semi-permanent repository"
The optional features weren't added to make things like leaving mail on the
server possible. The fact of the matter is that these things were being done
basically from the get-go. The problem is that without UIDL it can only be done
badly. UIDL makes it possible to do leave mail on server "well".
As for the question of "delivery" versus "access" in the sense that we
mean it today, going back to by RFC1081 (1988):
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> 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
rfc1081> the tasks of mail handling.
Nothing here says or even implies that POP is going to take over the task of
performing final delivery.
rfc1081> The POP and the Split-UA model
rfc1081> The underlying paradigm in which the POP3 functions is that of a
rfc1081> split-UA model. The POP3 client host, being a remote PC based
rfc1081> workstation, acts solely as a client to the message transport
rfc1081> It does not provide delivery/authentication services to others.
That last line is the only place we get a statement that has a statement
involving the model as precisely as we are using it now.
See above. There are statements as far back as RFC 918 that describe something
quite close to the current model.
Which is why all the original work on so-called "timely delivery" in the
never panned out.
First of all, folks seem to be missing my distinction between POP's
original intent versus current usage.
On the contrary, I see the distinction you're attempting to make. I just don't
buy it and even if I did buy it I don't think it is particularly relevant. The
intent of POP was explicitly stated almost 20 years ago to access mailboxes on
a mailbox server. And most of the implementations of POP since then have been
one of a server that sits on top of a bunch of mailboxes - exactly what
RFC 918 talked about and one form of the things we now call "message
And the reference to the fax work is both ironic and wrong. First, the
fax effort underscored the problem with having the DSN mechanism stop
before POP and the need to have POP more capable in the role of
I never said it wasn't a problem. However, it is a problem precisely because
POP wasn't designed for the use the fax folks wanted to put it to, and it is
much harder than it first appears to change it.
In any case, I believe the diagram Cyrus proposed is pretty much on target.