ietf-smtp
[Top] [All Lists]

Re: MS vs. pop and imap

2004-05-30 02:33:56


----- Original Message ----- 
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Chris Newman" <Chris(_dot_)Newman(_at_)Sun(_dot_)COM>
Cc: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Saturday, May 29, 2004 2:32 PM
Subject: MS vs. pop and imap


Here's why:

POP really does finally delivery, "moving" messages from upstream to
downstream -- to choose some neutral terms. By contrast, IMAP does
"copying" from upstream to downstream. That is, POP changes where the
message actually resides. It is eliminated from the upstream. As a core
construct, IMAP leaves the message on the upstream host and simply
provides a copy to the MUA.

This is not true in general Dave.  POP3/IMAP are just mechanisms and System
Mail Policies can not be altered by POP3/IMAP or in general client commands.
This is discussed in the POP3 RFC and most POP3 clients (like Outlook)
provide on-line help telling the user that their POP3 "Leave Mail On Server"
download options may not be honored.  See POP3 RFC 1939  "8. Scaling and
Operational Considerations"

In fact, POP3 has violated many traditional hosting systems where "Mail
Previewing" was secured or a priverledged access (i.e, Sysops only).   Mail
previewing is now pretty much requirement in order to offer POP3 vs HTML
roaming users access to reread the same mail from multiple sites.  It
altered our secured design where mail marking, auditing and tracking was a
security requirement.  I.e, Admin sends a "Payment Notice" and the user now
says he need saw it because he was able to preview it without marking it as
read or bypassing the return receipt trigger.  POP3 allows for this behavior
and hosting systems need to take that into account.

.... strikes me as too much about implementation and not enough about
architecture.

Thoughts?

You're trying to "map"  (excuse the pun) access methods to backends.   Some
system, such as our system, has the following different "access" methods:

- Text Mode (Dialup/Telnet) Mail Access
- Web Mail Client Access
- Windows GUI Frontend Mail Access
- QWK, RIME, Offline Mail Systems
- Peer To Peer Mail Distribution (Fidonet)
- POP3 Client Access
- News Client Access
- WEB Service Mail API
- or 3rd party native language mail API access

etc.  So whether its POP3 or IMAP or what have you,  regardless of how the
mail is accessed, it can not violate the security of the backend.  No client
can "Preview" or "Delete" the mail unless the admin provides the security
for it.

In my view, they all provide "copies" to the MUA and only if the MUA says to
delete the mail, does it make an attempt, and whether it works or not
depends on the backend.  For example, the POP3 delete command can actually
translate to a server function of marking the mail as "Received" instead.

Of course, you can have a backend with a mail storage designed with POP3
100% in mind, having the POP3 client control every aspect of the
maintenance.  But in general, your client design is based on what the server
provides.  POP3 and IMAP are just 2 or many ways backend servers offer mail
access.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



<Prev in Thread] Current Thread [Next in Thread>