Alright, I’m considering this issue resolved and, thankfully, with nothing nefarious going on. I found a thread, here related to gmail and the problem description is identical. In particular, the comments from ‘Witekb’ are illuminating. After the jump, I have an explanation for what was going on.
First, the name “plus.pop.mail.yahoo.com” will in fact resolve to different IP’s at different times based on loading of email servers. So the fact that fetchmail’s POP requests were getting routed to “pop.mail.yahoo.com” is not unusual- it’s intentional in fact. Further, it’s likely that the SSL certificates were being updated (I can’t verify this, but it seems almost a given at this point). Rather than update all certificates at once, thus risking that users would not be able to get their email, they update the certificates a batch at a time. So the error is the result of seeing the old certificate on a server that hadn’t been updated. In a couple of days, when the update process is completed, the errors should disappear.
So with that, on to deck staining.
UPDATE: Idiot. Should have checked the expiration dates before writing this. If I had done so, I would have noticed that the date range for the certificates in question did not expire recently. So all I’m left with is load balancing that sends the requests over to the pop.mail.yahoo.com server which has an incompatible certificate because it doesn’t match the name I call out in the fetchmail configuration, plus.pop.mail.yahoo.com.
Seems like a mistake on Yahoo’s part, FWIW. But, in case it isn’t obvious, I’m no expert. That’s all … until the next update.