----- Original Message -----
From: "Iljitsch van Beijnum" <iljitsch(_at_)muada(_dot_)com>
Sent: Thursday, February 12, 2004 3:31 AM
Subject: Storage: service provider vs user
I once asked someone from an ISP why they only support POP access and
not IMAP. His answer: "we want users to download their mail". Users on
the other hand like storing their mail on the server. I think a new
protocol should include semantics to handle these conflicting goals, so
that the user agent and the server can negotiate who stores what. For
instance, the server may be prepared to store mail for a limited time
or a maximum amount. Even if they don't get to store mail on the server
forever, it's still very valuable for users to be able to keep the mail
on the server a little while after looking at it for the first time.
For instance, the user may be connecting over a slow link and not want
to download everything just yet, or the user uses several computers to
read mail and wants to make sure each of those has a copy before the
message is removed from the server. A way to track how many clients are
supposed to get copies of a message and how many have already would be
I have brought this up recently. The main reason user want it is because
they roam and also because of the higher increase of WebMail access as well.
So you can be on vacation or remote job, go to a mail station and read your
mail via the WEB or other way and then when you get home you are able to
download it using your normal POP3 MUA.
Some system policies prohibit this and for good reasons:
1) It can conflict with mail maintenance (automatic packing) policies,
2) It can conflict with "tracking" especially in subscription based systems
where a notification is sent and it isn't recorded as being received, or
with return receipts.
In other words, it requires a redesign where the server requires multiple
"received" flags in the header. One that says he received it at the system
level and one that related to the human and presented as being received.
In our system, we called the "Preview Mail" problem because that is
basically what a system will need to do if he doesn't add a multiple receive
bit concept to identify the different methods a message was previewed. One
that allows a message to be redownload and one that tells the system the
user did receive the message. The user can't lie now
"Hey, I never saw that expiration message! Why you cut me off?"
In Fidonet and I think also UUCP messages are bundled in an archive so
that someone connects it's easy to download all new messages. Do we
want something like this in the new system?
If mail-ng become more than just email, I vote for it. In Fidonet/Uucp
the bundling usually implied only to the "public forum" mail conference
distribution (Echos/News). Netmail/Email was kept separate, however,
during hub to hub routes, the direct mail could be bundled as well.
I would like to see it a concept like this, it will definitely help in
storage, streaming and distribution.
And would it be useful to create two levels of mail access: the first
level means someone gets to download the mail but it's encrypted, and
the second level means the ability to decrypt it. This way you could
ask a friend to download your mail for you, but they can't read it.
Something like this could be useful for intermittently connected
Interesting - allowing "a friend" to download your mail.