From: Stefano <fet...@po...> - 2008-03-15 09:33:34
Attachments:
socket.c.patch
|
I recently installed Fetchmail (6.3.8) to collect my mail from various accounts, so that they could be automatically filtered and sorted. Since installation, I had been getting the following error whenever it polled my ISP's server (POP3): Invalid SSL protocol '' specified, using default (SSLv23). This does not happen when accessing other IMAP servers, but they don't support IMAP. Given that I had added a cron job to check the accounts periodically, I kept receiving messages from the cron daemon with these errors; rather irritating. Thus began my quest to track down and silence the error. The documentation seems to indicate that an empty SSL protocol type string is valid, and would cause a default negotiation. Yet I was getting the error despite having specified ssl23 in the run control file. I finally tracked it down to the fact that the particular POP3 server they use was rejecting the CAPA command, and, upon re-poll, sslproto was being set to "" (line 454 or so of pop3.c). The subsequent call to SSLOpen() (driver.c:1625 or so, if I recall) was generating the error, after my protocol specification had been changed to '', as described above. My solution was to modify socket.c as in the attached patch. This seems to me to cause the correct behaviour, and appears to be more in keeping with the documentation. I apologise for being so long winded, but wanted to try giving a sufficient description of the problem, so that others will have an idea of where the error comes from in the event that the provided patch turns out to be total nonsense or causes other problems. I had read about this problem while trying to solve it, but it didn't seem to have been fixed in the latest development code, so I took a stab at it. |
From: Matthias A. <mat...@gm...> - 2008-03-15 14:50:36
Attachments:
fix-invalid-sslproto.patch
|
On Sat, 15 Mar 2008, Stefano wrote: > I recently installed Fetchmail (6.3.8) to collect my mail from various > accounts, so that they could be automatically filtered and sorted. Since > installation, I had been getting the following error whenever it polled > my ISP's server (POP3): > > Invalid SSL protocol '' specified, using default (SSLv23). > > This does not happen when accessing other IMAP servers, but they don't > support IMAP. Given that I had added a cron job to check the accounts > periodically, I kept receiving messages from the cron daemon with these > errors; rather irritating. Thus began my quest to track down and > silence the error. Well, try the attached patch and see if it helps, it's actually simpler. If the NEWS or TODO.txt parts of the patch fail, nevermind. > I had read about this problem while trying to solve it, but it didn't > seem to have been fixed in the latest development code, so I took a stab > at it. It should be fixed in the SVN repository though, http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/ (That's where my patch comes from.) If not, we'll check again how to fix this. Thanks a lot for your report and patch! -- Matthias Andree |
From: Stefano <fet...@po...> - 2008-03-16 05:24:57
|
Evidently, I should have looked more closely at the latest development code in the repository. The particular problem I was having does indeed appear to have been fixed in BRANCH_6-3 (checked it out and built a few hours ago). However, is there not a chance that a similar problem will return in the event that the "defeat opportunistic STLS" block *is* executed? It seems that the only thing that was done is to avoid going through that block in the particular case of a required re-poll when an opportunistic STLS negotiation was not attempted. Without changing the sslproto = "" aspect of that block, or the handling in socket.c, does the potential for the problem to return not remain? Quoting Matthias Andree <mat...@gm...>: > On Sat, 15 Mar 2008, Stefano wrote: > >> I recently installed Fetchmail (6.3.8) to collect my mail from various >> accounts, so that they could be automatically filtered and sorted. Since >> installation, I had been getting the following error whenever it polled >> my ISP's server (POP3): >> >> Invalid SSL protocol '' specified, using default (SSLv23). >> >> This does not happen when accessing other IMAP servers, but they don't >> support IMAP. Given that I had added a cron job to check the accounts >> periodically, I kept receiving messages from the cron daemon with these >> errors; rather irritating. Thus began my quest to track down and >> silence the error. > > Well, try the attached patch and see if it helps, it's actually simpler. > > If the NEWS or TODO.txt parts of the patch fail, nevermind. > >> I had read about this problem while trying to solve it, but it didn't >> seem to have been fixed in the latest development code, so I took a stab >> at it. > > It should be fixed in the SVN repository though, > > http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/ > > (That's where my patch comes from.) > > If not, we'll check again how to fix this. > > Thanks a lot for your report and patch! > > -- > Matthias Andree > |
From: Vitezslav C. <vcr...@re...> - 2009-06-03 17:27:47
|
Hi, it seems that Stefano was right - the problem still exists in some circumstances. See https://bugzilla.redhat.com/show_bug.cgi?id=503881 Best regards, Vitezslav Crhonek ----- Original Message ----- From: "Stefano" <fet...@po...> To: "Matthias Andree" <mat...@gm...> Cc: fet...@li... Sent: Sunday, March 16, 2008 5:22:05 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [fetchmail-devel] Fetchmail 6.3.8: "Invalid SSL protocol..." Error Evidently, I should have looked more closely at the latest development code in the repository. The particular problem I was having does indeed appear to have been fixed in BRANCH_6-3 (checked it out and built a few hours ago). However, is there not a chance that a similar problem will return in the event that the "defeat opportunistic STLS" block *is* executed? It seems that the only thing that was done is to avoid going through that block in the particular case of a required re-poll when an opportunistic STLS negotiation was not attempted. Without changing the sslproto = "" aspect of that block, or the handling in socket.c, does the potential for the problem to return not remain? Quoting Matthias Andree <mat...@gm...>: > On Sat, 15 Mar 2008, Stefano wrote: > >> I recently installed Fetchmail (6.3.8) to collect my mail from various >> accounts, so that they could be automatically filtered and sorted. Since >> installation, I had been getting the following error whenever it polled >> my ISP's server (POP3): >> >> Invalid SSL protocol '' specified, using default (SSLv23). >> >> This does not happen when accessing other IMAP servers, but they don't >> support IMAP. Given that I had added a cron job to check the accounts >> periodically, I kept receiving messages from the cron daemon with these >> errors; rather irritating. Thus began my quest to track down and >> silence the error. > > Well, try the attached patch and see if it helps, it's actually simpler. > > If the NEWS or TODO.txt parts of the patch fail, nevermind. > >> I had read about this problem while trying to solve it, but it didn't >> seem to have been fixed in the latest development code, so I took a stab >> at it. > > It should be fixed in the SVN repository though, > > http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/ > > (That's where my patch comes from.) > > If not, we'll check again how to fix this. > > Thanks a lot for your report and patch! > > -- > Matthias Andree > _______________________________________________ fetchmail-devel mailing list fet...@li... https://lists.berlios.de/mailman/listinfo/fetchmail-devel |
From: Matthias A. <mat...@gm...> - 2009-06-03 18:54:18
|
Am 03.06.2009, 17:00 Uhr, schrieb Vitezslav Crhonek <vcr...@re...>: > Hi, > > it seems that Stefano was right - the problem still exists in some > circumstances. See > https://bugzilla.redhat.com/show_bug.cgi?id=503881 > > Best regards, > Vitezslav Crhonek Hi Vitezslav, could you please request the original fetchmailrc (with only passwords and login masked but everything else unchanged) from the original reporter? I need that file to reproduce the problem on my end. Thanks in advance. Best regards Matthias Andree -- Matthias Andree |
From: Matthias A. <mat...@gm...> - 2009-06-05 09:49:59
|
Am 03.06.2009, 17:00 Uhr, schrieb Vitezslav Crhonek <vcr...@re...>: > it seems that Stefano was right - the problem still exists in some > circumstances. See > https://bugzilla.redhat.com/show_bug.cgi?id=503881 > > Best regards, > Vitezslav Crhonek Vitezslav, you've written "reproduced" in Bugzilla; so if _you_ have a configuration that shows this problem, please send it so I can start fixing, and perhaps later look if the configuration of the original submitter is also fixed. I think there is potential in the code to trigger such issues, but I don't yet know how (what the control flow is that leads to the problem). Before I fix this deep down the code, I want to make sure that we're free of other bugs in the SSL/TLS logic in the socket.c SSLOpen() callers. Thanks in advance. Best regards -- Matthias Andree |