[Top] [All Lists]

Re: MS vs. pop and imap

2004-05-30 12:09:11

On 5/30/2004 8:20 AM, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

POP really does finally delivery,

No, it really does no such thing. Final delivery is a well defined
action that takes place before POP comes into the picture.

"Final delivery" is "well defined" within the context of SMTP (it occurs
when the last public transfer takes place, where no more Received headers
will be written, where the Return-Path is written, and so forth, [except
when it doesn't (*)]). SMTP only provides the "public-transport" function
for the global network of mailboxes and its terms and meanings have to be
restricted to its area of relevance.

In the context of global end-to-end messaging infrastructure, final
delivery occurs when the message reaches the storage where it will be
accessed by the recipient. This is obviously different from the last-hop
SMTP server when things like Exchange, DECmail, AOL, or other "gateway"
systems where SMTP's idea of "final destination" visibly differs from the
destination's idea of final destination. This is also somewhat obvious
with things like fetchmail that use POP to redistributed and file messages
locally. Even LMTP transfers into a local store on the same box is
different since LTMP is for private transfers (*). Another point of order
here is that SMTP and the associated specifications DO NOT SPECIFY STORAGE
FORMATS so as far as that goes, every permanent-storage end-point is via
some kind of gateway, and which is precisely why the scope of SMTP (and
its definition of "final delivery") has to be limited to the public
transfer portion of the network and treated as irrelevant otherwise.

(*) I note that the Cyrus IMAP server acts like it's part of the actual
SMTP network; it will write its own Recieved and Return-Path headers even
though it is not part of the SMTP network (it doesn't have an SMTP
listener on port 25, and LMTP on port 24 is definitely not SMTP, so...).
Sieve redirects in Cyrus redirect incoming mail without rewriting the
sender envelope, instead of generating new messages like one would expect
from a post-delivery expansion. So even where there is a pretty clear
architecture once it is divided into functional groups, exceptions exist.

Eric A. Hall                              
Internet Core Protocols