GMail and POP3 RETR problem - switch to IMAP?

When I'm accessing GMail inbox using POP3 protocol, it seems that after fetching given email using RETR command, after QUIT-ting and reconnecting, previously RETR-ieved email is not listed anymore when calling LIST.

Then, after going to: GMail settings//Forwarding and POP/IMAP and setting "Enable POP for all mail (even mail that's already been downloaded)", on next login all emails are being LIST-ed again, but if I RETR any of them, it again disappears from LIST after re-logging..

I can then go 开发者_开发问答to GMail settings again and repeat the whole process, but it's a show-stopper for me as I'm writing a script that should work without any manual actions.

Am I missing something, or only IMAP can help here?

(EDIT: RFC http://www.ietf.org/rfc/rfc1939.txt doesn't say a word about RETR command deleting messages)

This is intended behaviour of Gmail. According to this question, "[a]ll messages may be downloaded to another computer once; after downloading mail, it will not download again."

There's also a 'recent mode', in which the last 30 days of mail are fetched, regardless of whether it's been sent to another POP client already.

That said, don't try to fetch all your mail by different computer in a short period of time, as Gmail may block your account for 24 hours.

I strongly suggest using IMAP.

Gmail’s POP3 configuration maybe sometimes confusing. You can find Gmail POP3 behavior here.

Switching to IMAP is very good solution.

This is a common problem, unfortunately, it does not always have the easiest solution. Hopefully, this information will help you and others arrive at the best implementation that suits your needs. Disclaimer: if you have the option or capability to add IMAP to your pop3, it certainly makes things more manageable.

Gmail has its own Pop3 implementation, and with that said, not all of this is relevant to other pop3 providers Here is the lifecycle of the issue and some information that can help you manage it:

You connect to the pop3 server either in NORMAL mode or RECENT mode. This puts the "session" on the pop server into a "transaction state". Recent mode is used by prefixing the username on connection with "recent:" + Username. Recent mode will return the last 30 days of email on the server. Note* this will supersede the UIDL command which I will touch on below. I.e. recent mode will return all 30 days worth of email if they have not been removed. Since it always returns the last 30 days, if you have multiple clients, they will all receive the same information in recent mode.

Normal mode is the default. Normal mode will respect the limitations of the commands you choose to use. UIDL will return a chunk of roughly 250 of the oldest emails on the server. If you have 500 emails on the server, and you do not remove any, UIDL will return the id and Unique Identifier for those first 250 emails regardless, so you may not be aware of the new 250. The caveat here is as follows, GMAIL has an option on the web console where you configure pop, to "Enable pop from now on". By selecting that and saving, the timestamp at that moment will be used by the pop server to "refresh" the oldest time. Therefore UIDL will start returning messages back you from that point on up until you reach the 250 mark again (assuming you have not removed them).

It is important to note that the transaction state exists until you issue the QUIT command. Upon issuing that command the server enters the "Update" state, where it will begin issuing the updates you requested, like DELETE commands, or popping them after they have been downloaded. Until QUIT is issued successfully, nothing will be deleted and the server state does not change.

STAT command will show you the number of emails in the pop3 stack, that are on your server.

RETR command will retrieve, or download the email, but it is not marked as downloaded until you successfully end the session

UIDL which many developers use to retrieve the message numbers and unique identifiers is very useful if you maintain the state of the server and pop the email. UIDL will only ever return the oldest 250-ish (I have seen 251-255) emails. If you are constantly polling for new email, this is dangerous if email hasn't been removed. ALSO! if you need to delete email, make sure the GMAIL setting to, Keep a copy in my inbox, is configured in the web console, so that you have access to those emails as a backup.

LIST command would solve your problem in normal mode for getting more than 250 emails back, (note: you still need to maintain an id file locally to cross-check incoming mail in order to know that it is new or old)... HOWEVER: this command also returns mail from the SENT box, which for many, is not a viable solution.

Hints:

If you are managing the inbox quickly and effectively and do not believe 250 to be a limiting factor in your process, UIDL and RETR will work.

If you will not be able to keep your inbox below 250 but also need access to new email, AND you do not expect the inbox to grow to outrageous size and the performance is not concerning, RECENT mode should work.