Greg's original question:
> > If you know, does the server somehow flag an individual message as to
> > whether the client has been informed of its presence in the mailbox; and not
> > allow its deletion until it (the server) is sure the client knows about it?
No. The POP3 server keeps track of which messages have been read,
but it will quite happily let you delete a message (by message #)
that you have not read. This could be useful, for example, if you
receive a 50MB attachment and want to delete it without downloading
it over a slow connection.
Sterlings comments:
> If that's the question, the answer is that I don't know all the
> specifics. However, from messing around with the POP protocol and
> watching my mailbox at the same time, I've noticed that the server
> does not deliver new messages to you mailbox (a simple file) until the
> mailbox is closed. It keeps the incoming mail in it's spool, a temp
> file, or some such place until it is safe to deliver.
>
> It also, as I recall, removes the mailbox file while you have it open.
> so when you open the mailbox and then go look for the file on the
> server, it actually appears empty on the server though you are reading
> a bunch of messages on the client side. I figure this is to protect
> the system from mailbox edits while the box is open... could royally
> mess things up.
This is correct if the POP3 server is running in 'normal mode'. When
you successfully authenticate into the POP3 server, your mail spool
file is copied (typically to /var/spool/mail/.pop.username, but the
path could be anywhere). When you log out, the "poplock" file is
copied back to the main spool, minus any message you've deleted along
the way.
The process of copying the mail to the poplock file can be very slow
(I/O intensive) on a busy server, particularly if that 50MB
attachment mentioned above is involved.
The authors of the qpopper daemon (Qualcomm) added a new mode in
version 3 called "server mode". It leaves your mail in the main
spool file and operates directly on that file. This is most
efficient for users that either 1) download all mail and delete
everything or 2) download all mail and leave everything on the server.
Things slow down a bit for people that delete some and leave some.
As Sterling points out, mailbox edits while the file is open could
royally mess things up. None of my users have telnet access to the
mail server, so they can't attempt to use Pine or Elm -- server mode
is only recommended if you don't have other processes accessing the
mailbox directly.
Best regards,
Kev
------------------------------------------------------------------------
Kevin McKinnon, Postmaster [EMAIL PROTECTED]
Sunshine Communications http://www.sunshinecable.com
PGP Public Key: http://www.dockmaster.net/pgp.html PGP 6.0 www.pgp.com
