| Summary: | net-mail/fetchmail-6.3.6 SSL/TLS negotation fails on some servers | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Walther <walther.md> |
| Component: | Current packages | Assignee: | Net-Mail Packages <net-mail+disabled> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | normal | CC: | matsuu, matthias.andree |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
patch to fix STLS regression
Patch to repoll on protocol errors (such as this) as well. |
||
|
Description
Walther
2007-01-25 17:46:00 UTC
Reported at upstream bug tracker: https://developer.berlios.de/bugs/?func=detailbug&bug_id=10133&group_id=1824 Note that I got a different error with TLS negotiation. Can you please post your .fetchmailrc entry for this server? (With obfuscated password and/or username, of course) The fetchmailrc file I use is quite simple:
# Configuration created Wed Sep 18 12:13:34 2002 by fetchmailconf
set postmaster "<my linux user>"
set bouncemail
set daemon 30
set no spambounce
poll gye.satnet.net
proto pop3
user "<username here>"
pass "<password here>"
is <linux username here>
limit 0
fetchall
As you can see, this seems like a very easy to reproduce problem. I just wonder if something may be broken in the ISP rather than fetchmail... but if it worked on the previous version, then it's more likely that something broke on the latest version instead.
Same here. fetchmail: POP3< +OK <17661.1170383361@svr306> fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< LAST fetchmail: POP3< USER fetchmail: POP3< APOP fetchmail: POP3< STLS fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK starting TLS negotiation fetchmail: <hostname>: opportunistic upgrade to TLS failed, trying to continue . fetchmail: POP3> USER <username> fetchmail: POP3< authorization first 27126:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c: 288: fetchmail: Unknown login or authentication error on <username>@<hostname> fetchmail: POP3> QUIT fetchmail: POP3< -ERR authorization first fetchmail: authorization first fetchmail: client/server protocol error while fetching from <username>@<hostname> fetchmail: 6.3.6 querying <hostname> (protocol POP3) at Fri Feb 2 11:29:21 20 07: poll completed Fetchmail upstream have admitted that there is a regression in 6.3.6 (see link at comment #1), so until it's fixed in next release, please use previous versions where it works. This bug is supposed to be fixed in the upstream 6.3.7-rc1 version. -- Matthias Andree, upstream fetchmail maintainer (thanks for the Gentoo bug # in our upstream tracker) Created attachment 110451 [details, diff]
patch to fix STLS regression
As there's already a release candidate for 6.3.7, I think we'll wait for 6.3.7 to come out instead of applying the patch. Thanks for the info, Matthias! 6.3.7 is out, and has just entered Portage tree. Please test. error occurred. fetchmail: 6.3.7 querying <hostnameA> (protocol POP3) at Tue Feb 20 14:04:36 2007: poll started Trying to connect to <ipaddressA>/110...connected. fetchmail: POP3< +OK <21929.1171947876@svr306> fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< LAST fetchmail: POP3< USER fetchmail: POP3< APOP fetchmail: POP3< STLS fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK starting TLS negotiation 23391:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:288: fetchmail: <hostnameA>: opportunistic upgrade to TLS failed, trying to continue. fetchmail: POP3> USER <usernameA> fetchmail: POP3< authorization first fetchmail: Unknown login or authentication error on <usernameA>@<hostnameA> fetchmail: POP3> QUIT fetchmail: POP3< -ERR authorization first fetchmail: authorization first fetchmail: client/server protocol error while fetching from <usernameA>@<hostnameA> fetchmail: 6.3.7 querying <hostnameA> (protocol POP3) at Tue Feb 20 14:04:37 2007: poll completed fetchmail: Query status=4 (PROTOCOL) fetchmail: 6.3.7 querying <hostnameB> (protocol POP3) at Tue Feb 20 14:04:37 2007: poll started [snip] fetchmail: 6.3.7 querying <hostnameB> (protocol POP3) at Tue Feb 20 14:04:38 2007: poll completed fetchmail: normal termination, status 0 $ cat .fetchmailrc set postmaster <account> set no bouncemail defaults protocol pop3 flush no mimedecode smtphost localhost poll <hostnameA> user <usernameA> password <password> poll <hostnameB> user <usernameB> password <password> ssl sslfingerprint <fingerprint> If I put 'sslproto ""' in hostnameA, it successfully fetched. Although this looks like a genuine server bug, it should be possible to work around this - the only upstream concern however is that we don't go through wastefull disconnect/reconnect cycles unless we have to. Comment #9 documents one such case. Thanks, Takuto! Please reopen this bug, since comment #9 provides evidence this isn't fixed yet. Created attachment 111758 [details, diff] Patch to repoll on protocol errors (such as this) as well. This new patch (incremental to the previous for 6.3.6; self-sufficient for 6.3.7) should fix the problem reported in comment #9, by retrying the whole poll without SSL if protocol errors occur after USER command. the patch works fine on my env. Thank you; I've committed the patch to the upstream SVN repository, it will become part of fetchmail 6.3.8. Thanks Matthias. Applied patch in 6.3.7-r1. I don't think patching 6.3.6 (current stable) is necessary, as this is not a common issue. If anyone disagrees, feel free to poke me and I'll bump 6.3.6 with both patches applied. |
