How to tell POP3 daemon to mark messages as read?

[Greg A. Woods]

At Fri, 10 Nov 2006 09:29:25 +0000 (GMT),
David Carter wrote:
> 
> On Fri, 3 Nov 2006, Georgy Goshin wrote:
> 
> > Is it possible to mark all messages downloaded via POP3 daemon as read 
> > so that next time user connected via IMAP could see wich messages are 
> > new?
> 
> No, the POP daemon doesn't open the seen message database. There would
> be a fairly substantial performance hit if it did.
> 
> I believe (its been some time now) that the UW server works the way that 
> you want. The POP protocol doesn't have any concept of \Seen messages, so 
> there isn't really a right or wrong way to do this.

Well the right way to do it is to never leave messages on the server in
the first place.

Face it, POP, as a protocol design, is really only useful for retrieving
messages.

(The real-world analogies are all pretty silly, but leaving mail on the
server is like going to your post-box, opening and photocopying every
letter, sealing them up again, and putting all the letters back in.  THe
important part is that you can't tag the originals -- you have to
covertly copy them.  Only the person doing the copying may know which
were copied.)

As the RFC says:  "POP3 is not intended to provide extensive
manipulation operations of mail on the server; normally, mail is
downloaded and then deleted."

If there were a way for the POP server to reject attempts by the client
to leave messages on the server then there should probably be a
configurable policy option to make it do that.  Perhaps this would be as
simple as removing support for the silly UIDL command.  The RFC also
suggests:

          This could be implemented in POP3 server
      software by the following mechanism: "following a POP3 login by a
      client which was ended by a QUIT, delete all messages downloaded
      during the session with the RETR command".  It is important not to
      delete messages in the event of abnormal connection termination
      (ie, if no QUIT was received from the client) because the client
      may not have successfully received or stored the messages.
      Servers implementing a download-and-delete policy may also wish to
      disable or limit the optional TOP command, since it could be used
      as an alternate mechanism to download entire messages.

Having real quotas in the POP server isn't really a decent solution,
especially not when the server's only avenue of notifying the user of an
over-quota problem is by adding yet another message to their over-quota
inbox.

I would opt for the "delete successfully retrieved messages" option in
the blink of an eye, and I'm not even sure I'd bother telling the users.
Most of the ones I deal with are too ignorant of these issues to
understand the implications beforehand anyway.  They will only learn by
experience.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>       Secrets of the Weird <woods at weird.com>