ietf-smtp
[Top] [All Lists]

Re: MS vs. pop and imap (alternate response)

2004-05-30 21:35:14


----- Original Message ----- 
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Sunday, May 30, 2004 1:36 PM
Subject: Re: MS vs. pop and imap (alternate response)


1. How do we model the components and downstream interactions of srv1
and pc1:
...

  pc1 does not retain any messages. Repeated readings of the same
  message require repeated retrievals from srv1.

2. How do we model the components and downstream interactions of srv2
and pc2:

....

  Messages are retained on pc1 and not on srv1.

Dave, this (both designs) is a very fundamental issue with our system.  I
can only speak on how we do it.  Can it be modeled generically?   Maybe, but
I think the issue is that the mail policies or the expectations of the
clients may not be honored.  This is important today especially in the era
of legitation and corporate mail retaintion policies

First, again, strong mail policies can not be voilated by clients.  So #2
would be a foriegn or "loose" server design by my standards.

However, from the MUA standpoint, it looks like a "Deletion" or physical
transfer of storage location.

The following goes back to the days where older traditional "access" did not
have offer "preview" or "delete" mail options.  (As a side note, keep in
mind these end-user "features" can have a major effect on the server mail
maintenance.   This is a major consideration.)

So for our system we have options such as:

      "[X] Mark Downloaded Mail as Received"
      "[X] Allow Mail Previewing (for non-POP3 clients)"
      "[X] Allow Mail Deletion"

What this does is basically define how the #1 and #2 behind, especially how
the PC1 "Repeated Reading" of the same mail is "emulated"

Lets forget the server side for the moment and thing purely MUA, such as
POP3:

PC1 with "[X] Leave Mail On Server" options
              Number of Days ___
              [X] When Deleted

      MTA
       |
       |
     MESSAGES
       |
       |
    PC1 LISTNEW
        DNLDNEW
        KILLOLD (based on MUA "Leave Mail On Server" Options)

PC1 with "[_] Leave Mail On Server"

      MTA
       |
       |
     MESSAGES
       |
       |
    PC1 LISTNEW
        DNLDNEW
        KILLOLD

Also keep in mind that MUAs like Outlook will have a F1 help on the "Leave
Mail On Server" options that says basically the options may not be honored.

But as we discovered, the market pressure is quite certainly there to
support the "roaming user" concept who want to read their mail from vacation
or remote job sites via web mail or their LapTop POP3 client but do not want
to loose the downloading at the home based PC.   So an preverledged option
of "mail snooping" had to be allowed without losing mail auditing, tracking,
signaling capabilities on the server.  The last thing we wanted was to have
a system sent "Subscription Expiration Payment Notices" and then the "mail
snooping" allowed the user to bypass any indication that the mail was
actually received.

So with Model #1 and #2, it all depends on how the above server options are
set.

What this means is that the LISTNEW command may list trully new mail along
with mail already downloaded but not marked received.  We call this the
user's "Direct Mail Chain"   If the server allows for mail snooping,  then
download mail is not removed from the chain.

What this means is that the DNLDNEW command may or may not mark the
message received

and finally, what this means is th KILLOLD command may or may not delete the
message. It
might mark the message received.

This might be a implementation issue, but what it all basically means (in my
view) is that the LISTNEW may not be honored.

In the eyes of the MUA, when it does a LISTNEW,  the list of ids it sees is
for its own management. It determines what is actually new and from the list
of ids that are not already recorded, it sends the DNLDNEW command.   But if
the server is going to disallow mail previewing/snooping, etc, the LISTNEW
will only have unread new mail ids - which is not what roaming users want.

I hope this make some sense and not too much of a specific design, but I
think it is generic design consideration with any high-end mail server that
has strong mail policies and more important, multiple access methods, not
just POP3 like systems.     If a system does not want any mail previewing
whatsoever, the last thing the admin wants to control this via Console, GUI,
clients, only to be bypassed by POP3.

Also, keep in mind, may not be important, but in POP3, it has the UPDATE
process.  This is very important and it basically means that server side
mail markings can only be done when the QUIT command is issued.   So if PC1
download a message and ungracefully aborts or does not issue the QUIT
command, the server will not record the download.









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