Menu
▾
▴
fetchmail-users
|
From: Jerry <je...@se...> - 2015-04-06 09:54:54
|
Fetchmail was working just fine until a few days ago. I have an account at "outlook,com", formerly "hotmail.com". Fetchmail now cannot fetch mail from that site. I am running FreeBSD-10. I update "openssl" to version "OpenSSL 1.0.1l-freebsd 15 Jan 2015". After that, fetchmail fails. This is the log entry: fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Mon Apr 6 05:05:59 2015: poll started Trying to connect to 65.55.162.199/995...connected. fetchmail: SSL connection failed. fetchmail: socket error while fetching from me...@ou...@pop3.live.com fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Mon Apr 6 05:06:00 2015: poll completed Merged UID list from pop3.live.com: <empty> fetchmail: Query status=2 (SOCKET) fetchmail: normal termination, status 2 Using "openssl" works fine: ~ $ openssl s_client -crlf -showcerts -connect pop3.live.com:995 CONNECTED(00000003) depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - G2 verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=*.hotmail.com i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - G2 -----BEGIN CERTIFICATE----- MIIFQjCCBCqgAwIBAgISESHl0vjrML7zKmGlv42YL75vMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYD VQQDEypHbG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gRzIw HhcNMTMwNDI0MjAzNTA5WhcNMTYwNDI0MjAzNTA5WjBsMQswCQYDVQQGEwJVUzET MBEGA1UECBMKV2FzaGluZ3RvbjEQMA4GA1UEBxMHUmVkbW9uZDEeMBwGA1UEChMV TWljcm9zb2Z0IENvcnBvcmF0aW9uMRYwFAYDVQQDDA0qLmhvdG1haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAumSiBWrzHZf6WFP5a/j4+K7D 1izLoYKj5Omll0pdxKvKcBRDf+iaIkCbSOPNpx2uWGZdwNwkabYCQavaBf2ebwmS S8i1CJpHflO+k0qYd5WUi7sSsZ3+6RaCMdLoDIPGyYMQuy7TFtVO7LSt5+qscyyi ET8c3lE2aj/XW13UZvRrV65ZJvMjUtwaDnIcAxGeasYoebLsKdqHQ2uTr4PmNwCc viGVFSOzkGAoC0PfyqKB2xUWy3Kc5zRI2xvUW8Jb2b/9Ze3g55pIUzKsjpglkQTm edVPSYYPGNz6Kl/ZshBXdBAk398q1JkSmUaTMa2hJgBbcC+73ax40AJDGJlz+QID AQABo4IB6zCCAecwDgYDVR0PAQH/BAQDAgWgMEkGA1UdIARCMEAwPgYGZ4EMAQIC MDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9z aXRvcnkvMEAGA1UdEQQ5MDeCDSouaG90bWFpbC5jb22CCioubGl2ZS5jb22CDSou b3V0bG9vay5jb22CC2hvdG1haWwuY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYI KwYBBQUHAwEGCCsGAQUFBwMCMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwu Z2xvYmFsc2lnbi5jb20vZ3MvZ3Nvcmdhbml6YXRpb252YWxnMi5jcmwwgZYGCCsG AQUFBwEBBIGJMIGGMEcGCCsGAQUFBzAChjtodHRwOi8vc2VjdXJlLmdsb2JhbHNp Z24uY29tL2NhY2VydC9nc29yZ2FuaXphdGlvbnZhbGcyLmNydDA7BggrBgEFBQcw AYYvaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL2dzb3JnYW5pemF0aW9udmFs ZzIwHQYDVR0OBBYEFHbgHqTLsXDt7uMRyE62rnDEfLn9MB8GA1UdIwQYMBaAFF1G so3ES3Qcu+31c7Y6tziPdZ5+MA0GCSqGSIb3DQEBBQUAA4IBAQByy1+3N6ZRVooI xqw8Ng+UFz0g7UHkbPEnvTu1uxJ2AojFuP/P1PAk+/6uMRvpPlWg/5uqmOIWxKxJ Lo6xSbkDf4LN+KYwes3XSuPyziZ4QbPnehHhZ0377iiA8fpRJADg9NWKCRHh5aAd e9QvJUW/GgYkBN+F4yYc2jIjR3Rehv4JYOKS3iXO9OoHsDS2CcCFaS2imgQVfYLg slBwT/A08PCOhW5huiluSmih7x5Qf7sFDv8jineu6ehKzi8pKnOq4k8G4QiWn38Y CeiBkkwFOwj7T3M/ITiiSS9DHDGeokj16eBi83Zx3YYiJ9YZvnQ+4GvqJ5eJJ6pR KKvemr+m -----END CERTIFICATE----- 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - G2 i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA -----BEGIN CERTIFICATE----- MIIEizCCA3OgAwIBAgILBAAAAAABL07hQvkwDQYJKoZIhvcNAQEFBQAwVzELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xMTA0MTMxMDAw MDBaFw0yMjA0MTMxMDAwMDBaMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIE9yZ2FuaXphdGlvbiBW YWxpZGF0aW9uIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDdNR3yIFQmGtDvpW+Bdllw3Of01AMkHyQOnSKf1Ccyeit87ovjYWI4F6+0S3qf ZyEcLZVUunm6tsTyDSF0F2d04rFkCJlgePtnwkv3J41vNnbPMYzl8QbX3FcOW6zu zi2rqqlwLwKGyLHQCAeV6irs0Z7kNlw7pja1Q4ur944+ABv/hVlrYgGNguhKujiz 4MP0bRmn6gXdhGfCZsckAnNate6kGdn8AM62pI3ffr1fsjqdhDFPyGMM5NgNUqN+ ARvUZ6UYKOsBp4I82Y4d5UcNuotZFKMfH0vq4idGhs6dOcRmQafiFSNrVkfB7cVT 5NSAH2v6gEaYsgmmD5W+ZoiTAgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCAQYw EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUXUayjcRLdBy77fVztjq3OI91 nn4wRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3 Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwPQYIKwYBBQUHAQEEMTAv MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWxzaWduLmNvbS9yb290cjEw KQYDVR0lBCIwIAYIKwYBBQUHAwEGCCsGAQUFBwMCBgorBgEEAYI3CgMDMB8GA1Ud IwQYMBaAFGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQBz euwBLBcikZrKsWcYorrIBYmSJN4fuKtEn/dAVWXy4PQux96wP5kVH5VwgumbSmQk IBbwdhfSG/6s+ga0d8+Y2CrsVxXYXk7di5bhUzMZkdWEbiXvD8utv9tLa1bMtdRA PiZetln0xZDJCcSE37wmfYLp6/Rb/MgV3gkYRYazi03HazUnm2D2pFoqWEmx2DVD xjK7XjvESiHBoDtewSOpztvVuv5dbf0AfvrxlDdhuQA5ZpapnLQeEe9V2LTYsMSl rjIKL/gt9KKn/zbTXmOLThL3tSiAde6UL3CgVnc5qjmXF/wA889m56JxkqsFm3Mu eufnIVkJjTChrFzKGXr4 -----END CERTIFICATE----- --- Server certificate subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=*.hotmail.com issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - G2 --- No client certificate CA names sent --- SSL handshake has read 2656 bytes and written 617 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: A3200000F28DBE70E6BA0680730A1D6A26DF052A91482F711846423C7877FA33 Session-ID-ctx: Master-Key: 9EEAEA3D6219C2E22F99367A760D95D4D795E63441518AA1298FDDCE49456B2C935E2941B66EE4545601AA1BC85D7664 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1428311841 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- +OK dub0-pop742 POP3 server ready user ME...@ou... +OK password required pass PASSWOED +OK mailbox has 0 messages quit +OK mailbox unchanged, POP3 server signing off read:errno=0 This is the line from the ".fetchmailrc. file: poll pop3.live.com with proto POP3 service 995 timeout 30 and options bad-header accept user 'ger...@ou...' there with password 'PASSWORD' is 'ME' here options flush forcecr dropdelivered smtpname 'ME...@My...' ssl sslfingerprint '86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76' Does anyone have any idea what the problem is? -- Jerry |
|
From: Matthias A. <mat...@gm...> - 2015-04-07 01:03:08
|
Am 06.04.2015 um 11:24 schrieb Jerry: > Fetchmail was working just fine until a few days ago. I have an account at > "outlook,com", formerly "hotmail.com". Fetchmail now cannot fetch mail from > that site. Yeah. What does make it a fetchmail problem? > I am running FreeBSD-10. I update "openssl" to version "OpenSSL > 1.0.1l-freebsd 15 Jan 2015". After that, fetchmail fails. This is the log entry: > > fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Mon Apr 6 05:05:59 2015: poll started > Trying to connect to 65.55.162.199/995...connected. > fetchmail: SSL connection failed. > fetchmail: socket error while fetching from me...@ou...@pop3.live.com > fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Mon Apr 6 05:06:00 2015: poll completed > Merged UID list from pop3.live.com: <empty> > fetchmail: Query status=2 (SOCKET) > fetchmail: normal termination, status 2 > > Using "openssl" works fine: No it does not. You are not feeding it similar options to fetchmail's, and openssl's s_client will not bail out if verification fails. > ~ $ openssl s_client -crlf -showcerts -connect pop3.live.com:995 ... > Verify return code: 20 (unable to get local issuer certificate) Oops. That's not "fine" in my book. You don't have trust anchors (but you neither gave -CApath nor -CAfile to point s_client to them). > poll pop3.live.com with proto POP3 service 995 timeout 30 and options bad-header accept > user 'ger...@ou...' there with password 'PASSWORD' is 'ME' here options flush forcecr dropdelivered smtpname 'ME...@My...' ssl sslfingerprint '86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76' > > Does anyone have any idea what the problem is? I'm afraid not. That configuration works for me with the same OpenSSL version on FreeBSD 10.1-RELEASE-pwhatever on amd64 up to the point where it chats to the server, which then tells me that that made-up password isn't good for logging in, this is what I'm getting: >>| $ LC_ALL=C fetchmail -f /tmp/testrc >>| fetchmail: Authorization failure on ger...@ou...@pop3.glbdns2.microsoft.com >>| fetchmail: Query status=3 (AUTHFAIL) Now, you've been around mail and lists for long enough to know that you might want to read the FAQ before posting, and that you will not get support unless you provide verbose logs... <http://www.fetchmail.info/fetchmail-FAQ.html#G3> Specifically for FreeBSD, install ca_root_nss and add -verify 5 -CAfile /usr/local/share/certs/ca-root-nss.crt to the s_client command line. You should not need these for fetchmail though as long as you go without --sslcertck but with --sslfingerprint '...'. |
|
From: Jerry <je...@se...> - 2015-04-07 10:23:01
|
On Tue, 07 Apr 2015 03:02:59 +0200, Matthias Andree stated: > Am 06.04.2015 um 11:24 schrieb Jerry: "Message truncated" > Now, you've been around mail and lists for long enough to know that you > might want to read the FAQ before posting, and that you will not get > support unless you provide verbose logs... > <http://www.fetchmail.info/fetchmail-FAQ.html#G3> I did. > Specifically for FreeBSD, install ca_root_nss and add -verify 5 -CAfile > /usr/local/share/certs/ca-root-nss.crt to the s_client command line. > You should not need these for fetchmail though as long as you go without > --sslcertck but with --sslfingerprint '...'. I guess I should have stated in my original post, that the ".fetchmailrc" file, etcetera is exactly what I have been using for two years now without a single problem until few days ago when I updated "openssl" on my system. You don't have to be genius to figure out that the cause of the problem was the updated "openssl"; however, what is triggering it is what I am trying to decipher. Does any of this help: env LC_ALL=C fetchmail --nodetach -vvv --nosyslog Old UID list from pop3.live.com: <empty> Scratch list of UIDs: <empty> fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Tue Apr 7 05:57:50 2015: poll started Trying to connect to 134.170.170.231/995...connected. fetchmail: SSL connection failed. fetchmail: socket error while fetching from ME...@ou...@pop3.live.com fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Tue Apr 7 05:57:50 2015: poll completed Merged UID list from pop3.live.com: <empty> fetchmail: Query status=2 (SOCKET) fetchmail: normal termination, status 2 Or this: LC_ALL=C fetchmail -V This is fetchmail release 6.3.26+GSS+RPA+NTLM+SDPS+SSL+OPIE+NLS. Copyright (C) 2002, 2003 Eric S. Raymond Copyright (C) 2004 Matthias Andree, Eric S. Raymond, Robert M. Funk, Graham Wilson Copyright (C) 2005 - 2012 Sunil Shetye Copyright (C) 2005 - 2013 Matthias Andree Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. For details, please see the file COPYING in the source or documentation directory. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) Fallback MDA: (none) FreeBSD scorpio.seibercom.net 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64 Taking options from command line and /home/gerard/.fetchmailrc Idfile is /home/gerard/.fetchids Fetchmail will masquerade and will not generate Received Fetchmail will forward misaddressed multidrop messages to ad...@My.... Options for retrieving from ME...@ou...@pop3.live.com: True name of server is pop3.live.com. Protocol is POP3 (using service 995). All available authentication methods will be tried. SSL encrypted sessions enabled. SSL key fingerprint (checked against the server key): 86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76 Server nonresponse timeout is 30 seconds. Default mailbox selected. Only new messages will be retrieved (--all off). Fetched messages will not be kept on the server (--keep off). Old messages will be flushed before message retrieval (--flush on). Oversized messages will not be flushed before message retrieval (--limitflush off). Rewrite of server-local addresses is enabled (--norewrite off). Carriage-return stripping is disabled (stripcr off). Carriage-return forcing is enabled (forcecr on). Interpretation of Content-Transfer-Encoding is enabled (pass8bits off). MIME decoding is disabled (mimedecode off). Idle after poll is disabled (idle off). Nonempty Status lines will be kept (dropstatus off) Delivered-To lines will be discarded (dropdelivered on) Fetch message size limit is 100 (--fetchsizelimit 100). Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4). Messages will be SMTP-forwarded to: localhost (default) Address to be put in RCPT TO lines shipped to SMTP will be ME...@se... Single-drop mode: 1 local name recognized. No UIDs saved from this host. Messages with bad headers will be passed on. Or this: openssl s_client -tls1 -crlf -showcerts -verify 5 -CAfile /usr/local/share/certs/ca-root-nss.crt -connect pop3.live.com:995 verify depth is 5 CONNECTED(00000003) depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA verify return:1 depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - G2 verify return:1 depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = *.hotmail.com verify return:1 --- Certificate chain 0 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=*.hotmail.com i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - G2 -----BEGIN CERTIFICATE----- MIIFQjCCBCqgAwIBAgISESHl0vjrML7zKmGlv42YL75vMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYD VQQDEypHbG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gRzIw HhcNMTMwNDI0MjAzNTA5WhcNMTYwNDI0MjAzNTA5WjBsMQswCQYDVQQGEwJVUzET MBEGA1UECBMKV2FzaGluZ3RvbjEQMA4GA1UEBxMHUmVkbW9uZDEeMBwGA1UEChMV TWljcm9zb2Z0IENvcnBvcmF0aW9uMRYwFAYDVQQDDA0qLmhvdG1haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAumSiBWrzHZf6WFP5a/j4+K7D 1izLoYKj5Omll0pdxKvKcBRDf+iaIkCbSOPNpx2uWGZdwNwkabYCQavaBf2ebwmS S8i1CJpHflO+k0qYd5WUi7sSsZ3+6RaCMdLoDIPGyYMQuy7TFtVO7LSt5+qscyyi ET8c3lE2aj/XW13UZvRrV65ZJvMjUtwaDnIcAxGeasYoebLsKdqHQ2uTr4PmNwCc viGVFSOzkGAoC0PfyqKB2xUWy3Kc5zRI2xvUW8Jb2b/9Ze3g55pIUzKsjpglkQTm edVPSYYPGNz6Kl/ZshBXdBAk398q1JkSmUaTMa2hJgBbcC+73ax40AJDGJlz+QID AQABo4IB6zCCAecwDgYDVR0PAQH/BAQDAgWgMEkGA1UdIARCMEAwPgYGZ4EMAQIC MDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9z aXRvcnkvMEAGA1UdEQQ5MDeCDSouaG90bWFpbC5jb22CCioubGl2ZS5jb22CDSou b3V0bG9vay5jb22CC2hvdG1haWwuY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYI KwYBBQUHAwEGCCsGAQUFBwMCMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwu Z2xvYmFsc2lnbi5jb20vZ3MvZ3Nvcmdhbml6YXRpb252YWxnMi5jcmwwgZYGCCsG AQUFBwEBBIGJMIGGMEcGCCsGAQUFBzAChjtodHRwOi8vc2VjdXJlLmdsb2JhbHNp Z24uY29tL2NhY2VydC9nc29yZ2FuaXphdGlvbnZhbGcyLmNydDA7BggrBgEFBQcw AYYvaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL2dzb3JnYW5pemF0aW9udmFs ZzIwHQYDVR0OBBYEFHbgHqTLsXDt7uMRyE62rnDEfLn9MB8GA1UdIwQYMBaAFF1G so3ES3Qcu+31c7Y6tziPdZ5+MA0GCSqGSIb3DQEBBQUAA4IBAQByy1+3N6ZRVooI xqw8Ng+UFz0g7UHkbPEnvTu1uxJ2AojFuP/P1PAk+/6uMRvpPlWg/5uqmOIWxKxJ Lo6xSbkDf4LN+KYwes3XSuPyziZ4QbPnehHhZ0377iiA8fpRJADg9NWKCRHh5aAd e9QvJUW/GgYkBN+F4yYc2jIjR3Rehv4JYOKS3iXO9OoHsDS2CcCFaS2imgQVfYLg slBwT/A08PCOhW5huiluSmih7x5Qf7sFDv8jineu6ehKzi8pKnOq4k8G4QiWn38Y CeiBkkwFOwj7T3M/ITiiSS9DHDGeokj16eBi83Zx3YYiJ9YZvnQ+4GvqJ5eJJ6pR KKvemr+m -----END CERTIFICATE----- 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - G2 i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA -----BEGIN CERTIFICATE----- MIIEizCCA3OgAwIBAgILBAAAAAABL07hQvkwDQYJKoZIhvcNAQEFBQAwVzELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xMTA0MTMxMDAw MDBaFw0yMjA0MTMxMDAwMDBaMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIE9yZ2FuaXphdGlvbiBW YWxpZGF0aW9uIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDdNR3yIFQmGtDvpW+Bdllw3Of01AMkHyQOnSKf1Ccyeit87ovjYWI4F6+0S3qf ZyEcLZVUunm6tsTyDSF0F2d04rFkCJlgePtnwkv3J41vNnbPMYzl8QbX3FcOW6zu zi2rqqlwLwKGyLHQCAeV6irs0Z7kNlw7pja1Q4ur944+ABv/hVlrYgGNguhKujiz 4MP0bRmn6gXdhGfCZsckAnNate6kGdn8AM62pI3ffr1fsjqdhDFPyGMM5NgNUqN+ ARvUZ6UYKOsBp4I82Y4d5UcNuotZFKMfH0vq4idGhs6dOcRmQafiFSNrVkfB7cVT 5NSAH2v6gEaYsgmmD5W+ZoiTAgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCAQYw EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUXUayjcRLdBy77fVztjq3OI91 nn4wRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3 Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwPQYIKwYBBQUHAQEEMTAv MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWxzaWduLmNvbS9yb290cjEw KQYDVR0lBCIwIAYIKwYBBQUHAwEGCCsGAQUFBwMCBgorBgEEAYI3CgMDMB8GA1Ud IwQYMBaAFGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQBz euwBLBcikZrKsWcYorrIBYmSJN4fuKtEn/dAVWXy4PQux96wP5kVH5VwgumbSmQk IBbwdhfSG/6s+ga0d8+Y2CrsVxXYXk7di5bhUzMZkdWEbiXvD8utv9tLa1bMtdRA PiZetln0xZDJCcSE37wmfYLp6/Rb/MgV3gkYRYazi03HazUnm2D2pFoqWEmx2DVD xjK7XjvESiHBoDtewSOpztvVuv5dbf0AfvrxlDdhuQA5ZpapnLQeEe9V2LTYsMSl rjIKL/gt9KKn/zbTXmOLThL3tSiAde6UL3CgVnc5qjmXF/wA889m56JxkqsFm3Mu eufnIVkJjTChrFzKGXr4 -----END CERTIFICATE----- --- Server certificate subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=*.hotmail.com issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - G2 --- No client certificate CA names sent --- SSL handshake has read 2663 bytes and written 525 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: CC000000BC566476FCB1E77772B326A005BF4D8B998C5D7C505EAAE9C27C53E6 Session-ID-ctx: Master-Key: 44A57A1235FF50BE1F87B530C30F1D09B131D926E913252264FD90BC72B4E3B389BE914D78F7C2BCCF9243CE2433FEA5 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1428400859 Timeout : 7200 (sec) Verify return code: 0 (ok) --- +OK dub0-pop485 POP3 server ready quit +OK POP3 server signing off read:errno=0 Does any of this help? -- Jerry |
|
From: michael c. <mic...@gm...> - 2015-04-07 19:22:04
|
I think fetchmail only cares is the fingerprint the same. When google keeps changing the fingerprint whatever I do "openssl s_client -connect imap.gmail.com:993 -showcerts | openssl x509 -fingerprint -noout - md5" and put that in .fetchmailrc If somebody wants to impersonate gmail to me they can have my mails. cheers |
|
From: Jerry <je...@se...> - 2015-04-07 22:19:41
|
On Tue, 7 Apr 2015 20:21:56 +0100, michael crane stated: > I think fetchmail only cares is the fingerprint the same. > When google keeps changing the fingerprint whatever > I do > "openssl s_client -connect imap.gmail.com:993 -showcerts | openssl > x509 -fingerprint -noout - md5" > and put that in .fetchmailrc > If somebody wants to impersonate gmail to me they can have my mails. > cheers The problem is not with gmail. However, I ran your command and it is producing the exact same fingerprint that I am using. openssl s_client -connect pop3.live.com:995 -showcerts | openssl x509 -fingerprint -noout -md5 depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - G2 verify error:num=20:unable to get local issuer certificate verify return:0 MD5 Fingerprint=86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76 So, that is not the problem. -- Jerry |
|
From: Matthias A. <mat...@gm...> - 2015-04-07 23:29:32
Attachments:
shark.diff.txt
|
Am 07.04.2015 um 12:22 schrieb Jerry: > I guess I should have stated in my original post, that the ".fetchmailrc" > file, etcetera is exactly what I have been using for two years now without a > single problem until few days ago when I updated "openssl" on my system. You > don't have to be genius to figure out that the cause of the problem was the > updated "openssl"; however, what is triggering it is what I am trying to > decipher. You updated openssl to version 1.0.2a from ports. The tricky part is that typing "openssl" would grab the version from /usr/bin and not /usr/local/bin with default PATH, so the version from "openssl version" may not be version of the library that fetchmail is linked against. > Or this: > > openssl s_client -tls1 -crlf -showcerts -verify 5 -CAfile /usr/local/share/certs/ca-root-nss.crt -connect pop3.live.com:995 > verify depth is 5 ... Which is again not what fetchmail would be doing, it just uses SSLv23_*_method() without the -tls1 option. What I know is that installing openssl as a port, rather than using the base system's OpenSSL, has always caused strange problems for me, so let's try something else: > $ /usr/local/bin/openssl s_client -crlf -showcerts -verify 5 \ > -CAfile /usr/local/share/certs/ca-root-nss.crt \ > -connect pop3.live.com:995 > CONNECTED(00000003) > 34381952888:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: Oops! I can reproduce your problem if I compile fetchmail against OpenSSL 1.0.2a, and in Wireshark I see what's going on. This is what comes out of fetchmail's calling SSLOpen() with OpenSSL 1.0.2a: ... (first frames are regular TCP connection set-up, i. e. the normal 3-way >SYN <SYN|ACK >ACK sequence) > Frame 4: 583 bytes on wire (4664 bits), 583 bytes captured (4664 bits) on interface 0 > ... > Secure Sockets Layer > SSL Record Layer: Handshake Protocol: Client Hello > Content Type: Handshake (22) > Version: TLS 1.0 (0x0301) > Length: 512 > Handshake Protocol: Client Hello > Handshake Type: Client Hello (1) > Length: 508 > Version: TLS 1.2 (0x0303) > ... So OpenSSL 1.0.2a wants to negotiate TLS v1.2, with a list of ciphers, and no DEFLATE compression support (not shown here, see attached text file - it And this is what Microsoft's server responds: > Frame 5: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0 > ... > Transmission Control Protocol, Src Port: 995 (995), Dst Port: 25580 (25580), Seq: 1, Ack: 518, Len: 0 > Source Port: 995 (995) > Destination Port: 25580 (25580) > [Stream index: 0] > [TCP Segment Len: 0] > Sequence number: 1 (relative sequence number) > Acknowledgment number: 518 (relative ack number) > Header Length: 32 bytes > .... 0000 0001 0001 = Flags: 0x011 (FIN, ACK) Oops again. The sucker of Microsoft's server doesn't like our SSL client hello message and just hangs up without saying goodbye or telling us of the problem. For some unknown reason, OpenSSL makes it exceptionally hard to identify and repeat this situation. It does not hit the SSL error queue, it does not end up in errno, and it takes guessing from circumstances to figure out that the server just hung up. As a *workaround*, try adding --sslproto tls1 (or --sslproto ssl3 if you have to) for a workaround, or "pkg delete openssl" and rebuild fetchmail (and all other SSL-based applications that got built after you'd installed the OpenSSL 1.0.2+ port or package). I'm not sure what really causes the Microsoft server to hang up with the newer OpenSSL. Might be worth asking on the OpenSSL lists. To identify "base vs. ports/packages OpenSSL", this is what I get with ldd, most importantly, libssl goes to /usr/lib, not /usr/local/lib (ditto for libcrypto, from /lib - not to be confused with libcrypt (without trailing o), which does not matter here.) $ ldd /usr/local/bin/fetchmail /usr/local/bin/fetchmail: libintl.so.8 => /usr/local/lib/libintl.so.8 (0x800858000) libopie.so.7 => /usr/lib/libopie.so.7 (0x800a62000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c6b000) libkvm.so.6 => /lib/libkvm.so.6 (0x800e8b000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x801093000) libssl.so.7 => /usr/lib/libssl.so.7 (0x801295000) libcrypto.so.7 => /lib/libcrypto.so.7 (0x801500000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x8018f4000) ... HTH! |
|
From: Matthias A. <mat...@gm...> - 2015-04-08 00:02:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Git's new legacy_64 branch, as of c3c106ac, now has code to check for this situation and report it as "Server shut down connection prematurely during SSL_connect().", and has other SSL changes and fixes. I need to merge some of the SSL code between legacy_64 and master branches and will then try to do a 6.4.0 beta2 release with updated SSL code shortly. Note that the repository has moved from gitorious.org to https://gitlab.com/groups/fetchmail and the sourceforge.net and my homepage mirrors remain in place and active. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUkcAgACgkQvmGDOQUufZUdYACeNFxS59nuB3V+rbSPwNe/weTf g+MAn30lPPXKT7fB+jTtuHJ+7EonswyB =bV63 -----END PGP SIGNATURE----- |
|
From: Matthias A. <mat...@gm...> - 2015-04-09 16:26:44
|
Am 09.04.2015 um 13:16 schrieb Jerry: > On Wed, 08 Apr 2015 01:29:21 +0200, Matthias Andree stated: > >> As a *workaround*, try adding --sslproto tls1 (or --sslproto ssl3 if you >> have to) for a workaround, or "pkg delete openssl" and rebuild fetchmail >> (and all other SSL-based applications that got built after you'd >> installed the OpenSSL 1.0.2+ port or package). I'm not sure what really >> causes the Microsoft server to hang up with the newer OpenSSL. Might be >> worth asking on the OpenSSL lists. > > Thanks for your hard work on this problem. > > I tried rebuilding "fetchmail" and using the "--sslproto tls1" and > "--sslproto ssl3" settings; however, it still failed to work, although it did > hang for a while before crapping out. That would probably rather point to a local problem because I see the hang-up with OpenSSL 1.0.2* happen right away. No delay. Check ldd, and check with a fetchmail rebuilt after you've removed the openssl pkg. > I am going to see if I can get an answer on the MS forum. Is it all right > with you if I post your debug info on that forum? Yes, it is - this list has public archives anyhow, but I would rather search on the local end. Any other changes happening at the same time as the openssl upgrade? Tried pkg upgrade -f to upgrade everything? |
|
From: Matthias A. <mat...@gm...> - 2015-04-09 20:00:47
|
Am 09.04.2015 um 20:25 schrieb Jerry: > Sorry, about the confusion. I did not remove openssl. Rather, I rebuilt > everything, including fetchmail that depended on it. The problem still exists. Do remove openssl and then rebuild things. This should use the OpenSSL version from the base system. OpenSSL-from-Ports only ever caused trouble for me. |
|
From: Matthias A. <mat...@gm...> - 2015-04-10 17:04:03
|
Am 10.04.2015 um 16:18 schrieb Jerry: > On Thu, 09 Apr 2015 22:00:38 +0200, Matthias Andree stated: > >> Do remove openssl and then rebuild things. This should use the OpenSSL >> version from the base system. OpenSSL-from-Ports only ever caused >> trouble for me. > > Unfortunately, that is not really an option. The "ports" version is tightly > integrated to several other applications that I use. Reverting to the "base > system" version is a step backwards and not one that I feel is advantageous. > > What I am confused about is why MUA's like "Claws-Mail" that utilize > "openssl" from ports is not encountering the same problem that "fetchmail" > is. In any case, at some point, the base system will be updated to the latest > version of "openssl". Therefore it becomes crucial that this problem is > corrected. Jerry, I concur that such a problem needs to be corrected. However, having seen the network traces, I'd say this needs to be fixed on the server's end. Is claws also connecting to pop3.live.com in your situation? What does it do in a different way, compared to fetchmail? The pop3.live.com server in your case just sees the first package of TLS negotiation and directly hangs up, without any more TLS packets. That seems like a protocol violation, thus, a malfunction on the server's end, to me. My interpretation is that pop3.live.com's service (or some preceding application-level firewall) does not support TLS v1.2 and gets scared to death when a client offers TLS v1.2. If the negotiation fails, one normally expects to see something along the lines of > fetchmail: OpenSSL reported: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number (when forcing TLS v1.1 on pop3.live.com, which it rejects) or: > fetchmail: OpenSSL reported: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure (when only offering ciphers that aren't acceptable to the server) but instead you're getting a rude plain disconnect which I also see when /forcing/ TLS v1.2 (I am using the Git master branch for experimenting which allows a bit more control over TLS protocols and ciphers than RELEASE-6-3-26 aka fetchmail-6.3.26 does). Now, retracing your previous setup and workaround experiments: When I suggested to use --sslproto tls1 for a workaround, you got longish delays before the failure. I should mention that you need to be sure to specify --ssl in that case to avoid STARTTLS that is implied by fetchmail 6.3.x versions if you give --sslproto tls1. HTH Matthias |
|
From: Jerry <je...@se...> - 2015-04-09 11:16:12
|
On Wed, 08 Apr 2015 01:29:21 +0200, Matthias Andree stated: > As a *workaround*, try adding --sslproto tls1 (or --sslproto ssl3 if you > have to) for a workaround, or "pkg delete openssl" and rebuild fetchmail > (and all other SSL-based applications that got built after you'd > installed the OpenSSL 1.0.2+ port or package). I'm not sure what really > causes the Microsoft server to hang up with the newer OpenSSL. Might be > worth asking on the OpenSSL lists. Thanks for your hard work on this problem. I tried rebuilding "fetchmail" and using the "--sslproto tls1" and "--sslproto ssl3" settings; however, it still failed to work, although it did hang for a while before crapping out. I am going to see if I can get an answer on the MS forum. Is it all right with you if I post your debug info on that forum? -- Jerry |
|
From: Jerry <je...@se...> - 2015-04-09 18:25:57
|
On Thu, 09 Apr 2015 18:26:34 +0200, Matthias Andree stated: > Am 09.04.2015 um 13:16 schrieb Jerry: > > On Wed, 08 Apr 2015 01:29:21 +0200, Matthias Andree stated: > > > >> As a *workaround*, try adding --sslproto tls1 (or --sslproto ssl3 if you > >> have to) for a workaround, or "pkg delete openssl" and rebuild fetchmail > >> (and all other SSL-based applications that got built after you'd > >> installed the OpenSSL 1.0.2+ port or package). I'm not sure what really > >> causes the Microsoft server to hang up with the newer OpenSSL. Might be > >> worth asking on the OpenSSL lists. > > > > Thanks for your hard work on this problem. > > > > I tried rebuilding "fetchmail" and using the "--sslproto tls1" and > > "--sslproto ssl3" settings; however, it still failed to work, although it > > did hang for a while before crapping out. > > That would probably rather point to a local problem because I see the > hang-up with OpenSSL 1.0.2* happen right away. No delay. > > Check ldd, and check with a fetchmail rebuilt after you've removed the > openssl pkg. > > > I am going to see if I can get an answer on the MS forum. Is it all right > > with you if I post your debug info on that forum? > > Yes, it is - this list has public archives anyhow, but I would rather > search on the local end. Any other changes happening at the same time > as the openssl upgrade? > > Tried pkg upgrade -f to upgrade everything? Sorry, about the confusion. I did not remove openssl. Rather, I rebuilt everything, including fetchmail that depended on it. The problem still exists. -- Jerry |
|
From: Jerry <je...@se...> - 2015-04-10 14:18:37
|
On Thu, 09 Apr 2015 22:00:38 +0200, Matthias Andree stated: > Do remove openssl and then rebuild things. This should use the OpenSSL > version from the base system. OpenSSL-from-Ports only ever caused > trouble for me. Unfortunately, that is not really an option. The "ports" version is tightly integrated to several other applications that I use. Reverting to the "base system" version is a step backwards and not one that I feel is advantageous. What I am confused about is why MUA's like "Claws-Mail" that utilize "openssl" from ports is not encountering the same problem that "fetchmail" is. In any case, at some point, the base system will be updated to the latest version of "openssl". Therefore it becomes crucial that this problem is corrected. Just my 2¢. -- Jerry |
|
From: Jerry <je...@se...> - 2015-04-10 20:04:12
|
On Fri, 10 Apr 2015 19:03:54 +0200, Matthias Andree stated: > Now, retracing your previous setup and workaround experiments: > When I suggested to use --sslproto tls1 for a workaround, > you got longish delays before the failure. > > I should mention that you need to be sure to specify --ssl in that case > to avoid STARTTLS that is implied by fetchmail 6.3.x versions if you > give --sslproto tls1. Success: env LC_ALL=C fetchmail --nodetach -vvv --nosyslog Old UID list from pop3.live.com: <empty> Scratch list of UIDs: <empty> fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Fri Apr 10 15:55:38 2015: poll started Trying to connect to 134.170.170.231/995...connected. fetchmail: Certificate chain, from root to peer, starting at depth 2: fetchmail: Issuer Organization: GlobalSign nv-sa fetchmail: Issuer CommonName: GlobalSign Root CA fetchmail: Subject CommonName: GlobalSign Root CA fetchmail: Certificate at depth 1: fetchmail: Issuer Organization: GlobalSign nv-sa fetchmail: Issuer CommonName: GlobalSign Root CA fetchmail: Subject CommonName: GlobalSign Organization Validation CA - G2 fetchmail: Server certificate: fetchmail: Issuer Organization: GlobalSign nv-sa fetchmail: Issuer CommonName: GlobalSign Organization Validation CA - G2 fetchmail: Subject CommonName: *.hotmail.com fetchmail: Subject Alternative Name: *.hotmail.com fetchmail: Subject Alternative Name: *.live.com fetchmail: Subject Alternative Name: *.outlook.com fetchmail: Subject Alternative Name: hotmail.com fetchmail: pop3.live.com key fingerprint: 86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76 fetchmail: pop3.live.com fingerprints match. fetchmail: POP3< +OK dub0-pop605 POP3 server ready fetchmail: POP3> CAPA fetchmail: POP3< -ERR unrecognized command fetchmail: unrecognized command fetchmail: Repoll immediately on ME...@ou...@pop3.glbdns2.microsoft.com Trying to connect to 134.170.170.231/995...connected. fetchmail: Certificate chain, from root to peer, starting at depth 2: fetchmail: Issuer Organization: GlobalSign nv-sa fetchmail: Issuer CommonName: GlobalSign Root CA fetchmail: Subject CommonName: GlobalSign Root CA fetchmail: Certificate at depth 1: fetchmail: Issuer Organization: GlobalSign nv-sa fetchmail: Issuer CommonName: GlobalSign Root CA fetchmail: Subject CommonName: GlobalSign Organization Validation CA - G2 fetchmail: Server certificate: fetchmail: Issuer Organization: GlobalSign nv-sa fetchmail: Issuer CommonName: GlobalSign Organization Validation CA - G2 fetchmail: Subject CommonName: *.hotmail.com fetchmail: Subject Alternative Name: *.hotmail.com fetchmail: Subject Alternative Name: *.live.com fetchmail: Subject Alternative Name: *.outlook.com fetchmail: Subject Alternative Name: hotmail.com fetchmail: pop3.live.com key fingerprint: 86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76 fetchmail: pop3.live.com fingerprints match. fetchmail: POP3< +OK dub0-pop599 POP3 server ready fetchmail: POP3> USER ME...@ou... fetchmail: POP3< +OK password required fetchmail: POP3> PASS * fetchmail: POP3< +OK mailbox has 0 messages fetchmail: selecting or re-polling default folder fetchmail: POP3> STAT fetchmail: POP3< +OK 0 0 fetchmail: No mail for ME...@ou... at pop3.live.com fetchmail: POP3> QUIT fetchmail: POP3< +OK mailbox unchanged, POP3 server signing off fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Fri Apr 10 15:55:50 2015: poll completed New UID list from pop3.live.com: <empty> fetchmail: not swapping UID lists, no UIDs seen this query fetchmail: Query status=1 (NOMAIL) fetchmail: normal termination, status 1 I have this in the ".fetchmailrc" file: poll pop3.live.com with proto POP3 service 995 timeout 30 and options bad-header accept user 'ME...@ou...' there with password 'PASSWORD' is 'ME' here options flush forcecr dropdelivered smtpname 'ME...@IS...' sslproto tls1 ssl sslfingerprint '86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76' Anyway, at least it is working again. Thanks for your assistance. -- Jerry |
|
From: Matthias A. <mat...@gm...> - 2015-04-11 09:10:54
|
Am 10.04.2015 um 22:04 schrieb Jerry: > On Fri, 10 Apr 2015 19:03:54 +0200, Matthias Andree stated: > >> Now, retracing your previous setup and workaround experiments: >> When I suggested to use --sslproto tls1 for a workaround, >> you got longish delays before the failure. >> >> I should mention that you need to be sure to specify --ssl in that case >> to avoid STARTTLS that is implied by fetchmail 6.3.x versions if you >> give --sslproto tls1. > > Success: > > env LC_ALL=C fetchmail --nodetach -vvv --nosyslog > Old UID list from pop3.live.com: <empty> > Scratch list of UIDs: <empty> > fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Fri Apr 10 15:55:38 2015: poll started > Trying to connect to 134.170.170.231/995...connected. > fetchmail: Certificate chain, from root to peer, starting at depth 2: ... > fetchmail: pop3.live.com key fingerprint: 86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76 > fetchmail: pop3.live.com fingerprints match. > fetchmail: POP3< +OK dub0-pop605 POP3 server ready ... > Anyway, at least it is working again. Thanks for your assistance. OK, thank you for this feedback. JFTR, the --ssl is not a general requirement (many servers will also be happy with STARTTLS), but specific to servers that only offer SSL/TLS-wrapped POP3 (or IMAP) on port 995 (or 993, for IMAP), but do not offer STARTTLS or similar on the default ports 110 (for POP3) or 143 (for IMAP). I suppose you might have removed that in the first experiment when you added --sslproto, and maybe my instructions weren't clear on what I was suggesting to do. Lesson learned: we probably need to be able to specify TLS versions explicitly in future fetchmail versions so that users can work around server limitations. I don't currently think any of this can be automatic though - version fallback would be too dangerous. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X