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.