Gmail, POP3 and Indy

In my ever expanding need for dealing with the outside world, I've discovered a quirky little thing about Indy 10. When using the TIdPOP3 component with Gmail, you have to manually call DisconnectNotifyPeer or delete commands are ignored. I suppose this isn't quirky as much as not really documented any place I was able to find. Let's backup and start at the beginning, shall we?

I have a Windows service that polls a POP3 account looking for messages that it can import into a DB. It has all sorts of fun rules that can be assigned to discover what needs to be imported, what database it goes into, etc. At any rate, this code has been merrily chugging away on both Yahoo and SmarterMail servers with nary a hiccup. I recently needed to watch a Google domain app e-mail address and didn't think much of it.

Of course, in order to do so you have to implement SSL for POP3. As I've posted in the past, this is not really much of an issue, you simply create the TIdSSLIOHandlerSocketOpenSSL object and assigned it to the IOHandler like so:

Pop3Srv.IOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(Pop3Srv);
Pop3Srv.UseTLS := utUseImplicitTLS;

Anyway, all was proceeding swimmingly until I retrieved the first message. In my case, I automatically delete any e-mail that matches my rules so it will not be imported a second time. This works fine with Yahoo and SmarterMail. You just call DeleteMessage(msgNumber) and voila, away it goes. With Gmail, no such luck.

Gmail actually has a three different settings under POP3. One keeps messages in the inbox after reading via POP, one archives it and one deletes it. Thinking this option was set wrong, I tried all three options... repeatedly... still no luck. I tried searching pretty extensively on this one and finally found the clue with RFC 1939. Gmail honors the "you must notify me you are quitting or I will not delete anything" rule that 1939 dictates.

When the client issues the QUIT command from the TRANSACTION state, the POP3 session enters the UPDATE state. (Note that if the client issues the QUIT command from the AUTHORIZATION state, the POP3 session terminates but does NOT enter the UPDATE state.) If a session terminates for some reason other than a client-issued QUIT command, the POP3 session does NOT enter the UPDATE state and MUST not remove any messages from the maildrop.

After checking the code for the IdPOP3, it turns out calling Free does not issue the QUIT command. It makes sense for it not to do so. What if you wanted to avoid the UPDATE state? It was just surprising that some mail servers worked without this command and some required it.

At any rate, I hope this helps someone else who's working with POP3 commands.