Description of problem: In some circumstances fetchmail will override user supplied sslproto and assign an empty string to the internal sslproto variable. However, fetchmail then treats the empty string as though it was an assigned value rather than NULL and emits a pointless error message. Version-Release number of selected component (if applicable): fetchmail-6.3.9-3.fc11 How reproducible: Always Steps to Reproduce: 1. create pop3 fetchmail configuration with ssl enabled (sslproto setting seems to be ignored). 2. poll the pop3 account Actual results: fetchmail writes to stderr: Invalid SSL protocol '' specified, using default (SSLv23). Expected results: Nothing should be written to stderr Additional info: In socket.c near the string "ssl23" the following lines could be added: } else if (!strcasecmp("",myproto)) { myproto = NULL;
Reproduced. Could you please attach your original fetchmailrc (with erased passwords and login, everything else unchanged)? Thanks in advance.
fetchmail config is: defaults protocol pop3 password XXXX is XXXX no keep no mimedecode ssl sslfingerprint "XXXX" sslcertck sslcertpath /etc/pki/tls/certs poll pop3.live.com username XXXX
Hi JW, I'm the upstream fetchmail maintainer. Could you show the command line you're calling fetchmail with and double-check that this is the same configuration that gives you the problem? While I do believe that you're seeing the problem, I cannot reproduce this with your configuration and just "fetchmail" or "fetchmail -v". (I'm testing this on openSUSE 11.1, so I'd changed sslcertpath to /etc/ssl/certs and pasted the actual sslfingerprint of pop3.live.com. Password and Login shouldn't matter for the problem to show though). Can you also verify with "type -a fetchmail" if you're not accidentally using an older version in /usr/local/bin or such effects? Thank you. Best regards Matthias
> Could you show the command line you're calling fetchmail with and double-check > that this is the same configuration that gives you the problem? > While I do believe that you're seeing the problem, I cannot reproduce this with > your configuration and just "fetchmail" or "fetchmail -v". You may need to use the "--nosyslog" arg or check your syslog for the erroneous message. In any case, I have patched my version of fetchmail (as outlined) and it eliminates the erroneous message.
Hi JW, --nosyslog does not help here with this configuration: defaults protocol pop3 password XXXX is XXXX no keep no mimedecode ssl sslfingerprint "D0:3C:4D:59:F6:95:37:59:EA:A9:5D:4C:CE:D3:2A:A1" sslcertck sslcertpath /etc/ssl/certs poll pop3.live.com username XXX While I see that your patch removes the message, it's a cosmetic fix to a different problem. I'd like to identify and fix that rather than mask the error. What is your command line? What is different between your and my configurations? (password ..., is ... and username shouldn't matter, the problem appears during SSL negotiation, i. e. before the credentials are submitted). (I've also been testing with the Fedora 11 .src.rpm to avoid version skew.) Thanks in advance.
My command-line is quite simple - it just does "fetchmail --nosyslog -f configfile". From what I can see in the source code there appears to be various places where the code deliberately zaps "sslproto" configuration setting and sets the sslproto field to xstrdup("") for some reason. But in the relevant portion of code the test is always for sslproto being NULL and never an empty string. Why? Surely it would make sense to test for sslproto being an empty string and allow that without emitting an error message.
JW, there are two places in pop3.c, but none can be reached with fetchmail 6.3.9 source code and with the given config file (i. e. with ssl enabled), unless there is a hardware error or fetchmail has been miscompiled. What is the architecture you're using? A. "ssl" disables the zapping after capa_probe(), as maybe_tls() always returns FALSE B. the zapping in connection_may_have_tls_errors is also defeated by "ssl". Since I still cannot reproduce this, and from reading pop3.c and related code still don't see how we get to a point where this happens: Can either of you who can reproduce this please: 1. provide "fetchmail -V" output 2. provide "fetchmail -v --nosyslog -f configfile" output 3. provide this *full* configfile with just passwords masked? No abbreviations please! 4a. provide the corresponding scripts used to start fetchmail 4b. provide an "env" or "printenv" dump from the shell used to start fetchmail
I did some more experiments and failed to reproduce the problem. Vitezslav/JW, is either of you willing to provide me with the details required to debug this, or should we just close the bug report as invalid (miscompilation or whatever)? I'm very much inclined to purge this report from my upstream TODO list given that I have no further information and reading the code provides me with A and B as shown in comment #7.
At the moment I'm able to reproduce it with fetchmail-6.3.8-8.fc10.x86_64 in F-10. [vcrhonek@norcus ~]$ fetchmail Invalid SSL protocol '' specified, using default (SSLv23). fetchmail: No mail for Vitezslav.Crhonek at pop3.seznam.cz [vcrhonek@norcus ~]$ rpm -q fetchmail fetchmail-6.3.8-8.fc10.x86_64 I'll attach required details.
Created attachment 354671 [details] fetchmailrc
Created attachment 354672 [details] fetchmail_v.txt
Created attachment 354673 [details] fetchmail_v_nosyslog.txt
Created attachment 354674 [details] printenv.txt
Created attachment 354777 [details] fetchmail SVN changeset 5109 to fix sslproto "" complaints in POP3 This is taken from the fetchmail SVN repository, -c5109, to fix sslproto issues; it appeared in fetchmail release 6.3.9 in November 2008.
Thank you, Vitezslav, for providing the information. I'm sorry to say that 6.3.8 does not qualify, because there were relevant fixes in 6.3.9, and the current version is 6.3.10. From 6.3.9's NEWS file: # BUG FIXES: * ... * No longer complain about invalid sslproto "" when POP3 CAPA probe fails. Fixes Debian Bug#421446 (Holger Leskien), Novell Bug #247233 (Jon Nelson). Thanks to Matthias Strauß for a configuration to reproduce the issue. Please provide logs of 6.3.9 or 6.3.10. I'm re-enabling the needinfo flag.
Sorry Matthias, I knew it bug just unsuspected it. I'm not able to reproduce it with fetchmail-6.3.9-3.fc11 anymore. [vcrhonek@azrael2 ~]$ fetchmail fetchmail: No mail for Vitezslav.Crhonek at pop3.seznam.cz [vcrhonek@azrael2 ~]$ rpm -q fetchmail fetchmail-6.3.9-3.fc11.i586 JW, could you please provide information wanted in comment #7?
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I think this bug was caused by a version skew on the reporter's end. He has probably been using 6.3.8 when he filed the issue, and 6.3.9 contained the relevant fix. I'd propose to close this bug as invalid.
Fixed since fetchmail-6.3.9-3.fc11.