11

I am trying to prepare a complete list of behaviour that Gmail POP3 exhibits, that you wouldn’t expect to generally find in a POP3 server.

For example, Gmail appears to ignore the DELE (delete) command from a POP3 client. Instead, it implements its own delete and archive strategy.

The purpose of preparing a list is to avoid developers testing a POP3 client against the Gmail POP3 server and then assuming that all POP3 servers behave in the same way.

Can anyone provide a more complete list of non-standard behaviour?

Yi Jiang
  • 49,435
  • 16
  • 136
  • 136
Mike Green
  • 2,031
  • 2
  • 18
  • 16

1 Answers1

26

I cannot come with a complete list, but I can come with what I know of:

  • Fetching an email will hide it from all later POP3 sessions unless you reset your gmail pop3 settings (sets them again).
    To be more precise: I found out that this happens with the RETR command only. Not the TOP command. I also noticed that if the QUIT command is not sent after issuing RETR commands, the messages are kept on the server for later sessions. It is therefore possible to fetch the messages and just close the connection, and gmail will keep the messages visible for the next session.
  • Depending on your gmail settings, a fetched email can be deleted from your gmail web interface as well.
  • Logging in with a special "recent:" in front of your username will show emails received in the last 30 days, regardless of being sent to another POP3 client already.

Those are the only non-standard behaviour I know about the gmail pop3 service. Most of this information I have gathered while being a developer for OpenPop.NET.

References that might be of use:

foens
  • 8,642
  • 2
  • 36
  • 48
  • Does 'fetching an email' mean both the RETR command and the TOP command? Does it also mean that an RSET command (to make deleted emails visible again in the session) has no effect on a Gmail POP3 server? – Mike Green Dec 25 '10 at 23:21
  • I edited my response to be more precise. Regarding RSET command: When fetching emails the emails are still visible to the client as long as we are in the same pop3 session. Therefore I do not understand your question with the RSET command. The RSET command simply unmarks those messages marked as deleted, but they are only marked as deleted if you issue a DELE command on them. RSET does not undelete messages deleted in prior pop3 sessions - messages marked as deleted (with DELE command) are permanently deleted when issuing the QUIT command. – foens Dec 26 '10 at 10:34
  • Thanks. My question about the RSET command assumed that the implicit deletions caused by using the RETR command, are the only deletions that the RSET command could potentially reverse. I also assumed that the DELE command had no effect. You have clarified that, by explaining that the DELE command and the RSET command work as expected for any POP3 server. So, the only non-standard behaviour in the RETR, DELE and RSET command space is that emails that have been RETR(ieved) will be hidden from future POP3 sessions, if the session is properly ended using the QUIT command. – Mike Green Dec 26 '10 at 14:25
  • That is the things I know of, yes. I do not know if there are others though. – foens Dec 26 '10 at 17:54
  • Actually, the CAPA EXPIRE command with a value of 0 is specified in RFC to tell the client that messages will not be left on the server. Maybe GMAIL supports this command. – foens Jan 26 '11 at 17:27
  • +1 I am having to retrieve mail from Gmail as well, this is very useful. Thanks for the research and hard work. – JYelton Jun 01 '11 at 17:24
  • +1 I wish I could give more plus ones. Great and rare information. – Auxiliary Aug 29 '13 at 08:36