Did POP3 servers ever auto-delete mail after retrieval?
Rob
If I read them correctly, none of the main POP3 RFCs (1081, 1225,
1460, 1725, and 1939) call for automatic mail deletion by the server
once mail has been retrieved by the client.
In each case, the mail client has to specifically command the server
to delete mail, and doesn't need to send a given command to require
that it's saved.
Am I correct about this?
I've also been trying to find out if, historically, any major server
implementations have done this, or if it's just a no-no (a violation
of the RFC). I had trouble finding that information on Google.
My reason for asking is that in a lecture for a networking course, the
professor stated that one reason IMAP was created was so that clients
could access mail from different workstations. He says that older
POP3 servers would delete mail automatically after the client had
downloaded it. (IMAP was created to replace POP2, right?)
Any help on this would be helpful. The class just started and I'm
wondering if I should be worried about "learning wrong." :)
Thanks,
Rob (remove 'just' in address to reply by mail)
Mark Crispin
> If I read them correctly, none of the main POP3 RFCs (1081, 1225,
> 1460, 1725, and 1939) call for automatic mail deletion by the server
> once mail has been retrieved by the client.
Correct. An explicit DELE command must be sent to delete a message.
> In each case, the mail client has to specifically command the server
> to delete mail, and doesn't need to send a given command to require
> that it's saved.
Correct.
> I've also been trying to find out if, historically, any major server
> implementations have done this, or if it's just a no-no (a violation
> of the RFC).
It is most definitely a violation of the POP3 specification.
> My reason for asking is that in a lecture for a networking course, the
> professor stated that one reason IMAP was created was so that clients
> could access mail from different workstations. He says that older
> POP3 servers would delete mail automatically after the client had
> downloaded it. (IMAP was created to replace POP2, right?)
Well,... I invented IMAP, so presumably I know something about why IMAP
was created. :-)
Indeed, the ability to access mail from multiple workstations was a reason
behind the design of IMAP. But there were many reasons. You'll find some
aspects of the design philosophy in the IMAP2 specification (RFC 1176).
IMAP was not created to replace POP2. I was unaware of the existance of
POP when I invented IMAP. This was fortunate. I am sensitive to
accusations of "reinventing the wheel", and if I had known about POP I
would have used it (grumbling about its limitations all the way) and IMAP
would not have been invented. By the time Jon Postel told me about POP,
IMAP was already well along and far superior.
The underlying philsophy in IMAP is completely different than POP. POP
did not influence IMAP in any way. The influences in IMAP were my own
work with the TOPS-20 mailsystem, operating system programming
(specifically device drivers), and a vague charter to create a
"distributed mail system." Only two things in IMAP2 were from other
people: command tags (the original IMAP did not have tags), and response
codes (e.g. "[READ-ONLY]"). Everything else in IMAP2 originated with me.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Rob
<m...@CAC.Washington.EDU> wrote:
>Well,... I invented IMAP, so presumably I know something about why IMAP
>was created. :-)
Hmm, I guess I came to the right newsgroup, after all!
Thank you very much for taking the time to respond and answer every
one of my questions. I have plenty of practical experience on the
Internet, but my theoretical foundation is spotty.
>Indeed, the ability to access mail from multiple workstations was a reason
>behind the design of IMAP. But there were many reasons. You'll find some
>aspects of the design philosophy in the IMAP2 specification (RFC 1176).
That's kind of what I'd thought. The mentality behind POP3 seems to
be to get the mail off the server and to the client, period. That
makes access from multiple servers pretty messy, but not strictly
impossible. (And explains, to some extent, why it's popular with
ISPs.) But having worked for an ISP, I knew better, but I know next
to nothing about the theory behind the two protocols. (That's why I'm
taking this class and why I'm hyperfocused on getting the right info.)
>IMAP was not created to replace POP2.
When looking through a few RFC indexes for IMAP and POP, the earliest
reference I could find to IMAP was in 1064, which discusses IMAP2.
With that and it's references to POP2, I thought that the number had
come from the "2" in POP2. I'm sorry about that.
> I was unaware of the existance of
>POP when I invented IMAP. This was fortunate. I am sensitive to
>accusations of "reinventing the wheel", and if I had known about POP I
>would have used it (grumbling about its limitations all the way) and IMAP
>would not have been invented. By the time Jon Postel told me about POP,
>IMAP was already well along and far superior.
Sorry if I came across that way. I know next to nothing about IMAP,
outside of what I've picked up as an end-user. Compounding that, both
the book and the teacher breezed over it, focusing mostly on POP. Of
course, this is just a basic networking course, and there will be
others in the future. :)
Meanwhile, I downloaded RFC 1176, and have read it. (The IMAP FAQ and
http://www.imap.org/, found off your site, are very helpful too.)
Thanks for getting me (restarted) in the right direction!
Regards,
Stephen M. Dunn
$My reason for asking is that in a lecture for a networking course, the
$professor stated that one reason IMAP was created was so that clients
$could access mail from different workstations. He says that older
$POP3 servers would delete mail automatically after the client had
$downloaded it. (IMAP was created to replace POP2, right?)
I think this is more a client issue than anything else - many older
POP3 clients (at least on Windows - dunno about other OSes) automatically
deleted the mail off the server once it had been downloaded and didn't
provide configuration options to change this behaviour. (As a
sysadmin who runs a few mail servers, I don't terribly mind that;
let the user clog up their own hard drive, not mine, with stuff
they've already read but are too lazy to delete :-)
--
Stephen M. Dunn <ste...@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/
Mark Crispin
> be to get the mail off the server and to the client, period.
You don't need to prevaricate with "seems" -- that *is* the mentality with
POP3! :-)
> When looking through a few RFC indexes for IMAP and POP, the earliest
> reference I could find to IMAP was in 1064, which discusses IMAP2.
> With that and it's references to POP2, I thought that the number had
> come from the "2" in POP2. I'm sorry about that.
Here's a further bit of history for you.
The original protocol was the "Interim Mail Access Protocol", called that
because the name "MAP" was taken and what I was doing was experimental.
The original IMAP looked very much like IMAP2, except that there were no
tags. In other words, a transaction looked like:
FETCH 1 FLAGS
* 1 FLAGS (\Seen)
OK FETCH done!
So, you did a command, got back some number of data responses, and then
got an "OK", "NO", or "BAD" indicating the result.
Well, a person was quite unhappy with the idea of only sending one command
at a time, raised a great hue and cry that IMAP would die unless it was
possible to send multiple commands simultaneously, and demanded the
addition of tags. Hence the modern form:
tag FETCH 1 FLAGS
* 1 FLAGS (\Seen)
tag OK FETCH done!
This was, of course, a complete incompatibility (and on the same port no
less), but fortunately it was still possible to have a "flag day" in which
the old was exterminated in favor of the new. This was done, and the name
of the protocol was changed to "IMAP2" to distinguish it from the extinct
original IMAP.
Subsequent incarnations of the specification have grappled with sending
multiple commands simultaneously ever since, but for the most part IMAP
clients and servers still do just one command at a time.
The less said about "IMAP3" the better. "IMAP3" was a regrettable public
temper tantrum, long ago amended, and more importantly was a fantasy
protocol. There was never any IMAP3 software.
Hence the name IMAP4 for the next mainstream specification. The RFC 1176
IMAP2 protocol had been extended in the mainstream to support MIME and
added the CREATE, DELETE, and RENAME commands. The result was called
IMAP2bis, and as IMAP2bis it developed for many years. However, an early
decision of the IMAP working group was to rename IMAP2bis to IMAP4 and put
an end to the "IMAP3" question. IMAP4 was specified in RFC 1730.
Unfortunately, it turned out that some last-minute additions to IMAP4 were
design-broken; specifically, the header filtering and partial fetching
extensions. This needed to be fixed, and was fixed promptly with a new
design. Netscape demanded that the fixed version be called IMAP4rev1, and
implied that they would sue if their RFC 1730 server was obsoleted by the
new document. Hence the RFC 2060 protocol was called IMAP4rev1. [Anyone
who wonders why I switched my browser to IE long before the Evil Empire
made it a mandatory part of Windows need wonder no more.]
RFC 1730 IMAP4 became extinct remarkably rapidly; in fact, even Netscape
had switched over before RFC 2060 IMAP4rev1 was officially released.
The IMAP4rev1 protocol in RFC 2060 has proven remarkably stable, and for
the most part is *the* IMAP. Pockets of IMAP2bis and even RFC 1176 IMAP2
still exist in the world; Pine, at least, can still talk to them.
There is an update to RFC 2060 in the works, but it will be an updated
specification to IMAP4rev1, not IMAP4rev2 or IMAP5. Basically, it fixes
bugs discovered in RFC 2060 in the past 5 1/2 years, along with a few
minor changes that the IMAP community came to concensus on.
> Sorry if I came across that way.
No need to apologize!
> Meanwhile, I downloaded RFC 1176, and have read it. (The IMAP FAQ and
> http://www.imap.org/, found off your site, are very helpful too.)
> Thanks for getting me (restarted) in the right direction!
You're very welcome, and happy reading!
Paul Colquhoun
At least 1 POP3 server allows auto-deletion as an option (cucipop) but
it points out quite clearly that this option breaks the spec in the RFC
--
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/~paulcol
Asking for technical help in newsgroups? Read this first:
http://www.tuxedo.org/~esr/faqs/smart-questions.html
Paul Engle
Mark Crispin wrote:
> On Fri, 31 May 2002, Rob wrote:
>
>
>>I've also been trying to find out if, historically, any major server
>>implementations have done this, or if it's just a no-no (a violation
>>of the RFC).
>>
>
> It is most definitely a violation of the POP3 specification.
>
Interesting that this should come up now, because our site has just been
wrestling with this question. In RFC 1939 it explicitly says (regarding
server-side deletion of mail after a certain amount of time):
"Such message deletions are outside the scope of the POP3 protocol
and are not considered a protocol violation." As long as the deletions
are only done if a valid QUIT is received, it seems kosher.
In fact, I've managed to shoehorn in some expiration code into ipopd
because we really need to do automatic deletions but are moving to a
totally mbx-format setup. I'd be happy to share the changes with you,
Mark, if you're interested. I went that route rather than tweaking an
expiration-enabled server to use the c-client library because the ipopd
code was much easier to understand. I'm not a programmer and don't like
playing one on TV. I would have rather abandoned POP in lieu of IMAP
altogether, but that wasn't my call to make.
-paul
--
Paul D. Engle | Rice University
Unix System Administrator | Educational Technology - MS 119
(713) 348-4702 | P.O. Box 1892
pen...@rice.edu | Houston, TX 77251-1892
Mark Crispin
> >>I've also been trying to find out if, historically, any major server
> >>implementations have done this, or if it's just a no-no (a violation
> >>of the RFC).
> > It is most definitely a violation of the POP3 specification.
> Interesting that this should come up now, because our site has just been
> wrestling with this question. In RFC 1939 it explicitly says (regarding
> server-side deletion of mail after a certain amount of time):
> "Such message deletions are outside the scope of the POP3 protocol
> and are not considered a protocol violation."
That's different from automatically deleting a message as a consequence of
a RETR.
> In fact, I've managed to shoehorn in some expiration code into ipopd
> because we really need to do automatic deletions but are moving to a
> totally mbx-format setup. I'd be happy to share the changes with you,
> Mark, if you're interested. I went that route rather than tweaking an
> expiration-enabled server to use the c-client library because the ipopd
> code was much easier to understand. I'm not a programmer and don't like
> playing one on TV. I would have rather abandoned POP in lieu of IMAP
> altogether, but that wasn't my call to make.
I'll certainly take a look at your code if you send it to me. I always
encourage people to make their patches publicly available. There is a
huge grey area of patches which are useful to some people, but which, for
whatever reason, I choose not to adopt.
I personally do not approve of that functionality; I feel that mail should
never be deleted except by explicit user instruction. But I understand
why some sites may have a need for it, and I'm certainly willing to offer
assistance and recommendations for how to do it "right".
Here's a couple of recommendations off the top of my head for a site that
is considering that type of functionality:
1) don't do it in the IMAP or POP3 daemons, but rather have a separate
maintenance program which periodically scans and reaps old messages.
2) modify the mail store to be able to record a "last access" date/time,
and then modify the IMAP and POP3 daemons to update that time when a
message is retrieved. The "last access" date/time should then be a factor
in deciding whether or not a message should be reaped.