Re: Avoid POP3
Camaleón wrote:
On Wed, 18 May 2011 10:32:01 -0400, Miles Fidelman wrote:
The protocol is very specific - listing headers, downloading/reading
messages, marking messages for deletion, and actually deleting messages
(when a QUIT is issued) are very distinct operations that have to be
executed via different protocol transactions. There is no inherent
combined download/fetch/get/retrieve/delete action.
There may be default actions set up in a client, but those are client
and configuration specific.
Do you *really* think that pop3 is *widely* used to do not get and delete
the messages from the server? I don't think so, and moreover, I would not
recommend to keep the messages on it because it can cause a big mess on
the client side, better use imap.
I didn't say that - I said that there is no inherent combined operation
in the protocol - if read/delete are bundled, it is either by action of
a client invoking the protocol, or by an out-of-band action on the
server side.
And YES, to the extent that pop3 is still used, there are lots of cases
where people leave messages on their server - for example, checking mail
from a smartphone, then downloading and saving it later from a computer
at home or office. (And, perhaps, as pointed out in RFC1918, using the
pop3 server as a cheap mail repository.)
There may be defaults and customizations on the server-side, but those
are external to the protocol (if a server deletes messages after they're
downloaded, that's completely outside the scope of POP3).
Pop3 was not designed to keep the messages on the server, having such
option is not the norm but the exception (many e-mail server do not have
it enabled) and as I said, it does not work very well...
"The intent of the Post Office Protocol (POP) is to allow a user's
workstation to access mail from a mailbox server. It is expected
that mail will be posted from the workstation to the mailbox server
via the Simple Mail Transfer Protocol (SMTP)." RFC918 (POP)
P.S. Recommeded lecture:
- RFC1939, chapter "8. Scaling and Operational Considerations"
- http://en.wikipedia.org/wiki/Post_Office_Protocol#Extensions
Actually, I have.
RFC1939 gives a somewhat expanded statement of the intent of POP3 (vis POP)
"The Post Office Protocol - Version 3 (POP3) is intended to
permit a workstation to dynamically access a maildrop on a server
host in a useful fashion. Usually, this means that the POP3 protocol
is used to allow a workstation to retrieve mail that the server is
holding for it.
POP3 is not intended to provide extensive manipulation operations of
mail on the server; normally, mail is downloaded and then deleted."
Note the word "normally."
And then in Section 8, among other things, states:
"In these situations and others, users and vendors of POP3 clients have
discovered
that the combination of using the UIDL command and not issuing the DELE
command
can provide a weak version of the "maildrop as semi-permanent
repository" functionality
normally associated with IMAP."
And goes on to recommend that commercial operators consider such actions as:
"Imposing a per-user maildrop storage quota or the like" and/or
"Enforce a site policy regarding mail retention on the server"
and go on to note that "Such message deletions are outside the scope of
the POP3 protocol"
The section notes, explicitly that:
"Clients must not assume that a site policy will automate message
deletions, and should
continue to explicitly delete messages using the DELE command when
appropriate."
-----
Which brings us back to the original question that started this thread:
"We have a problem. We are building an app which uses Roundcube to read
mails. It's ok for IMAP accounts, but we need to read an account
provider who just uses POP3. We need to read it without download the
mails. There are some way to read the mails from POP3 account without
download...maybe a gateway to IMAP...some idea?"
Whether IMAP is a "better" solution or not; whether it's a good idea to
leave mail on a POP server; and whether some clients default to deleting
messages after downloading them by POP3 are all irrelevant to the question.
Maybe you like IMAP better for your purposes (I do), though it's worth
noting that at least some IMAP servers and clients exhibit funny locking
problems when multiple clients access the same mailbox simultaneously
(I've had some real problems with the UW server in supporting a user who
runs both Mac Mail and an iPhone - when both are online and polling
asynchronously). But again, these are irrelevant to the original
questioner.
What are relevant are:
1. Clarifying that "read without download" is simply not possible, but
that read, but leave on the server is.
2. POP3 does NOT inherently delete messages after they are read
3. There are both clients and software libraries (and probably gateway
services) that can:
- pull mail from a POP3 mailbox
- make that mail available via IMAP
- AND leave the original mail on the POP3 server
4. There is a risk that the the operator of the POP3 server might
implement out-of-band mechanisms to delete messages after they are read
- as a matter of site-specific policy and mechanisms.
What also might be relevant is clarifying the original poster's intent.
Why is someone "building an app which uses Roundcube to read mails" -
given that Roundcube already IS an app to read mails. If the question
is "how do we extend Roundcube to access POP3 mailboxes?" that leads to
a very different answer (e.g., a plug-in or gateway) than if the OP is
writing an application that has email as an internal function - in which
case, that tends to lead toward use of a package of mail-access library
routines, rather than an email client like Roundcube.
What is definitely not helpful are factually inaccurate statements like:
"pop3, due to its own nature, inherits by default a
"download/fetch/get/retrieve and delete"
and then attempts to further justify such statements with further
inaccurate statements and with references to binding documentation that
states exactly the opposite.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra
Reply to: