Back at the end of May 2010, my home Virgin Media cable service switched from the old mail service to a new service based on Gmail.

I was collecting mail from the mail servers with fetchmail using POP3 over SSL. This carried on working over the changeover.

But lo! Today, 27th July 2010, I noticed that SSL connections were failing to connect. Later they would connect and then close with

error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:284

so I looked closer. This error disappeared while I was looking, but in the process I did notice a subtle change in POP3 behaviour. There is a Gmail setting that controls what happens to mails deleted over POP3. By default it is set to keep those mails on the server - or, in less technical speak, not delete them. So they just sit there and pile up.

I don't want my mails lurking on Virgin's or Google's servers, thanks. I know 8Gb is a lot, but it is finite and I don't want to find out what happens when I hit it.

It turns out there are two ways around this. The first is to stick with POP3 and prefix your username with recent: - so if, for example, your username for email at Virgin is bear-cave, specify recent:bear-cave in your fetchmail setup. This causes deleted mail to be moved to the Gmail bin, and deleted after 30 days. But it has the significant snag that it downloads all undeleted emails from the last 30 days regardless of whether or not they've been downloaded before. So all your emails from the last 30 days will be duplicated the first time you use this setting. To get round this, use the web mail interface to delete all the mails on the server, and then start.

The other option is to use the web mail interface to delete all the mails on the server, and then switch to retrieving via IMAP. I've done this.

I also noticed in passing that quite a few fetchmail sessions are failing because Gmail reports Invalid back end or an authentication failure.