Re: Avoid POP3
Camaleón wrote:
Next time you need to configure a POP3 account tell me if you leave
enable the "keep a copy in the server" setting. It's not the default, it
never has been in any MUA, or not in any I'm aware of. I don't think how
is that so hard to understand.
I think everyone understand this just fine. What I question is why this
is relevant, other
than in confusing the OP.
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.)
Yes, it can be used, of course, it's an optional feature that can be
provided by your e-mail server.
I see it as just the opposite. Keeping the email until explicitly
delete is the assumption. Deleting
email without a specific DELE command issued is optional, and out-of-band.
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."
Yes, I've noted, I hope you also did :-)
I did. I also note that in standards speak, "normally" is equivalent to
"may." What matters
are the "should" and "must" statements. In particular, the RFC states:
"Clients MUST not assume that a site policy will automate messagedeletions,
and SHOULD continue to explicitly delete messages using the DELE command
when appropriate." (emphasis mine)
-----
Which brings us back to the original question that started this thread:
Well, at last someone re-read the original post!
:-)
I read it as if the OP is currently *downloading and deleting* the e-
mails that come from the POP3 server... but he can read the messages
without downloading them, many pop3 checkers do that way! And I just said
this, no more, no less.
I read it as an OP unclear on the concept. He (she?) is trying to
access POP3 mail from
Roundcube - with a less than clear understanding of how POP3 works - as
evident from
a statement that asks about "reading without downloading."
2. POP3 does NOT inherently delete messages after they are read
It's the default action, but you can use another words if you like.
It's the default action of many clients, not of the POP3 protocol.
Since the OP was asking about things like gateways, the matter of
defaults is very
much less clear. I expect, for example, that Blackberry's email gateway
defaults
to leaving mail on the original account.
And then there are libraries and tools like fetchmail - where everything
is specifiable.
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
Of course, there are also fetchmail and getmail for that task and you can
instruct both applications to keep a copy in the server.
Which, I expect is really the solution to the OPs original question.
What also might be relevant is clarifying the original poster's intent.
Exactly!
Always :-)
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.
Just a side note on this.
You are not aware that the OP sent the same question to the Spanish
mailing list and I replied to him in there becasue I first saw the
question in that list... and I asked him to clarify what was his exact
intention, what was he wanting to get because I was not very clear to me,
neither.
Ahhh... don't you just hate that.
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.
Sir, just two things:
1/ The "inaccurate statements" can be because I'm not a native English
speaker and my English vocabulary is not as good as I would like (or as
it can be yours). I hope you can understand that.
Fair enough.
2/ The RFC (and also the Wikipedia article) clearly say that UIDL is not
intended to be used as a "poor" copy of the imap features, that is, to
keep messages on the server and follow their state (seen, read, etc...)
nor to track them.
The RFC is definitive, Wikipedia certainly is not. I'll still go back
to the RFC statement:
"Clients MUST not assume that a site policy will automate messagedeletions,
and SHOULD continue to explicitly delete messages using the DELE command
when appropriate."
I'll also state that I would consider it a poor design and policy for a
server to automatically
delete messages without explicit deletion. Lines go down, sessions get
dropped, people
access mailboxes from multiple computers - there are lots of reasons
that one needs to be
able to re-read a message.
This is from Wikipedia:
***
"(...) An extension mechanism was proposed in RFC 2449 to accommodate
general extensions as well as announce in an organized manner support for
optional commands, such as TOP and UIDL. The RFC did not intend to
encourage extensions, and reaffirmed that the role of POP3 is to provide
simple support for mainly download-and-delete requirements of mailbox
handling..."
***
And I think the last paragraph is very contundent on what pop3 was
designed for.
Wikipedia is not a definitive source for such things. Now if you can
point to statements
by John Myers or Marshall Rose, say in the archives of an ietf mailing
list, that would
be a more definitive statement of the authors' intent.
--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra
Reply to: