Does RSET Reset RETR-caused Deletions?

Some POP3 servers have a policy of deleting an e-mail after it has been
retrieved using the RETR command (as opposed to the TOP command).

My question is: Will the issuance of an RSET command following one or more
RETR commands (and prior to the QUIT command) prevent a POP3 server from
deleting mail that has been retrieved during that same session via the RETR
commands?

The RFC (1939) defining the POP3 protocol says of RSET only that:

---
If any messages have been marked as deleted by the POP3 server, they are
unmarked.
---

That would certainly pertain to messages marked as deleted by the DELE
command, but I cannot determine whether it would pertain to messages
*implicitly* queued for deletion by the retrieval of a message via RETR.
The RFC say the following about such (optional) server policies:

---
Sites are free to establish local policy regarding the storage and retention
of messages on the server, both read and unread. For example, a site might
delete unread messages from the server after 60 days and delete read
messages after 7 days. Such message deletions are outside the scope of the
POP3 protocol and are not considered a protocol violation.

Server operators enforcing message deletion policies should take care to
make all users aware of the policies in force.

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.

It should be noted that enforcing site message deletion policies may be
confusing to the user community, since their POP3 client may contain
configuration options to leave mail on the server which will not in fact be
supported by the server.

One special case of a site policy is that messages may only be downloaded
once from the server, and are deleted after this has been accomplished. 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.
---

So, to summarize the dilemma (for an e-mail client author / maintainer):

TOP is optional. If TOP is not implemented by a particular server, then the
only way to preview messages would be RETR. But, some servers implement a
policy of deleting a message after it has been retrieved using RETR.
Therefore, an attempt to preview a message using RETR could result in the
deletion of a message before the e-mail client performing the previewing
(for example) has actually stored it for viewing and archiving by the user.
However, if RSET reliably prevents deletion of messages retrieved by RETR,
then a solution based upon RETR followed by RSET could be used for
previewing messages.

A related question is: How common is it among servers to implement the TOP
command? My impression is that, despite the fact that this command is
optional in the specification, to *not* implement it is almost unheard of.
However, I have no hard evidence of this (e.g., a study of various specific
POP3 servers).

Another question is: How common is it for servers to provide non-standard
(i.e., noncompliant) implementations of the TOP command (e.g., one that does
not download the entire header plus as many lines of the body as are
specified in the second argument, but instead downloads only as many lines
of the raw message, starting from the first line of the header, as are
specified)? I have read vague reports of such noncompliance on Usenet.

Since the RFC appears to be ambiguous or ambivalent on these points, these
questions could be seen as primarily being about what is actually
implemented by various servers, as opposed to the "true meaning" of the
specification.

Thanks in advance for any information you might provide.

Carl

Re: Does RSET Reset RETR-caused Deletions?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-32240-1118788536-0006
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Carl Gunther writes:

> Some POP3 servers have a policy of deleting an e-mail after it has been
> retrieved using the RETR command (as opposed to the TOP command).
>
> My question is: Will the issuance of an RSET command following one or more
> RETR commands (and prior to the QUIT command) prevent a POP3 server from
> deleting mail that has been retrieved during that same session via the RETR
> commands?

You answered your own question, below, with the following quote:

> Server operators enforcing message deletion policies should take care to
> make all users aware of the policies in force.


--=_mimegpg-commodore.email-scan.com-32240-1118788536-0006
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCr1u4x9p3GYHlUOIRApsbAJ48b5+DnnJTeBHjcY5XDoUJ9b8ebgCf UP1Q
bgmOK9VbuuB62P+dXA3DQ3I=
=xyFK
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-32240-1118788536-0006--

Re: Does RSET Reset RETR-caused Deletions?

On comp.mail.misc, in , "Carl Gunther" wrote:



I'd suggest that you try using RETR and RSET manually, with
telnet, on a server that deletes messages after a RETR command.

The implementations of TOP in servers must be pretty common,
considering that this is how fetchmail operates by default.

AC

--
alanconnor AT earthlink DOT net
Use your real return address or I'll never know you
even tried to mail me. http://tinyurl.com/2t5kp
~

Re: Does RSET Reset RETR-caused Deletions?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-32240-1118796238-0007
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Usenet Beavis writes:

> On comp.mail.misc, in , "Carl Gunther" wrote:
>
>
>
> I'd suggest that you try using RETR and RSET manually, with
> telnet, on a server that deletes messages after a RETR command.

And I suggest that you read the message before you attempt to reply to it.

> The implementations of TOP in servers must be pretty common,
> considering that this is how fetchmail operates by default.

That's nice to know, Beavis. But it doesn't have to do with anything.


--=_mimegpg-commodore.email-scan.com-32240-1118796238-0007
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCr3nOx9p3GYHlUOIRAtGQAJ9WjK83PqCgdYDYbknuAuBWstmk2ACf UEUV
oVV/S2GydykpF+H9HjrQd9I=
=jFqN
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-32240-1118796238-0007--

