Properly adminstrated IMAP servers (and also POP3 servers) get their SSL certificates replaced once in a while, and their SSL fingerprints change then as well
Of course this invalidates fetchmail’s configuration data “describing” those servers.
And fetchmail does not assist you keeping them updated – for good reason somehow.
Today it appeared to me, as if had already updated manually such configuration details quite a couple of times in my life-time.
This job also appeared to me as tedious and errorprone.
So I made this a tiny little programming challenge.
Right …, looks like yet another NIH thing – and I actually only did the research after completing my task, but I am staying entirely within the fetchmail universe, whereas the others resort to using openssl and mix up things quite a little, and I don’t really see the benefit.
My resulting script is neither super-exemplary nor very beautiful.
Well … it does indeed make use of a little formatting aid function, that I quite like and that I added inline – but actually w/o debugging switched on, you don’t need it all.
Update 2014-12-12: if different IMAP servers (all responding at different times to the same DNS name) can have different certificates, it is certainly better to have fetchmail deal with that fact, but apparently up until today, that isn’t the fact. I should listen probably listen to the fetchmail mailing lists (or even get involved in the discussion) – see the link to the mailing lists above! Actually it does not appear to me, as there was a recent discussion on the matter.
Update 2014-12-15: always start fetchmail like this:
$ fetchmail –verbose –logfile $HOME/var/log/fetchmail.log
then run my script, and it will also tell you, whether the fingerprints match; I simply call it, before following my procmail LOG again