I think the best summary is that IMAP is a remote mailbox access protocol, supporting all common mailbox operations at the protocol level. POP is not: it supports full message retrieval, new-message scan (kind of, via UIDL), and deletion. This makes it, at best, a queued message pull protocol.
But as someone else said, IMAP is just more flexible. You may not need all the features of IMAP, but since it fully encompasses everything that POP supports, why not use it? >> so the "leave mail on server" option that most pop-clients have is >> certainly not a convenient way to access your mail remotely from different >> locations. If you have minimal needs, it works alright. It's implementation- dependent since it's not done at the protocol level, but POP servers can track basic message and mailbox status. > Plus: POP needs locking, i.e. only one client at a time can access the > mailbox which implies that tools should not perform time-consuming tasks > while they have a POP session open. That's implementation-dependent though. A server might require locking, but it's not inherent to the protocol and it's possible to implement one that has few of the contstraints that people have mentioned in this thread. But historically, there are few really good POP servers, so in practical terms you're not wrong. Most of the things that people cite as flaws of POP are really flaws in particular implementations, not in the protocol. The POP protocol is limited in scope, but I don't think this is a flaw; POP just has a different design goal. (That said, it's really too bad that the POP and NNTP groups didn't join forces from the start. With an NNTP server that supported authentication and operationally understood the goals of user-oriented mailbox access, it would have been a completely reasonable alternative to both POP and IMAP, and much closer to IMAP in spirit.) -- -D. d...@uchicago.edu NSIT University of Chicago Just to clear the deck, I own no monkeys.