Re: Does RSET Reset RETR-caused Deletions?

Someone seems to have started this thread by indiscriminately
posting to a large set of news groups without first checking
which ones are relevant.

It would be a kindness to readers of comp.lang.pop if people
discussing this thread removed comp.lang.pop from the newsgroupos
list.

comp.lang.pop has nothing to do with the topic under discussion.

It is in the comp.lang hierarchy which is concerned with computer
programming langages.

Comp.lang.pop is concerned the poplog programming system, pop11 its
core language and the other poplog languages (common lisp, prolog,
and ML). POP3 servers are totally irrelevant to this.

Moreover the news group is gatewayed to an email list for people
interested in those languages and poplog so the news postings get
transmitted to the list.

For more on this see
http://www.cs.bham.ac.uk/research/poplog/freepoplog.html
http://www.cs.bham.ac.uk/research/poplog/poplog.info.html
http://www.cs.bham.ac.uk/research/poplog/comp.lang.pop.faq.h tml

Before posting to a news group it is always a good idea to read some
of the messages on it to see if it is relevant to your question.

Yours in hope.

Thanks.

Aaron
http://www.cs.bham.ac.uk/~axs/
====

Re: Does RSET Reset RETR-caused Deletions?

It's doubtful that the RSET command would help you. Its intention is to cancel the DELE
commands issued this session.

But since the POP3 server should not automatically mark for deletion records that have
just had a RETR, maybe it will work on the errant server.

Rather than the RSET command, another thing to try is just end the connection without
issuing the QUIT command. The POP3 server is not supposed to delete any messages until
the QUIT command is issued. And if the session ends without the QUIT command, the POP3
server is to assume that the connection was lost and the mail client lost all downloaded
messages.

But the real fix is to talk the POP3 server administrator into changing their policy.

--

Mike - http://pages.prodigy.net/michael_santovec/techhelp.htm


"Carl Gunther" wrote in message
news:GKIre.4412$jX6.3879@newsread2.news.pas.earthlink.net...
> Some POP3 servers have a policy of deleting an e-mail after it has been retrieved using
> the RETR command (as opposed to the TOP command).
>
> My question is: Will the issuance of an RSET command following one or more RETR
> commands (and prior to the QUIT command) prevent a POP3 server from deleting mail that
> has been retrieved during that same session via the RETR commands?
>
> The RFC (1939) defining the POP3 protocol says of RSET only that:
>
> ---
> If any messages have been marked as deleted by the POP3 server, they are unmarked.
> ---
>
> That would certainly pertain to messages marked as deleted by the DELE command, but I
> cannot determine whether it would pertain to messages *implicitly* queued for deletion
> by the retrieval of a message via RETR. The RFC say the following about such (optional)
> server policies:
>
> ---
> Sites are free to establish local policy regarding the storage and retention of messages
> on the server, both read and unread. For example, a site might delete unread messages
> from the server after 60 days and delete read messages after 7 days. Such message
> deletions are outside the scope of the POP3 protocol and are not considered a protocol
> violation.
>
> Server operators enforcing message deletion policies should take care to make all users
> aware of the policies in force.
>
> 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.
>
> It should be noted that enforcing site message deletion policies may be confusing to the
> user community, since their POP3 client may contain configuration options to leave mail
> on the server which will not in fact be supported by the server.
>
> One special case of a site policy is that messages may only be downloaded once from the
> server, and are deleted after this has been accomplished. 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.
> ---
>
> So, to summarize the dilemma (for an e-mail client author / maintainer):
>
> TOP is optional. If TOP is not implemented by a particular server, then the only way to
> preview messages would be RETR. But, some servers implement a policy of deleting a
> message after it has been retrieved using RETR. Therefore, an attempt to preview a
> message using RETR could result in the deletion of a message before the e-mail client
> performing the previewing (for example) has actually stored it for viewing and archiving
> by the user. However, if RSET reliably prevents deletion of messages retrieved by RETR,
> then a solution based upon RETR followed by RSET could be used for previewing messages.
>
> A related question is: How common is it among servers to implement the TOP command? My
> impression is that, despite the fact that this command is optional in the specification,
> to *not* implement it is almost unheard of. However, I have no hard evidence of this
> (e.g., a study of various specific POP3 servers).
>
> Another question is: How common is it for servers to provide non-standard (i.e.,
> noncompliant) implementations of the TOP command (e.g., one that does not download the
> entire header plus as many lines of the body as are specified in the second argument,
> but instead downloads only as many lines of the raw message, starting from the first
> line of the header, as are specified)? I have read vague reports of such noncompliance
> on Usenet.
>
> Since the RFC appears to be ambiguous or ambivalent on these points, these questions
> could be seen as primarily being about what is actually implemented by various servers,
> as opposed to the "true meaning" of the specification.
>
> Thanks in advance for any information you might provide.
>
> Carl
>
>
>
>
>
>