Menu
▾
▴
fetchmail-devel — Development related discussion
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(73) |
Jul
(22) |
Aug
(42) |
Sep
(11) |
Oct
(23) |
Nov
(40) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
|
Mar
(17) |
Apr
(26) |
May
(6) |
Jun
(21) |
Jul
(133) |
Aug
(25) |
Sep
(40) |
Oct
(12) |
Nov
(71) |
Dec
(57) |
| 2006 |
Jan
(23) |
Feb
(22) |
Mar
(43) |
Apr
(27) |
May
(13) |
Jun
(7) |
Jul
(3) |
Aug
(20) |
Sep
(16) |
Oct
(17) |
Nov
(31) |
Dec
(10) |
| 2007 |
Jan
(12) |
Feb
(17) |
Mar
(26) |
Apr
(13) |
May
(4) |
Jun
(1) |
Jul
(1) |
Aug
(21) |
Sep
(3) |
Oct
(8) |
Nov
(8) |
Dec
(5) |
| 2008 |
Jan
(5) |
Feb
(1) |
Mar
(3) |
Apr
(10) |
May
(3) |
Jun
(11) |
Jul
(5) |
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(10) |
Dec
(2) |
| 2009 |
Jan
(17) |
Feb
(2) |
Mar
(1) |
Apr
(9) |
May
(23) |
Jun
(22) |
Jul
(32) |
Aug
(30) |
Sep
(11) |
Oct
(24) |
Nov
(4) |
Dec
|
| 2010 |
Jan
(12) |
Feb
(56) |
Mar
(32) |
Apr
(41) |
May
(36) |
Jun
(14) |
Jul
(7) |
Aug
(10) |
Sep
(13) |
Oct
(16) |
Nov
|
Dec
(14) |
| 2011 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(16) |
May
(36) |
Jun
(2) |
Jul
|
Aug
(9) |
Sep
(2) |
Oct
(1) |
Nov
(8) |
Dec
(3) |
| 2012 |
Jan
(1) |
Feb
(5) |
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(7) |
Sep
(9) |
Oct
(2) |
Nov
(8) |
Dec
(9) |
| 2013 |
Jan
(11) |
Feb
(6) |
Mar
(14) |
Apr
(10) |
May
|
Jun
(12) |
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(7) |
Dec
(4) |
| 2014 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(7) |
Jul
|
Aug
(8) |
Sep
(8) |
Oct
|
Nov
|
Dec
(2) |
| 2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(2) |
Feb
(3) |
Mar
(5) |
Apr
(2) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(2) |
Sep
(3) |
Oct
(4) |
Nov
(3) |
Dec
|
| 2021 |
Jan
(5) |
Feb
(2) |
Mar
(3) |
Apr
(3) |
May
|
Jun
|
Jul
(2) |
Aug
(14) |
Sep
(3) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2022 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2023 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Translation P. R. <ro...@tr...> - 2013-01-27 13:46:16
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the Esperanto team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/eo.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: <ad...@be...> - 2013-01-24 19:09:43
|
Bug #18863, was updated on 2013-Jan-07 20:04 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Closed Resolution: Invalid Bug Group: None Priority: 5 Submitted by: m-a Assigned to : m-a Summary: fetchmail 6.3.24 ignores LOGINDISABLED Details: https://lists.berlios.de/pipermail/fetchmail-users/2013-January/003298.html https://lists.berlios.de/pipermail/fetchmail-users/2013-January/003303.html Follow-Ups: Date: 2013-Jan-24 19:09 By: m-a Comment: fetchmail only ignores LOGINDISABLED if password authentication is explicitly requested ------------------------------------------------------- Date: 2013-Jan-07 20:05 By: m-a Comment: this probably also includes older versions, and may require a fetchmail version configured without SSL support to show in practice ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18863&group_id=1824 |
|
From: <ad...@be...> - 2013-01-07 20:05:17
|
Bug #18863, was updated on 2013-Jan-07 20:04 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: m-a Assigned to : m-a Summary: fetchmail 6.3.24 ignores LOGINDISABLED Details: https://lists.berlios.de/pipermail/fetchmail-users/2013-January/003298.html https://lists.berlios.de/pipermail/fetchmail-users/2013-January/003303.html Follow-Ups: Date: 2013-Jan-07 20:05 By: m-a Comment: this probably also includes older versions, and may require a fetchmail version configured without SSL support to show in practice ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18863&group_id=1824 |
|
From: <ad...@be...> - 2013-01-07 20:04:41
|
Bug #18863, was updated on 2013-Jan-07 20:04 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: m-a Assigned to : m-a Summary: fetchmail 6.3.24 ignores LOGINDISABLED Details: https://lists.berlios.de/pipermail/fetchmail-users/2013-January/003298.html https://lists.berlios.de/pipermail/fetchmail-users/2013-January/003303.html For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18863&group_id=1824 |
|
From: <ad...@be...> - 2013-01-06 23:43:33
|
Bug #18853, was updated on 2013-Jan-03 22:49 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 4 Submitted by: w-f Assigned to : none Summary: IMAP IDLE + SSL: Error: re-poll failed Details: I use fetchmail with SSL and IMAP IDLE. The IMAP connection freezes after some time and the re-poll failed after 28 min. It looks like there is a ssl socket timeout before a IMAP IDLE re-poll is issued. ----- Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP> A0005 IDLE Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP< + OK Jan 3 20:59:35 mini2 fetchmail[14842]: IMAP> DONE Jan 3 20:59:35 mini2 fetchmail[14842]: re-poll failed Jan 3 20:59:35 mini2 fetchmail[14842]: socket error while fetching from web...@fi...@imap.strato.de Jan 3 20:59:35 mini2 fetchmail[14842]: 6.3.24 querying imap.strato.de (protocol IMAP) at Thu, 03 Jan 2013 20:59:35 +0100 (CET): poll completed Jan 3 20:59:35 mini2 fetchmail[14842]: Query status=2 (SOCKET) ----- The re-poll does not fail, when the idle timeout is reduced from 28 min to 10 minutes. This should also fulfil the RFC 2177, because the RFC suggests to re-issue a IDLE command at LEAST every 29 minutes. RFC 2177 "The server MAY consider a client inactive if it has an IDLE command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLE are advised to terminate the IDLE and re-issue it at least every 29 minutes to avoid being logged off. This still allows a client to receive immediate mailbox updates even though it need only "poll" at half hour intervals." Other IMAP Clients uses a shorter IDLE re-poll timer or issues a NOOP Command. Microsoft Outlook: 10 min Apple Mail: IMAP NOOP every 1 minute (RFC 3501: "The NOOP command can also be used to reset any inactivity autologout timer on the server.") ------ Patch (Reduce idle_timeout to 600) diff fetchmail-6.3.24-patched/imap.c fetchmail-6.3.24/imap.c 718,719c718 < /* mytimeout = idle_timeout = 1680; */ /* 28 min */ < mytimeout = idle_timeout = 600; /* reduce to 10 min to prevent ssl socket timeout */ --- > mytimeout = idle_timeout = 1680; /* 28 min */ Enviroment: fetchmail 6.3.24 OS: Mac OS 10.7.5 IMAP Server: Provider Strato (imap.strato.de) --- Best regards, Wolfgang Follow-Ups: Date: 2013-Jan-06 22:43 By: w-f Comment: Hello Matthias, I did a dtrace for the SSL case and non-SSL case. In both variants the TCP KeepAlive is enabled. 199552 20 14 socket(0x2, 0x1, 0x6) = 5 0 199559 8 2 setsockopt(0x5, 0xFFFF, 0x8) = 0 0 199634 21589 72 connect(0x5, 0x7FAF0AC01320, 0x10) = 0 0 But there is an other difference: The non-ssl socket uses the system call recvfrom to wait for data from the imap server during the idle time. The ssl socket uses the system call "read" to wait for data from the imap server during the idle time. The tcp stack sends no KeepAlive Packets during the system call read. You can download the complete dtrace files for both variants from https://www.hidrive.strato.com/lnk/RBTrVUhJ Best regards, Wolfgang ------------------------------------------------------- Date: 2013-Jan-06 13:29 By: m-a Comment: Wolfgang, could you dtrace setsockopt and/or all socket option, for (1) the SSL case, (2) the non-SSL case? I unconditionally enable SO_KEEPALIVE after the socket has been opened, and never see them disabled - perhaps your OpenSSL library behaves differently. Best regards, Matthias ------------------------------------------------------- Date: 2013-Jan-06 13:20 By: m-a Comment: Thanks for the detailed information. However, this pretty much looks like a networking issue. The server just hung up, but there was no FIN|ACK handshake from closing down the connection, so fetchmail was not informed of the shutdown or close until it tried to send the next packet. This pretty much looks like a networking issue, broken router or NAT or Masquerading. I'll grant that TCP keepalives might help. Unfortunately, strato does not appear to support STARTTLS, so we cannot test that. ------------------------------------------------------- Date: 2013-Jan-05 19:50 By: w-f Comment: The issue is not an server imap timeout. There are no problems when using an unencrypted imap session. The dtruss shows no activity during the idle time: 22867/0xaf6c4: 629137 33 24 write(0x5, "\027\003\0", 0x25) = 37 0 22867/0xaf6c4: 629147 9 3 __sysctl(0x7FFF60CF8FE8, 0x2, 0x7FFF60CF8FFF) = 0 0 22867/0xaf6c4: 629150 5 0 getuid(0x0, 0x7FFF60CF8C58, 0x0) = 273 0 22867/0xaf6c4: 629152 5 0 getgid(0x0, 0x7FFF60CF8C58, 0x0) = 1 0 22867/0xaf6c4: 629184 9 3 setitimer(0x0, 0x7FFF60CF7E00, 0x0) = 0 0 dtrace: error on enabled probe ID 1791 (ID 778: syscall::read:return): out of scratch space in action #13 at DIF offset 44 dtrace: error on enabled probe ID 1791 (ID 778: syscall::read:return): out of scratch space in action #13 at DIF offset 44 dtrace: error on enabled probe ID 1789 (ID 780: syscall::write:return): out of scratch space in action #13 at DIF offset 44 22867/0xaf6c4: 629354 343 20 sigreturn(0x7FFF60CF7B50, 0x1E, 0x7FFF60CF7B50) = 0 Err#-2 22867/0xaf6c4: 629358 8 0 __pthread_canceled(0x0, 0x7FE06C015000, 0x7FFF60CF7C08) = -1 Err#22 22867/0xaf6c4: 629372 8 1 setitimer(0x0, 0x7FFF60CF7E00, 0x0) = 0 0 22867/0xaf6c4: 629454 66 58 write(0x5, "\027\003\0", 0x1F) = 31 0 22867/0xaf6c4: 629481 15 8 __sysctl(0x7FFF60CFB0F8, 0x2, 0x7FFF60CFB10F) = 0 0 22867/0xaf6c4: 629485 6 0 getuid(0x0, 0x7FFF60CFAD68, 0x0) = 273 0 22867/0xaf6c4: 629487 6 0 getgid(0x0, 0x7FFF60CFAD68, 0x0) = 1 0 22867/0xaf6c4: 629533 10 4 setitimer(0x0, 0x7FFF60CF9F30, 0x0) = 0 0 22867/0xaf6c4: 629566 13 1 setitimer(0x0, 0x7FFF60CF9F30, 0x0) = 0 0 22867/0xaf6c4: 629569 5 0 setitimer(0x0, 0x7FFF60CFBFD0, 0x0) = 0 0 22867/0xaf6c4: 629596 14 7 __sysctl(0x7FFF60CFB118, 0x2, 0x7FFF60CFB12F) = 0 0 22867/0xaf6c4: 629600 5 0 getuid(0x0, 0x7FFF60CFAD88, 0x0) = 273 0 22867/0xaf6c4: 629602 5 0 getgid(0x0, 0x7FFF60CFAD88, 0x0) = 1 0 22867/0xaf6c4: 629648 10 2 sigaction(0xE, 0x7FFF60D00098, 0x7FFF60D000C0) = 0 0 22867/0xaf6c4: 629653 8 2 setitimer(0x0, 0x7FFF60D00278, 0x0) = 0 0 22867/0xaf6c4: 629849 18 9 close(0x5) = 0 0 22867/0xaf6c4: 629852 6 1 setitimer(0x0, 0x7FFF60D00298, 0x0) = 0 0 22867/0xaf6c4: 629854 6 0 sigaction(0xE, 0x7FFF60D00098, 0x7FFF60D000C0) = 0 0 22867/0xaf6c4: 629867 9 3 __sysctl(0x7FFF60CFF1E8, 0x2, 0x7FFF60CFF1FF) = 0 0 Also there is no network traffic during the idle time. And the response for first packet TCP Push from fetchmail to the imap server is a Reset. tcp dump IMAPS Session: ------ 18:42:48.547781 IP (tos 0x0, ttl 64, id 25398, offset 0, flags [DF], proto TCP (6), length 77) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [P.], cksum 0x4c5f (incorrect -> 0x2baf), seq 743:780, ack 4504, win 33396, length 37 18:42:48.568631 IP (tos 0x0, ttl 248, id 36786, offset 0, flags [DF], proto TCP (6), length 71) imap.strato.de.imaps > mini2.home.fischer-net.net.60975: Flags [P.], cksum 0x5a30 (correct), seq 4504:4535, ack 780, win 5135, length 31 18:42:48.568693 IP (tos 0x0, ttl 64, id 64318, offset 0, flags [DF], proto TCP (6), length 40) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [.], cksum 0x4c3a (incorrect -> 0xd50a), seq 780, ack 4535, win 33380, length 0 19:10:48.624932 IP (tos 0x0, ttl 64, id 12889, offset 0, flags [DF], proto TCP (6), length 71) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [P.], cksum 0x4c59 (incorrect -> 0xfd06), seq 780:811, ack 4535, win 33396, length 31 19:10:48.646571 IP (tos 0x0, ttl 248, id 18517, offset 0, flags [DF], proto TCP (6), length 40) imap.strato.de.imaps > mini2.home.fischer-net.net.60975: Flags [R.], cksum 0x574c (correct), seq 4535, ack 811, win 0, length 0 19:11:49.041641 IP (tos 0x0, ttl 64, id 1235, offset 0, flags [DF], proto TCP (6), length 64) mini2.home.fischer-net.net.61035 > imap.strato.de.imaps: Flags [S], cksum 0x4c52 (incorrect -> 0x0b3e), seq 771336041, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 1029692052 ecr 0,sackOK,eol], length 0 19:11:49.063272 IP (tos 0x0, ttl 248, id 26043, offset 0, flags [DF], proto TCP (6), length 52) imap.strato.de.imaps > mini2.home.fischer-net.net.61035: Flags [S.], cksum 0x1718 (correct), seq 2700448559, ack 771336042, win 4356, options [mss 1452,nop,wscale 0,sackOK,eol], length 0 ----- Now for me looks like the issue is, fetchmail opens the Socket for the SSL Session without a TCP KeepAlive. When I use an unencrypted imap session, the TCP KeepAlive is active. The tcpdump shows the TCP KeepAlive packets during the imap idle time. Best Regards, Wolfgang ------------------------------------------------------- Date: 2013-Jan-03 23:02 By: m-a Comment: Have Strato fix their server timeouts instead, the 30 minute timer is a "MUST" clause in RFC-3501 section 5.4, see http://tools.ietf.org/html/rfc3501#section-5.4 If there is a socket timeout, I'd like to see an strace or truss trace proving it, and possibly an accompanying tcpdump or wireshark/tshark dump of the protocol with timestamps, to see when the connection gets closed. Chances are that there is a problem on your end - are you using IPv4 NAT or Masquerading? ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18853&group_id=1824 |
|
From: <ad...@be...> - 2013-01-06 13:29:37
|
Bug #18853, was updated on 2013-Jan-03 22:49 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 4 Submitted by: w-f Assigned to : none Summary: IMAP IDLE + SSL: Error: re-poll failed Details: I use fetchmail with SSL and IMAP IDLE. The IMAP connection freezes after some time and the re-poll failed after 28 min. It looks like there is a ssl socket timeout before a IMAP IDLE re-poll is issued. ----- Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP> A0005 IDLE Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP< + OK Jan 3 20:59:35 mini2 fetchmail[14842]: IMAP> DONE Jan 3 20:59:35 mini2 fetchmail[14842]: re-poll failed Jan 3 20:59:35 mini2 fetchmail[14842]: socket error while fetching from web...@fi...@imap.strato.de Jan 3 20:59:35 mini2 fetchmail[14842]: 6.3.24 querying imap.strato.de (protocol IMAP) at Thu, 03 Jan 2013 20:59:35 +0100 (CET): poll completed Jan 3 20:59:35 mini2 fetchmail[14842]: Query status=2 (SOCKET) ----- The re-poll does not fail, when the idle timeout is reduced from 28 min to 10 minutes. This should also fulfil the RFC 2177, because the RFC suggests to re-issue a IDLE command at LEAST every 29 minutes. RFC 2177 "The server MAY consider a client inactive if it has an IDLE command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLE are advised to terminate the IDLE and re-issue it at least every 29 minutes to avoid being logged off. This still allows a client to receive immediate mailbox updates even though it need only "poll" at half hour intervals." Other IMAP Clients uses a shorter IDLE re-poll timer or issues a NOOP Command. Microsoft Outlook: 10 min Apple Mail: IMAP NOOP every 1 minute (RFC 3501: "The NOOP command can also be used to reset any inactivity autologout timer on the server.") ------ Patch (Reduce idle_timeout to 600) diff fetchmail-6.3.24-patched/imap.c fetchmail-6.3.24/imap.c 718,719c718 < /* mytimeout = idle_timeout = 1680; */ /* 28 min */ < mytimeout = idle_timeout = 600; /* reduce to 10 min to prevent ssl socket timeout */ --- > mytimeout = idle_timeout = 1680; /* 28 min */ Enviroment: fetchmail 6.3.24 OS: Mac OS 10.7.5 IMAP Server: Provider Strato (imap.strato.de) --- Best regards, Wolfgang Follow-Ups: Date: 2013-Jan-06 13:29 By: m-a Comment: Wolfgang, could you dtrace setsockopt and/or all socket option, for (1) the SSL case, (2) the non-SSL case? I unconditionally enable SO_KEEPALIVE after the socket has been opened, and never see them disabled - perhaps your OpenSSL library behaves differently. Best regards, Matthias ------------------------------------------------------- Date: 2013-Jan-06 13:20 By: m-a Comment: Thanks for the detailed information. However, this pretty much looks like a networking issue. The server just hung up, but there was no FIN|ACK handshake from closing down the connection, so fetchmail was not informed of the shutdown or close until it tried to send the next packet. This pretty much looks like a networking issue, broken router or NAT or Masquerading. I'll grant that TCP keepalives might help. Unfortunately, strato does not appear to support STARTTLS, so we cannot test that. ------------------------------------------------------- Date: 2013-Jan-05 19:50 By: w-f Comment: The issue is not an server imap timeout. There are no problems when using an unencrypted imap session. The dtruss shows no activity during the idle time: 22867/0xaf6c4: 629137 33 24 write(0x5, "\027\003\0", 0x25) = 37 0 22867/0xaf6c4: 629147 9 3 __sysctl(0x7FFF60CF8FE8, 0x2, 0x7FFF60CF8FFF) = 0 0 22867/0xaf6c4: 629150 5 0 getuid(0x0, 0x7FFF60CF8C58, 0x0) = 273 0 22867/0xaf6c4: 629152 5 0 getgid(0x0, 0x7FFF60CF8C58, 0x0) = 1 0 22867/0xaf6c4: 629184 9 3 setitimer(0x0, 0x7FFF60CF7E00, 0x0) = 0 0 dtrace: error on enabled probe ID 1791 (ID 778: syscall::read:return): out of scratch space in action #13 at DIF offset 44 dtrace: error on enabled probe ID 1791 (ID 778: syscall::read:return): out of scratch space in action #13 at DIF offset 44 dtrace: error on enabled probe ID 1789 (ID 780: syscall::write:return): out of scratch space in action #13 at DIF offset 44 22867/0xaf6c4: 629354 343 20 sigreturn(0x7FFF60CF7B50, 0x1E, 0x7FFF60CF7B50) = 0 Err#-2 22867/0xaf6c4: 629358 8 0 __pthread_canceled(0x0, 0x7FE06C015000, 0x7FFF60CF7C08) = -1 Err#22 22867/0xaf6c4: 629372 8 1 setitimer(0x0, 0x7FFF60CF7E00, 0x0) = 0 0 22867/0xaf6c4: 629454 66 58 write(0x5, "\027\003\0", 0x1F) = 31 0 22867/0xaf6c4: 629481 15 8 __sysctl(0x7FFF60CFB0F8, 0x2, 0x7FFF60CFB10F) = 0 0 22867/0xaf6c4: 629485 6 0 getuid(0x0, 0x7FFF60CFAD68, 0x0) = 273 0 22867/0xaf6c4: 629487 6 0 getgid(0x0, 0x7FFF60CFAD68, 0x0) = 1 0 22867/0xaf6c4: 629533 10 4 setitimer(0x0, 0x7FFF60CF9F30, 0x0) = 0 0 22867/0xaf6c4: 629566 13 1 setitimer(0x0, 0x7FFF60CF9F30, 0x0) = 0 0 22867/0xaf6c4: 629569 5 0 setitimer(0x0, 0x7FFF60CFBFD0, 0x0) = 0 0 22867/0xaf6c4: 629596 14 7 __sysctl(0x7FFF60CFB118, 0x2, 0x7FFF60CFB12F) = 0 0 22867/0xaf6c4: 629600 5 0 getuid(0x0, 0x7FFF60CFAD88, 0x0) = 273 0 22867/0xaf6c4: 629602 5 0 getgid(0x0, 0x7FFF60CFAD88, 0x0) = 1 0 22867/0xaf6c4: 629648 10 2 sigaction(0xE, 0x7FFF60D00098, 0x7FFF60D000C0) = 0 0 22867/0xaf6c4: 629653 8 2 setitimer(0x0, 0x7FFF60D00278, 0x0) = 0 0 22867/0xaf6c4: 629849 18 9 close(0x5) = 0 0 22867/0xaf6c4: 629852 6 1 setitimer(0x0, 0x7FFF60D00298, 0x0) = 0 0 22867/0xaf6c4: 629854 6 0 sigaction(0xE, 0x7FFF60D00098, 0x7FFF60D000C0) = 0 0 22867/0xaf6c4: 629867 9 3 __sysctl(0x7FFF60CFF1E8, 0x2, 0x7FFF60CFF1FF) = 0 0 Also there is no network traffic during the idle time. And the response for first packet TCP Push from fetchmail to the imap server is a Reset. tcp dump IMAPS Session: ------ 18:42:48.547781 IP (tos 0x0, ttl 64, id 25398, offset 0, flags [DF], proto TCP (6), length 77) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [P.], cksum 0x4c5f (incorrect -> 0x2baf), seq 743:780, ack 4504, win 33396, length 37 18:42:48.568631 IP (tos 0x0, ttl 248, id 36786, offset 0, flags [DF], proto TCP (6), length 71) imap.strato.de.imaps > mini2.home.fischer-net.net.60975: Flags [P.], cksum 0x5a30 (correct), seq 4504:4535, ack 780, win 5135, length 31 18:42:48.568693 IP (tos 0x0, ttl 64, id 64318, offset 0, flags [DF], proto TCP (6), length 40) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [.], cksum 0x4c3a (incorrect -> 0xd50a), seq 780, ack 4535, win 33380, length 0 19:10:48.624932 IP (tos 0x0, ttl 64, id 12889, offset 0, flags [DF], proto TCP (6), length 71) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [P.], cksum 0x4c59 (incorrect -> 0xfd06), seq 780:811, ack 4535, win 33396, length 31 19:10:48.646571 IP (tos 0x0, ttl 248, id 18517, offset 0, flags [DF], proto TCP (6), length 40) imap.strato.de.imaps > mini2.home.fischer-net.net.60975: Flags [R.], cksum 0x574c (correct), seq 4535, ack 811, win 0, length 0 19:11:49.041641 IP (tos 0x0, ttl 64, id 1235, offset 0, flags [DF], proto TCP (6), length 64) mini2.home.fischer-net.net.61035 > imap.strato.de.imaps: Flags [S], cksum 0x4c52 (incorrect -> 0x0b3e), seq 771336041, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 1029692052 ecr 0,sackOK,eol], length 0 19:11:49.063272 IP (tos 0x0, ttl 248, id 26043, offset 0, flags [DF], proto TCP (6), length 52) imap.strato.de.imaps > mini2.home.fischer-net.net.61035: Flags [S.], cksum 0x1718 (correct), seq 2700448559, ack 771336042, win 4356, options [mss 1452,nop,wscale 0,sackOK,eol], length 0 ----- Now for me looks like the issue is, fetchmail opens the Socket for the SSL Session without a TCP KeepAlive. When I use an unencrypted imap session, the TCP KeepAlive is active. The tcpdump shows the TCP KeepAlive packets during the imap idle time. Best Regards, Wolfgang ------------------------------------------------------- Date: 2013-Jan-03 23:02 By: m-a Comment: Have Strato fix their server timeouts instead, the 30 minute timer is a "MUST" clause in RFC-3501 section 5.4, see http://tools.ietf.org/html/rfc3501#section-5.4 If there is a socket timeout, I'd like to see an strace or truss trace proving it, and possibly an accompanying tcpdump or wireshark/tshark dump of the protocol with timestamps, to see when the connection gets closed. Chances are that there is a problem on your end - are you using IPv4 NAT or Masquerading? ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18853&group_id=1824 |
|
From: <ad...@be...> - 2013-01-06 13:20:05
|
Bug #18853, was updated on 2013-Jan-03 22:49 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 3 Submitted by: w-f Assigned to : none Summary: IMAP IDLE + SSL: Error: re-poll failed Details: I use fetchmail with SSL and IMAP IDLE. The IMAP connection freezes after some time and the re-poll failed after 28 min. It looks like there is a ssl socket timeout before a IMAP IDLE re-poll is issued. ----- Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP> A0005 IDLE Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP< + OK Jan 3 20:59:35 mini2 fetchmail[14842]: IMAP> DONE Jan 3 20:59:35 mini2 fetchmail[14842]: re-poll failed Jan 3 20:59:35 mini2 fetchmail[14842]: socket error while fetching from web...@fi...@imap.strato.de Jan 3 20:59:35 mini2 fetchmail[14842]: 6.3.24 querying imap.strato.de (protocol IMAP) at Thu, 03 Jan 2013 20:59:35 +0100 (CET): poll completed Jan 3 20:59:35 mini2 fetchmail[14842]: Query status=2 (SOCKET) ----- The re-poll does not fail, when the idle timeout is reduced from 28 min to 10 minutes. This should also fulfil the RFC 2177, because the RFC suggests to re-issue a IDLE command at LEAST every 29 minutes. RFC 2177 "The server MAY consider a client inactive if it has an IDLE command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLE are advised to terminate the IDLE and re-issue it at least every 29 minutes to avoid being logged off. This still allows a client to receive immediate mailbox updates even though it need only "poll" at half hour intervals." Other IMAP Clients uses a shorter IDLE re-poll timer or issues a NOOP Command. Microsoft Outlook: 10 min Apple Mail: IMAP NOOP every 1 minute (RFC 3501: "The NOOP command can also be used to reset any inactivity autologout timer on the server.") ------ Patch (Reduce idle_timeout to 600) diff fetchmail-6.3.24-patched/imap.c fetchmail-6.3.24/imap.c 718,719c718 < /* mytimeout = idle_timeout = 1680; */ /* 28 min */ < mytimeout = idle_timeout = 600; /* reduce to 10 min to prevent ssl socket timeout */ --- > mytimeout = idle_timeout = 1680; /* 28 min */ Enviroment: fetchmail 6.3.24 OS: Mac OS 10.7.5 IMAP Server: Provider Strato (imap.strato.de) --- Best regards, Wolfgang Follow-Ups: Date: 2013-Jan-06 13:20 By: m-a Comment: Thanks for the detailed information. However, this pretty much looks like a networking issue. The server just hung up, but there was no FIN|ACK handshake from closing down the connection, so fetchmail was not informed of the shutdown or close until it tried to send the next packet. This pretty much looks like a networking issue, broken router or NAT or Masquerading. I'll grant that TCP keepalives might help. Unfortunately, strato does not appear to support STARTTLS, so we cannot test that. ------------------------------------------------------- Date: 2013-Jan-05 19:50 By: w-f Comment: The issue is not an server imap timeout. There are no problems when using an unencrypted imap session. The dtruss shows no activity during the idle time: 22867/0xaf6c4: 629137 33 24 write(0x5, "\027\003\0", 0x25) = 37 0 22867/0xaf6c4: 629147 9 3 __sysctl(0x7FFF60CF8FE8, 0x2, 0x7FFF60CF8FFF) = 0 0 22867/0xaf6c4: 629150 5 0 getuid(0x0, 0x7FFF60CF8C58, 0x0) = 273 0 22867/0xaf6c4: 629152 5 0 getgid(0x0, 0x7FFF60CF8C58, 0x0) = 1 0 22867/0xaf6c4: 629184 9 3 setitimer(0x0, 0x7FFF60CF7E00, 0x0) = 0 0 dtrace: error on enabled probe ID 1791 (ID 778: syscall::read:return): out of scratch space in action #13 at DIF offset 44 dtrace: error on enabled probe ID 1791 (ID 778: syscall::read:return): out of scratch space in action #13 at DIF offset 44 dtrace: error on enabled probe ID 1789 (ID 780: syscall::write:return): out of scratch space in action #13 at DIF offset 44 22867/0xaf6c4: 629354 343 20 sigreturn(0x7FFF60CF7B50, 0x1E, 0x7FFF60CF7B50) = 0 Err#-2 22867/0xaf6c4: 629358 8 0 __pthread_canceled(0x0, 0x7FE06C015000, 0x7FFF60CF7C08) = -1 Err#22 22867/0xaf6c4: 629372 8 1 setitimer(0x0, 0x7FFF60CF7E00, 0x0) = 0 0 22867/0xaf6c4: 629454 66 58 write(0x5, "\027\003\0", 0x1F) = 31 0 22867/0xaf6c4: 629481 15 8 __sysctl(0x7FFF60CFB0F8, 0x2, 0x7FFF60CFB10F) = 0 0 22867/0xaf6c4: 629485 6 0 getuid(0x0, 0x7FFF60CFAD68, 0x0) = 273 0 22867/0xaf6c4: 629487 6 0 getgid(0x0, 0x7FFF60CFAD68, 0x0) = 1 0 22867/0xaf6c4: 629533 10 4 setitimer(0x0, 0x7FFF60CF9F30, 0x0) = 0 0 22867/0xaf6c4: 629566 13 1 setitimer(0x0, 0x7FFF60CF9F30, 0x0) = 0 0 22867/0xaf6c4: 629569 5 0 setitimer(0x0, 0x7FFF60CFBFD0, 0x0) = 0 0 22867/0xaf6c4: 629596 14 7 __sysctl(0x7FFF60CFB118, 0x2, 0x7FFF60CFB12F) = 0 0 22867/0xaf6c4: 629600 5 0 getuid(0x0, 0x7FFF60CFAD88, 0x0) = 273 0 22867/0xaf6c4: 629602 5 0 getgid(0x0, 0x7FFF60CFAD88, 0x0) = 1 0 22867/0xaf6c4: 629648 10 2 sigaction(0xE, 0x7FFF60D00098, 0x7FFF60D000C0) = 0 0 22867/0xaf6c4: 629653 8 2 setitimer(0x0, 0x7FFF60D00278, 0x0) = 0 0 22867/0xaf6c4: 629849 18 9 close(0x5) = 0 0 22867/0xaf6c4: 629852 6 1 setitimer(0x0, 0x7FFF60D00298, 0x0) = 0 0 22867/0xaf6c4: 629854 6 0 sigaction(0xE, 0x7FFF60D00098, 0x7FFF60D000C0) = 0 0 22867/0xaf6c4: 629867 9 3 __sysctl(0x7FFF60CFF1E8, 0x2, 0x7FFF60CFF1FF) = 0 0 Also there is no network traffic during the idle time. And the response for first packet TCP Push from fetchmail to the imap server is a Reset. tcp dump IMAPS Session: ------ 18:42:48.547781 IP (tos 0x0, ttl 64, id 25398, offset 0, flags [DF], proto TCP (6), length 77) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [P.], cksum 0x4c5f (incorrect -> 0x2baf), seq 743:780, ack 4504, win 33396, length 37 18:42:48.568631 IP (tos 0x0, ttl 248, id 36786, offset 0, flags [DF], proto TCP (6), length 71) imap.strato.de.imaps > mini2.home.fischer-net.net.60975: Flags [P.], cksum 0x5a30 (correct), seq 4504:4535, ack 780, win 5135, length 31 18:42:48.568693 IP (tos 0x0, ttl 64, id 64318, offset 0, flags [DF], proto TCP (6), length 40) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [.], cksum 0x4c3a (incorrect -> 0xd50a), seq 780, ack 4535, win 33380, length 0 19:10:48.624932 IP (tos 0x0, ttl 64, id 12889, offset 0, flags [DF], proto TCP (6), length 71) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [P.], cksum 0x4c59 (incorrect -> 0xfd06), seq 780:811, ack 4535, win 33396, length 31 19:10:48.646571 IP (tos 0x0, ttl 248, id 18517, offset 0, flags [DF], proto TCP (6), length 40) imap.strato.de.imaps > mini2.home.fischer-net.net.60975: Flags [R.], cksum 0x574c (correct), seq 4535, ack 811, win 0, length 0 19:11:49.041641 IP (tos 0x0, ttl 64, id 1235, offset 0, flags [DF], proto TCP (6), length 64) mini2.home.fischer-net.net.61035 > imap.strato.de.imaps: Flags [S], cksum 0x4c52 (incorrect -> 0x0b3e), seq 771336041, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 1029692052 ecr 0,sackOK,eol], length 0 19:11:49.063272 IP (tos 0x0, ttl 248, id 26043, offset 0, flags [DF], proto TCP (6), length 52) imap.strato.de.imaps > mini2.home.fischer-net.net.61035: Flags [S.], cksum 0x1718 (correct), seq 2700448559, ack 771336042, win 4356, options [mss 1452,nop,wscale 0,sackOK,eol], length 0 ----- Now for me looks like the issue is, fetchmail opens the Socket for the SSL Session without a TCP KeepAlive. When I use an unencrypted imap session, the TCP KeepAlive is active. The tcpdump shows the TCP KeepAlive packets during the imap idle time. Best Regards, Wolfgang ------------------------------------------------------- Date: 2013-Jan-03 23:02 By: m-a Comment: Have Strato fix their server timeouts instead, the 30 minute timer is a "MUST" clause in RFC-3501 section 5.4, see http://tools.ietf.org/html/rfc3501#section-5.4 If there is a socket timeout, I'd like to see an strace or truss trace proving it, and possibly an accompanying tcpdump or wireshark/tshark dump of the protocol with timestamps, to see when the connection gets closed. Chances are that there is a problem on your end - are you using IPv4 NAT or Masquerading? ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18853&group_id=1824 |
|
From: <ad...@be...> - 2013-01-05 19:50:09
|
Bug #18853, was updated on 2013-Jan-03 22:49 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 3 Submitted by: w-f Assigned to : none Summary: IMAP IDLE + SSL: Error: re-poll failed Details: I use fetchmail with SSL and IMAP IDLE. The IMAP connection freezes after some time and the re-poll failed after 28 min. It looks like there is a ssl socket timeout before a IMAP IDLE re-poll is issued. ----- Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP> A0005 IDLE Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP< + OK Jan 3 20:59:35 mini2 fetchmail[14842]: IMAP> DONE Jan 3 20:59:35 mini2 fetchmail[14842]: re-poll failed Jan 3 20:59:35 mini2 fetchmail[14842]: socket error while fetching from web...@fi...@imap.strato.de Jan 3 20:59:35 mini2 fetchmail[14842]: 6.3.24 querying imap.strato.de (protocol IMAP) at Thu, 03 Jan 2013 20:59:35 +0100 (CET): poll completed Jan 3 20:59:35 mini2 fetchmail[14842]: Query status=2 (SOCKET) ----- The re-poll does not fail, when the idle timeout is reduced from 28 min to 10 minutes. This should also fulfil the RFC 2177, because the RFC suggests to re-issue a IDLE command at LEAST every 29 minutes. RFC 2177 "The server MAY consider a client inactive if it has an IDLE command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLE are advised to terminate the IDLE and re-issue it at least every 29 minutes to avoid being logged off. This still allows a client to receive immediate mailbox updates even though it need only "poll" at half hour intervals." Other IMAP Clients uses a shorter IDLE re-poll timer or issues a NOOP Command. Microsoft Outlook: 10 min Apple Mail: IMAP NOOP every 1 minute (RFC 3501: "The NOOP command can also be used to reset any inactivity autologout timer on the server.") ------ Patch (Reduce idle_timeout to 600) diff fetchmail-6.3.24-patched/imap.c fetchmail-6.3.24/imap.c 718,719c718 < /* mytimeout = idle_timeout = 1680; */ /* 28 min */ < mytimeout = idle_timeout = 600; /* reduce to 10 min to prevent ssl socket timeout */ --- > mytimeout = idle_timeout = 1680; /* 28 min */ Enviroment: fetchmail 6.3.24 OS: Mac OS 10.7.5 IMAP Server: Provider Strato (imap.strato.de) --- Best regards, Wolfgang Follow-Ups: Date: 2013-Jan-05 19:50 By: w-f Comment: The issue is not an server imap timeout. There are no problems when using an unencrypted imap session. The dtruss shows no activity during the idle time: 22867/0xaf6c4: 629137 33 24 write(0x5, "\027\003\0", 0x25) = 37 0 22867/0xaf6c4: 629147 9 3 __sysctl(0x7FFF60CF8FE8, 0x2, 0x7FFF60CF8FFF) = 0 0 22867/0xaf6c4: 629150 5 0 getuid(0x0, 0x7FFF60CF8C58, 0x0) = 273 0 22867/0xaf6c4: 629152 5 0 getgid(0x0, 0x7FFF60CF8C58, 0x0) = 1 0 22867/0xaf6c4: 629184 9 3 setitimer(0x0, 0x7FFF60CF7E00, 0x0) = 0 0 dtrace: error on enabled probe ID 1791 (ID 778: syscall::read:return): out of scratch space in action #13 at DIF offset 44 dtrace: error on enabled probe ID 1791 (ID 778: syscall::read:return): out of scratch space in action #13 at DIF offset 44 dtrace: error on enabled probe ID 1789 (ID 780: syscall::write:return): out of scratch space in action #13 at DIF offset 44 22867/0xaf6c4: 629354 343 20 sigreturn(0x7FFF60CF7B50, 0x1E, 0x7FFF60CF7B50) = 0 Err#-2 22867/0xaf6c4: 629358 8 0 __pthread_canceled(0x0, 0x7FE06C015000, 0x7FFF60CF7C08) = -1 Err#22 22867/0xaf6c4: 629372 8 1 setitimer(0x0, 0x7FFF60CF7E00, 0x0) = 0 0 22867/0xaf6c4: 629454 66 58 write(0x5, "\027\003\0", 0x1F) = 31 0 22867/0xaf6c4: 629481 15 8 __sysctl(0x7FFF60CFB0F8, 0x2, 0x7FFF60CFB10F) = 0 0 22867/0xaf6c4: 629485 6 0 getuid(0x0, 0x7FFF60CFAD68, 0x0) = 273 0 22867/0xaf6c4: 629487 6 0 getgid(0x0, 0x7FFF60CFAD68, 0x0) = 1 0 22867/0xaf6c4: 629533 10 4 setitimer(0x0, 0x7FFF60CF9F30, 0x0) = 0 0 22867/0xaf6c4: 629566 13 1 setitimer(0x0, 0x7FFF60CF9F30, 0x0) = 0 0 22867/0xaf6c4: 629569 5 0 setitimer(0x0, 0x7FFF60CFBFD0, 0x0) = 0 0 22867/0xaf6c4: 629596 14 7 __sysctl(0x7FFF60CFB118, 0x2, 0x7FFF60CFB12F) = 0 0 22867/0xaf6c4: 629600 5 0 getuid(0x0, 0x7FFF60CFAD88, 0x0) = 273 0 22867/0xaf6c4: 629602 5 0 getgid(0x0, 0x7FFF60CFAD88, 0x0) = 1 0 22867/0xaf6c4: 629648 10 2 sigaction(0xE, 0x7FFF60D00098, 0x7FFF60D000C0) = 0 0 22867/0xaf6c4: 629653 8 2 setitimer(0x0, 0x7FFF60D00278, 0x0) = 0 0 22867/0xaf6c4: 629849 18 9 close(0x5) = 0 0 22867/0xaf6c4: 629852 6 1 setitimer(0x0, 0x7FFF60D00298, 0x0) = 0 0 22867/0xaf6c4: 629854 6 0 sigaction(0xE, 0x7FFF60D00098, 0x7FFF60D000C0) = 0 0 22867/0xaf6c4: 629867 9 3 __sysctl(0x7FFF60CFF1E8, 0x2, 0x7FFF60CFF1FF) = 0 0 Also there is no network traffic during the idle time. And the response for first packet TCP Push from fetchmail to the imap server is a Reset. tcp dump IMAPS Session: ------ 18:42:48.547781 IP (tos 0x0, ttl 64, id 25398, offset 0, flags [DF], proto TCP (6), length 77) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [P.], cksum 0x4c5f (incorrect -> 0x2baf), seq 743:780, ack 4504, win 33396, length 37 18:42:48.568631 IP (tos 0x0, ttl 248, id 36786, offset 0, flags [DF], proto TCP (6), length 71) imap.strato.de.imaps > mini2.home.fischer-net.net.60975: Flags [P.], cksum 0x5a30 (correct), seq 4504:4535, ack 780, win 5135, length 31 18:42:48.568693 IP (tos 0x0, ttl 64, id 64318, offset 0, flags [DF], proto TCP (6), length 40) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [.], cksum 0x4c3a (incorrect -> 0xd50a), seq 780, ack 4535, win 33380, length 0 19:10:48.624932 IP (tos 0x0, ttl 64, id 12889, offset 0, flags [DF], proto TCP (6), length 71) mini2.home.fischer-net.net.60975 > imap.strato.de.imaps: Flags [P.], cksum 0x4c59 (incorrect -> 0xfd06), seq 780:811, ack 4535, win 33396, length 31 19:10:48.646571 IP (tos 0x0, ttl 248, id 18517, offset 0, flags [DF], proto TCP (6), length 40) imap.strato.de.imaps > mini2.home.fischer-net.net.60975: Flags [R.], cksum 0x574c (correct), seq 4535, ack 811, win 0, length 0 19:11:49.041641 IP (tos 0x0, ttl 64, id 1235, offset 0, flags [DF], proto TCP (6), length 64) mini2.home.fischer-net.net.61035 > imap.strato.de.imaps: Flags [S], cksum 0x4c52 (incorrect -> 0x0b3e), seq 771336041, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 1029692052 ecr 0,sackOK,eol], length 0 19:11:49.063272 IP (tos 0x0, ttl 248, id 26043, offset 0, flags [DF], proto TCP (6), length 52) imap.strato.de.imaps > mini2.home.fischer-net.net.61035: Flags [S.], cksum 0x1718 (correct), seq 2700448559, ack 771336042, win 4356, options [mss 1452,nop,wscale 0,sackOK,eol], length 0 ----- Now for me looks like the issue is, fetchmail opens the Socket for the SSL Session without a TCP KeepAlive. When I use an unencrypted imap session, the TCP KeepAlive is active. The tcpdump shows the TCP KeepAlive packets during the imap idle time. Best Regards, Wolfgang ------------------------------------------------------- Date: 2013-Jan-03 23:02 By: m-a Comment: Have Strato fix their server timeouts instead, the 30 minute timer is a "MUST" clause in RFC-3501 section 5.4, see http://tools.ietf.org/html/rfc3501#section-5.4 If there is a socket timeout, I'd like to see an strace or truss trace proving it, and possibly an accompanying tcpdump or wireshark/tshark dump of the protocol with timestamps, to see when the connection gets closed. Chances are that there is a problem on your end - are you using IPv4 NAT or Masquerading? ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18853&group_id=1824 |
|
From: <ad...@be...> - 2013-01-03 23:02:37
|
Bug #18853, was updated on 2013-Jan-03 22:49 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 3 Submitted by: w-f Assigned to : none Summary: IMAP IDLE + SSL: Error: re-poll failed Details: I use fetchmail with SSL and IMAP IDLE. The IMAP connection freezes after some time and the re-poll failed after 28 min. It looks like there is a ssl socket timeout before a IMAP IDLE re-poll is issued. ----- Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP> A0005 IDLE Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP< + OK Jan 3 20:59:35 mini2 fetchmail[14842]: IMAP> DONE Jan 3 20:59:35 mini2 fetchmail[14842]: re-poll failed Jan 3 20:59:35 mini2 fetchmail[14842]: socket error while fetching from web...@fi...@imap.strato.de Jan 3 20:59:35 mini2 fetchmail[14842]: 6.3.24 querying imap.strato.de (protocol IMAP) at Thu, 03 Jan 2013 20:59:35 +0100 (CET): poll completed Jan 3 20:59:35 mini2 fetchmail[14842]: Query status=2 (SOCKET) ----- The re-poll does not fail, when the idle timeout is reduced from 28 min to 10 minutes. This should also fulfil the RFC 2177, because the RFC suggests to re-issue a IDLE command at LEAST every 29 minutes. RFC 2177 "The server MAY consider a client inactive if it has an IDLE command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLE are advised to terminate the IDLE and re-issue it at least every 29 minutes to avoid being logged off. This still allows a client to receive immediate mailbox updates even though it need only "poll" at half hour intervals." Other IMAP Clients uses a shorter IDLE re-poll timer or issues a NOOP Command. Microsoft Outlook: 10 min Apple Mail: IMAP NOOP every 1 minute (RFC 3501: "The NOOP command can also be used to reset any inactivity autologout timer on the server.") ------ Patch (Reduce idle_timeout to 600) diff fetchmail-6.3.24-patched/imap.c fetchmail-6.3.24/imap.c 718,719c718 < /* mytimeout = idle_timeout = 1680; */ /* 28 min */ < mytimeout = idle_timeout = 600; /* reduce to 10 min to prevent ssl socket timeout */ --- > mytimeout = idle_timeout = 1680; /* 28 min */ Enviroment: fetchmail 6.3.24 OS: Mac OS 10.7.5 IMAP Server: Provider Strato (imap.strato.de) --- Best regards, Wolfgang Follow-Ups: Date: 2013-Jan-03 23:02 By: m-a Comment: Have Strato fix their server timeouts instead, the 30 minute timer is a "MUST" clause in RFC-3501 section 5.4, see http://tools.ietf.org/html/rfc3501#section-5.4 If there is a socket timeout, I'd like to see an strace or truss trace proving it, and possibly an accompanying tcpdump or wireshark/tshark dump of the protocol with timestamps, to see when the connection gets closed. Chances are that there is a problem on your end - are you using IPv4 NAT or Masquerading? ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18853&group_id=1824 |
|
From: <ad...@be...> - 2013-01-03 22:49:48
|
Bug #18853, was updated on 2013-Jan-03 22:49 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: w-f Assigned to : none Summary: IMAP IDLE + SSL: Error: re-poll failed Details: I use fetchmail with SSL and IMAP IDLE. The IMAP connection freezes after some time and the re-poll failed after 28 min. It looks like there is a ssl socket timeout before a IMAP IDLE re-poll is issued. ----- Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP> A0005 IDLE Jan 3 20:31:35 mini2 fetchmail[14842]: IMAP< + OK Jan 3 20:59:35 mini2 fetchmail[14842]: IMAP> DONE Jan 3 20:59:35 mini2 fetchmail[14842]: re-poll failed Jan 3 20:59:35 mini2 fetchmail[14842]: socket error while fetching from web...@fi...@imap.strato.de Jan 3 20:59:35 mini2 fetchmail[14842]: 6.3.24 querying imap.strato.de (protocol IMAP) at Thu, 03 Jan 2013 20:59:35 +0100 (CET): poll completed Jan 3 20:59:35 mini2 fetchmail[14842]: Query status=2 (SOCKET) ----- The re-poll does not fail, when the idle timeout is reduced from 28 min to 10 minutes. This should also fulfil the RFC 2177, because the RFC suggests to re-issue a IDLE command at LEAST every 29 minutes. RFC 2177 "The server MAY consider a client inactive if it has an IDLE command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLE are advised to terminate the IDLE and re-issue it at least every 29 minutes to avoid being logged off. This still allows a client to receive immediate mailbox updates even though it need only "poll" at half hour intervals." Other IMAP Clients uses a shorter IDLE re-poll timer or issues a NOOP Command. Microsoft Outlook: 10 min Apple Mail: IMAP NOOP every 1 minute (RFC 3501: "The NOOP command can also be used to reset any inactivity autologout timer on the server.") ------ Patch (Reduce idle_timeout to 600) diff fetchmail-6.3.24-patched/imap.c fetchmail-6.3.24/imap.c 718,719c718 < /* mytimeout = idle_timeout = 1680; */ /* 28 min */ < mytimeout = idle_timeout = 600; /* reduce to 10 min to prevent ssl socket timeout */ --- > mytimeout = idle_timeout = 1680; /* 28 min */ Enviroment: fetchmail 6.3.24 OS: Mac OS 10.7.5 IMAP Server: Provider Strato (imap.strato.de) --- Best regards, Wolfgang For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18853&group_id=1824 |
|
From: Matthias A. <mat...@gm...> - 2013-01-03 00:56:10
|
Greetings, in an effort to get sufficient testing, I have released the next alpha version of fetchmail 7.0.0. This merges post-6.3.22 changes in, to fix some regressions and plug the OpenSSL memory leak that prompted the 6.3.24 release. The changelog is included below. Note that I plan to discontinue MAPI support, it has zero user interest. I have not received offers of Exchange test accounts, I have not received test reports from users, and I can only conclude that while it may have looked a good idea when the Google Summer Of Code project to add MAPI support was started, this is a stillborn. I will spend no more efforts in providing MAPI support in fetchmail unless there are sustainable offers to help out with test accounts, test reports, and so on. The alpha version is available for download from these sites: <http://home.pages.de/~mandree/fetchmail/> <https://sourceforge.net/projects/fetchmail/files/branch_7-alpha/> It is not available for download from BerliOS, its file release system is too cumbersome to use. The fetchmail sources are also available via Git. The corresponding git tag is SNAPSHOT_7-0-0-alpha4, the branch is "master". The repository browsers (these show the clone URLs): <http://gitorious.org/fetchmail> <http://git.berlios.de/cgi-bin/cgit.cgi/fetchmail/> <http://git.berlios.de/cgi-bin/gitweb.cgi?p=fetchmail;a=summary> Please send feedback to fet...@li.... Happy fetches! Matthias -------------------------------------------------------------------------------- fetchmail-7.0.0 (not yet released): NOTE THIS IS AN ALPHA RELEASE THAT HAS NOT BEEN THOROUGHLY TESTED! # MAJOR CHANGES * The UIDL handler code is now much faster, especially noticable with lots of mail kept on a POP3 server. Where the 6.3.X code was of O(n^2) complexity, we're down to O(n log n). Contributed by Rainer Weikusat, MAD Partners Ltd./MSS GmbH. * The POP3 code now always uses UIDL, except if "fetchall" is in effect. Fixes BerliOS Bug #16172. Fixes Debian Bug#345788. * Fetchmail now enables SSL support by default. If this is undesired, ./configure --without-ssl should help. * The OpenSSL code now excludes the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option. This can cause interoperability problems with certain buggy servers, but is required to defang chosen-plaintext attacks against AES. While probably hard to mount against fetchmail, let's play it safe rather than be sorry later. # FEATURES ADDED * Fetchmail can now retrieve credentials from PWMD. This needs to be enabled at compile-time and requires run-time configuration. See README.PWMD for details. Contributed by Ben Kibbey, author of libpwmd and pwmd. * Fetchmail now supports a retrieve-error command line or rcfile option that takes exactly one argument, abort (default), continue or markseen. This specifies the policy used by fetchmail to handle messages whose bodies fail to be retrieved due to server errors. Both the continue and markseen options will skip the message with errors and allow the session to continue so that subsequent messages can be retrieved. The markseen option will also mark the message with errors as seen. The default policy is to abort the session whenever a server error occurs. Contributed by Craig Brown. * Fetchmailconf offers cram-md5 and apop authentication. # REMOVED FEATURES * IMAP2 protocol support was removed. * POP2 protocol support was removed. * RPOP (not actually a protocol, but a variant of POP3) was removed * POP3: the uidl option has been removed. It is always on. * POP3: LAST is no longer used. It was removed from POP3 in 1994, and it could cause mail loss when the connection was interrupted or if clients besides fetchmail polled the mailbox. * Trio was removed, fetchmail expects reasonable stdio.h quality levels. * Support for systems that do not conform to C89 and POSIX 2001 was removed, this means that BeOS, EMX, NeXTSTEP quirks are no longer worked around. * The MX and host alias DNS lookups that fetchmail performs in multidrop mode have been removed. They were based on the mistaken assumption that the IMAP/POP3 server was also the MX server, which is rarely the case. They have never supported IPv6 (including IPv6-mapped IPv4) either. Non-DNS based alias keywords such as "aka" remain. * Kerberos IV support was removed. * fetchmail no longer supports SSL v2, nor the corresponding SSL2 option to --sslproto. SSLv2 is insecure and had been deprecated 15 years ago. fetchmail will actively forbid SSLv2 negotiation by means of SSL_OP_NO_SSLv2. To fix Debian Bug#622054. * A lot of outdated and/or unsafe-to-use material got dropped from contrib/. # REGRESSION FIXES * The mimedecode feature now properly detects multipart/mixed-type matches, so that quoted-printable-encoded multipart messages can get decoded. (Regression in 5.0.0 on 1999-03-27, as a side effect of a PGP-mimedecode fix attributed to Henrik Storner.) # BUG FIXES * The mimedecode feature failed to ship the last line of the body if it was encoded as quoted-printable and had a MIME soft line break in the very last line. Reported by Lars Hecking in June 2011. Bug introduced on 1998-03-20 when the mimedecode support was added by ESR before release 4.4.1 through code contributed by Henrik Storner. Workaround for older releases: do not use mimedecode feature. * Fetchmail now detects singly-quoted % expansions in the mda option and refuses to deliver for safety reasons. Fixes Debian Bug#347909. * The Server certificate: message in verbose mode now appears on stdout like the remainder of the output. Reported by Henry Jensen, to fix Debian Bug #639807. # CHANGES * A foreground fetchmail can now accept a few more options while another copy is running in the background. * APOP is no longer a protocol, but an authentication method. In order to use it, use protocol POP3 auth APOP, or on the commandline, -p pop3 --auth apop. If no authentication method is specified, APOP is automatically tried if offered by the server before we resort to sending the password as clear text. # KNOWN BUGS AND WORKAROUNDS (This section floats upwards through the NEWS file so it stays with the current release information) * Fetchmail does not handle messages without Message-ID header well (See sourceforge.net bug #780933) * BSMTP is mostly untested and errors can cause corrupt output. * Sun Workshop 6 (SPARC) is known to miscompile the configuration file lexer in 64-bit mode. Either compile 32-bit code or use GCC to compile 64-bit fetchmail. Note that fetchmail doesn't take advantage of 64-bit code, so compiling 32-bit SPARC code should not cause any difficulties. * Fetchmail does not track pending deletes across crashes. * The command line interface is sometimes a bit stubborn, for instance, fetchmail -s doesn't work with a daemon running. * Linux systems may return duplicates of an IP address in some circumstances if no or no global IPv6 addresses are configured. (No workaround. Ubuntu Bug#582585, Novell Bug#606980.) * Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error messages. This will not be fixed, because the maintainer has no Kerberos 5 server to test against. Use GSSAPI. -------------------------------------------------------------------------------- fetchmail-6.3.24 (released 2012-12-23, 26108 LoC): # NOTE THAT THE RELEASE OF FUTURE FETCHMAIL 6.3.X VERSIONS IS UNCLEAR. Should a 7.0 release be made earlier, chances are that the 6.3.X branch is abandoned and its changes be folded into the 7.0 release, with changes after 6.3.24 not available on their own in a newer 6.3.X release. # NOTE THAT FETCHMAIL IS NO LONGER PUBLISHED THROUGH IBIBLIO. They have stopped accepting submissions and consider themselves an archive. # CRITICAL AND REGRESSION FIXES * Plug a memory leak in OpenSSL's certificate verification callback. This would affect fetchmail configurations running with SSL in daemon mode more than one-shot runs. Reported by Erik Thiele, and pinned by Dominik Heeg, fixes Debian Bug #688015. This bug was introduced into fetchmail 6.3.0 (committed 2005-10-29) when support for subjectAltName was added through a patch by Roland Stigge, submitted as Debian Bug#201113. * The --logfile option now works again outside daemon mode, reported by Heinz Diehl. The documentation that I had been reading was inconsistent with the code, and only parts of the manual page claimed that --logfile was only effective in daemon mode. # KNOWN BUGS AND WORKAROUNDS (This section floats upwards through the NEWS file so it stays with the current release information) * Fetchmail does not handle messages without Message-ID header well (See sourceforge.net bug #780933) * BSMTP is mostly untested and errors can cause corrupt output. * Sun Workshop 6 (SPARC) is known to miscompile the configuration file lexer in 64-bit mode. Either compile 32-bit code or use GCC to compile 64-bit fetchmail. Note that fetchmail doesn't take advantage of 64-bit code, so compiling 32-bit SPARC code should not cause any difficulties. * Fetchmail does not track pending deletes across crashes. * The command line interface is sometimes a bit stubborn, for instance, fetchmail -s doesn't work with a daemon running. * Linux systems may return duplicates of an IP address in some circumstances if no or no global IPv6 addresses are configured. (No workaround. Ubuntu Bug#582585, Novell Bug#606980.) * Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error messages. This will not be fixed, because the maintainer has no Kerberos 5 server to test against. Use GSSAPI. fetchmail-6.3.23 (released 2012-12-10, 26106 LoC): # REGRESSION FIXES * Fix compilation with OpenSSL implementations before 0.9.8m that lack SSL_CTX_clear_options. Patch by Earl Chew. Note that the use of older OpenSSL versions with fetchmail is unsupported and *not* recommended. # BUG FIXES * Fix combination of --plugin and -f -. Patch by Alexander Zangerl, to fix Debian Bug#671294. * Clean up logfile vs. syslog handling, and in case logfile overrides syslog, send a message to the latter stating where logging goes. # CHANGES * The build process can now be made a bit more silent and concise through ./configure --enable-silent-rules, or by adding "V=0" to the make command. # WORKAROUNDS * Make Maillennium POP3 workarounds less specific, to encompass Maillennium POP3/UNIBOX (Maillennium V05.00c++). Reported by Eddie via fetchmail-users mailing list, 2012-10-13. # TRANSLATION UPDATES [cs] Czech, by Petr Pisar [da] Danish, by Joe Hansen [de] German [fr] French, Frédéric Marchal [ja] Japanese, Takeshi Hamasaki [pl] Polish, by Jakub Bogusz [sv] Swedish, by Göran Uddeborg [vi] Vietnamese, Trần Ngọc Quân -------------------------------------------------------------------------------- |
|
From: Translation P. R. <ro...@tr...> - 2012-12-10 23:07:15
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/da.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2012-12-09 23:17:12
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/da.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2012-12-08 01:12:21
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the Vietnamese team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/vi.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2012-12-06 23:27:33
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/sv.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2012-12-06 21:12:05
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the Czech team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/cs.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2012-12-06 16:57:04
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the Polish team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/pl.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2012-12-06 16:02:04
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the Japanese team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/ja.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2012-12-06 14:07:06
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the French team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/fr.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: Translation P. R. <ro...@tr...> - 2012-12-06 08:19:13
|
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to <coo...@tr...>.)
A new POT file for textual domain 'fetchmail' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/fetchmail-6.3.22.2.pot
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
Below is the URL which has been provided to the translators of your
package. Please inform the translation coordinator, at the address
at the bottom, if this information is not current:
http://home.pages.de/~mandree/fetchmail/fetchmail-6.3.22.2.tar.bz2
We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive. Ask at the address below if you want this.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
|
From: <ad...@be...> - 2012-11-29 08:48:33
|
Bug #18794, was updated on 2012-Nov-14 11:12 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Closed Resolution: Invalid Bug Group: None Priority: 5 Submitted by: madman1234 Assigned to : m-a Summary: BUG in libdispatch client - OSX ML 10.8.2 Details: I installed fetchmail using mac ports. But everytime I start fetchmail (SSL included), I receive the following message in /var/log/mail.log [...] BUG in libdispatch client: Do not close random Unix descriptors [...] I have compiled the latest fetchmail version by myself, but I receive the same message. Fetchmail itself works, but what does it means? If I should ran any debugs, just let me know :) Thanks Soeren Follow-Ups: Date: 2012-Nov-29 08:48 By: m-a Comment: I am closing this bug report, as it turns out, ./configure --disable-nls avoids the pollution of fetchmail with GCD on (Mac)OS X, per http://trac.macports.org/ticket/36984#comment:12 - should there be evidence that something fetchmail does with libintl cause this, please reopen this ticket; otherwise I will assume that libintl/gettext on MacOS X have to be fixed, rather than fetchmail. ------------------------------------------------------- Date: 2012-Nov-22 00:19 By: m-a Comment: I will keep the libintl issue out of this bug, it is separate and unrelated, and possibly an issue with LD_LIBRARY_PATH lacking a pointer to the /opt... directory that contains libintl. Now, I am unfamiliar with Apple MacOS X specialties, do not have access to a sufficiently new MacOS X system, and I do not care for them, so I need your help: 1. is there a way to avoid libdispatch being linked in and/or its manager started automatically? What triggers it? I don't need nor want it. 2. is there any documentation on what special file descriptors need to be kept open, and how I can identify them? Why does libc need to open special file descriptors at all? 3. what triggers libdispatch to open file descriptors I did not ask for? Note that closing file descriptors that fetchmail has not opened and are non-standard (a) is a security feature (against exploitation), (b) is required in several situations in order to actually let fetchmail detach into the background. I am very much inclined to declare this an operating system bug that the OS injects a file descriptor into my application, and especially that it crashes when I try to close it -- the POSIX standard mandates that close() return -1 after setting errno = EBADF, and does not specify that aborting the program were in order. It will only occur in daemon mode, so running fetchmail from cron, and setting -d0 on the command line will avoid the problem. Note: This does not happen on Linux, NetBSD, FreeBSD, or Cygwin, and none of the web pages I found describing your bug contain any solution, other than potential file system corruption, for instance: https://bugs.freedesktop.org/show_bug.cgi?id=56286#c2 ------------------------------------------------------- Date: 2012-Nov-19 22:58 By: madman1234 Comment: I found this on my Diagnostic Log: Process: fetchmail [8149] Path: /Users/USER/fetchmail Identifier: fetchmail Version: 0 Code Type: X86-64 (Native) Parent Process: bash [1175] User ID: 501 Date/Time: 2012-11-16 21:08:14.727 +0100 OS Version: Mac OS X 10.8.2 (12C60) Report Version: 10 Crashed Thread: 0 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Application Specific Information: dyld: launch, loading dependent libraries Dyld Error Message: Library not loaded: /opt/local/lib/libintl.8.dylib Referenced from: /Users/USER/*/fetchmail Reason: image not found Binary Images: 0x10bebe000 - 0x10bef6fef +fetchmail (0) <EB15E071-F57F-36BA-9B82-B3D1E6F14A9C> /Users/USER/fetchmail 0x7fff6babe000 - 0x7fff6baf293f dyld (210.2.3) <A40597AA-5529-3337-8C09-D8A014EB1578> /usr/lib/dyld ------------------------------------------------------- Date: 2012-Nov-19 11:58 By: madman1234 Comment: 1. What is libdispatch? Libdispatch is part of the OS. It's linked into virtually every program, as you can see from: {{{ otool -L /usr/lib/libc.dylib }}} 2. Why is fetchmail on macports linking to it? It is done by default from OSX. Macports is here not involved. 3. Why does libdispatch require an application to keep random file descriptors open? I don't know. 4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream? It is not macports specific, it seems to be a standard behavior by default (OSX) Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment. The error message appears only once, after fetchmail tries to fetch mail via POP3 SSL. If there is no POP3 Server configured, then there is no error message on startup. Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it. I have compiled fetchmail by myself, wihtout macports, and the same issue occurs. Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck. I don't want to use getmail. Fetchmail is verfy stable and I like it a lot. 5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem. With -d 0 there is no error message. I am running fetchmail now on my OSX 10.8.2 Server. The error message appears when fetchmail starts, the program itself runs for 2 days now. All E-Mails are delivered correctly. ------------------------------------------------------- Date: 2012-Nov-15 08:08 By: m-a Comment: Some questions and notes: 1. What is libdispatch? 2. Why is fetchmail on macports linking to it? 3. Why does libdispatch require an application to keep random file descriptors open? 4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream? Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment. Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it. Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck. 5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem. Please report back with answers to these four questions, and possibly with macports statements to the notes. ------------------------------------------------------- Date: 2012-Nov-14 11:27 By: madman1234 Comment: Here is the answer from macports: [...] http://trac.macports.org/ticket/36984#comment:3 This message is printed by libdispatch (and is thus Apple-specific). Apparently fetchmail closes file descriptors that are used by libdispatch, which terminates the process using this message when this happens. I guess one would have to attach a debugger, see where the file descriptor is closed and see whether this actually is a "random" file descriptor and what can be done about it. The maintainer might also consider forwarding this to upstream fetchmail. [...] Do you have such a debug script? Thanks ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18794&group_id=1824 |
|
From: <ad...@be...> - 2012-11-22 00:19:54
|
Bug #18794, was updated on 2012-Nov-14 11:12 Here is a current snapshot of the bug. Project: fetchmail Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: madman1234 Assigned to : m-a Summary: BUG in libdispatch client - OSX ML 10.8.2 Details: I installed fetchmail using mac ports. But everytime I start fetchmail (SSL included), I receive the following message in /var/log/mail.log [...] BUG in libdispatch client: Do not close random Unix descriptors [...] I have compiled the latest fetchmail version by myself, but I receive the same message. Fetchmail itself works, but what does it means? If I should ran any debugs, just let me know :) Thanks Soeren Follow-Ups: Date: 2012-Nov-22 00:19 By: m-a Comment: I will keep the libintl issue out of this bug, it is separate and unrelated, and possibly an issue with LD_LIBRARY_PATH lacking a pointer to the /opt... directory that contains libintl. Now, I am unfamiliar with Apple MacOS X specialties, do not have access to a sufficiently new MacOS X system, and I do not care for them, so I need your help: 1. is there a way to avoid libdispatch being linked in and/or its manager started automatically? What triggers it? I don't need nor want it. 2. is there any documentation on what special file descriptors need to be kept open, and how I can identify them? Why does libc need to open special file descriptors at all? 3. what triggers libdispatch to open file descriptors I did not ask for? Note that closing file descriptors that fetchmail has not opened and are non-standard (a) is a security feature (against exploitation), (b) is required in several situations in order to actually let fetchmail detach into the background. I am very much inclined to declare this an operating system bug that the OS injects a file descriptor into my application, and especially that it crashes when I try to close it -- the POSIX standard mandates that close() return -1 after setting errno = EBADF, and does not specify that aborting the program were in order. It will only occur in daemon mode, so running fetchmail from cron, and setting -d0 on the command line will avoid the problem. Note: This does not happen on Linux, NetBSD, FreeBSD, or Cygwin, and none of the web pages I found describing your bug contain any solution, other than potential file system corruption, for instance: https://bugs.freedesktop.org/show_bug.cgi?id=56286#c2 ------------------------------------------------------- Date: 2012-Nov-19 22:58 By: madman1234 Comment: I found this on my Diagnostic Log: Process: fetchmail [8149] Path: /Users/USER/fetchmail Identifier: fetchmail Version: 0 Code Type: X86-64 (Native) Parent Process: bash [1175] User ID: 501 Date/Time: 2012-11-16 21:08:14.727 +0100 OS Version: Mac OS X 10.8.2 (12C60) Report Version: 10 Crashed Thread: 0 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Application Specific Information: dyld: launch, loading dependent libraries Dyld Error Message: Library not loaded: /opt/local/lib/libintl.8.dylib Referenced from: /Users/USER/*/fetchmail Reason: image not found Binary Images: 0x10bebe000 - 0x10bef6fef +fetchmail (0) <EB15E071-F57F-36BA-9B82-B3D1E6F14A9C> /Users/USER/fetchmail 0x7fff6babe000 - 0x7fff6baf293f dyld (210.2.3) <A40597AA-5529-3337-8C09-D8A014EB1578> /usr/lib/dyld ------------------------------------------------------- Date: 2012-Nov-19 11:58 By: madman1234 Comment: 1. What is libdispatch? Libdispatch is part of the OS. It's linked into virtually every program, as you can see from: {{{ otool -L /usr/lib/libc.dylib }}} 2. Why is fetchmail on macports linking to it? It is done by default from OSX. Macports is here not involved. 3. Why does libdispatch require an application to keep random file descriptors open? I don't know. 4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream? It is not macports specific, it seems to be a standard behavior by default (OSX) Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment. The error message appears only once, after fetchmail tries to fetch mail via POP3 SSL. If there is no POP3 Server configured, then there is no error message on startup. Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it. I have compiled fetchmail by myself, wihtout macports, and the same issue occurs. Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck. I don't want to use getmail. Fetchmail is verfy stable and I like it a lot. 5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem. With -d 0 there is no error message. I am running fetchmail now on my OSX 10.8.2 Server. The error message appears when fetchmail starts, the program itself runs for 2 days now. All E-Mails are delivered correctly. ------------------------------------------------------- Date: 2012-Nov-15 08:08 By: m-a Comment: Some questions and notes: 1. What is libdispatch? 2. Why is fetchmail on macports linking to it? 3. Why does libdispatch require an application to keep random file descriptors open? 4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream? Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment. Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it. Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck. 5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem. Please report back with answers to these four questions, and possibly with macports statements to the notes. ------------------------------------------------------- Date: 2012-Nov-14 11:27 By: madman1234 Comment: Here is the answer from macports: [...] http://trac.macports.org/ticket/36984#comment:3 This message is printed by libdispatch (and is thus Apple-specific). Apparently fetchmail closes file descriptors that are used by libdispatch, which terminates the process using this message when this happens. I guess one would have to attach a debugger, see where the file descriptor is closed and see whether this actually is a "random" file descriptor and what can be done about it. The maintainer might also consider forwarding this to upstream fetchmail. [...] Do you have such a debug script? Thanks ------------------------------------------------------- For detailed info, follow this link: http://developer.berlios.de/bugs/?func=detailbug&bug_id=18794&group_id=1824 |
|
From: <ad...@be...> - 2012-11-19 22:58:47
|
Bug #18794, was updated on 2012-Nov-14 01:12
Here is a current snapshot of the bug.
Project: fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: madman1234
Assigned to : m-a
Summary: BUG in libdispatch client - OSX ML 10.8.2
Details: I installed fetchmail using mac ports. But everytime I start fetchmail (SSL included), I receive the following message in /var/log/mail.log
[...]
BUG in libdispatch client: Do not close random Unix descriptors
[...]
I have compiled the latest fetchmail version by myself, but I receive the same message.
Fetchmail itself works, but what does it means?
If I should ran any debugs, just let me know :)
Thanks
Soeren
Follow-Ups:
Date: 2012-Nov-19 12:58
By: madman1234
Comment:
I found this on my Diagnostic Log:
Process: fetchmail [8149]
Path: /Users/USER/fetchmail
Identifier: fetchmail
Version: 0
Code Type: X86-64 (Native)
Parent Process: bash [1175]
User ID: 501
Date/Time: 2012-11-16 21:08:14.727 +0100
OS Version: Mac OS X 10.8.2 (12C60)
Report Version: 10
Crashed Thread: 0
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Application Specific Information:
dyld: launch, loading dependent libraries
Dyld Error Message:
Library not loaded: /opt/local/lib/libintl.8.dylib
Referenced from: /Users/USER/*/fetchmail
Reason: image not found
Binary Images:
0x10bebe000 - 0x10bef6fef +fetchmail (0) <EB15E071-F57F-36BA-9B82-B3D1E6F14A9C> /Users/USER/fetchmail
0x7fff6babe000 - 0x7fff6baf293f dyld (210.2.3) <A40597AA-5529-3337-8C09-D8A014EB1578> /usr/lib/dyld
-------------------------------------------------------
Date: 2012-Nov-19 01:58
By: madman1234
Comment:
1. What is libdispatch?
Libdispatch is part of the OS. It's linked into virtually every program,
as you can see from:
{{{
otool -L /usr/lib/libc.dylib
}}}
2. Why is fetchmail on macports linking to it?
It is done by default from OSX. Macports is here not involved.
3. Why does libdispatch require an application to keep random file descriptors open?
I don't know.
4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream?
It is not macports specific, it seems to be a standard behavior by default (OSX)
Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment.
The error message appears only once, after fetchmail tries to fetch mail via POP3 SSL. If there is no POP3 Server configured, then there is no error message on startup.
Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it.
I have compiled fetchmail by myself, wihtout macports, and the same issue occurs.
Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck.
I don't want to use getmail. Fetchmail is verfy stable and I like it a lot.
5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem.
With -d 0 there is no error message.
I am running fetchmail now on my OSX 10.8.2 Server. The error message appears when fetchmail starts, the program itself runs for 2 days now. All E-Mails are delivered correctly.
-------------------------------------------------------
Date: 2012-Nov-14 22:08
By: m-a
Comment:
Some questions and notes:
1. What is libdispatch?
2. Why is fetchmail on macports linking to it?
3. Why does libdispatch require an application to keep random file descriptors open?
4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream?
Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment.
Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it.
Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck.
5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem.
Please report back with answers to these four questions, and possibly with macports statements to the notes.
-------------------------------------------------------
Date: 2012-Nov-14 01:27
By: madman1234
Comment:
Here is the answer from macports:
[...]
http://trac.macports.org/ticket/36984#comment:3
This message is printed by libdispatch (and is thus Apple-specific). Apparently fetchmail closes file descriptors that are used by libdispatch, which terminates the process using this message when this happens. I guess one would have to attach a debugger, see where the file descriptor is closed and see whether this actually is a "random" file descriptor and what can be done about it. The maintainer might also consider forwarding this to upstream fetchmail.
[...]
Do you have such a debug script?
Thanks
-------------------------------------------------------
For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=18794&group_id=1824
|
|
From: <ad...@be...> - 2012-11-19 11:58:40
|
Bug #18794, was updated on 2012-Nov-14 01:12
Here is a current snapshot of the bug.
Project: fetchmail
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: madman1234
Assigned to : m-a
Summary: BUG in libdispatch client - OSX ML 10.8.2
Details: I installed fetchmail using mac ports. But everytime I start fetchmail (SSL included), I receive the following message in /var/log/mail.log
[...]
BUG in libdispatch client: Do not close random Unix descriptors
[...]
I have compiled the latest fetchmail version by myself, but I receive the same message.
Fetchmail itself works, but what does it means?
If I should ran any debugs, just let me know :)
Thanks
Soeren
Follow-Ups:
Date: 2012-Nov-19 01:58
By: madman1234
Comment:
1. What is libdispatch?
Libdispatch is part of the OS. It's linked into virtually every program,
as you can see from:
{{{
otool -L /usr/lib/libc.dylib
}}}
2. Why is fetchmail on macports linking to it?
It is done by default from OSX. Macports is here not involved.
3. Why does libdispatch require an application to keep random file descriptors open?
I don't know.
4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream?
It is not macports specific, it seems to be a standard behavior by default (OSX)
Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment.
The error message appears only once, after fetchmail tries to fetch mail via POP3 SSL. If there is no POP3 Server configured, then there is no error message on startup.
Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it.
I have compiled fetchmail by myself, wihtout macports, and the same issue occurs.
Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck.
I don't want to use getmail. Fetchmail is verfy stable and I like it a lot.
5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem.
With -d 0 there is no error message.
I am running fetchmail now on my OSX 10.8.2 Server. The error message appears when fetchmail starts, the program itself runs for 2 days now. All E-Mails are delivered correctly.
-------------------------------------------------------
Date: 2012-Nov-14 22:08
By: m-a
Comment:
Some questions and notes:
1. What is libdispatch?
2. Why is fetchmail on macports linking to it?
3. Why does libdispatch require an application to keep random file descriptors open?
4. If fetchmail spams the logs due to macports specific, why do the macports involved people believe this bug should be reported upstream?
Note #1: Fetchmail deliberately closes unneeded file descriptors in a tradition of daemonizing (going to background and detaching from the controlling TTY/terminal) with a clean environment, so as to leave as few attack vectors as possible - closing foreign file descriptors fetchmail may have inherited from the invoking process avoids collateral damage in the case that a bug were to be discovered that let fetchmail write to a random file descriptor (no such bug is known in the latest release version at this time), and it also avoids an incomplete detachment.
Note #2: fetchmail is single-threaded, so if libdispatch is about multithreading, macports should not be using it.
Note #3, referring to the macports bug: getmail does not (can not, due to missing features in the Python library that getmail is using) detect man in the middle attacks on SSL/TLS connections. fetchmail does, if used with --sslcertck.
5. As a workaround, please try and see if running fetchmail with "-d 0" avoids the problem.
Please report back with answers to these four questions, and possibly with macports statements to the notes.
-------------------------------------------------------
Date: 2012-Nov-14 01:27
By: madman1234
Comment:
Here is the answer from macports:
[...]
http://trac.macports.org/ticket/36984#comment:3
This message is printed by libdispatch (and is thus Apple-specific). Apparently fetchmail closes file descriptors that are used by libdispatch, which terminates the process using this message when this happens. I guess one would have to attach a debugger, see where the file descriptor is closed and see whether this actually is a "random" file descriptor and what can be done about it. The maintainer might also consider forwarding this to upstream fetchmail.
[...]
Do you have such a debug script?
Thanks
-------------------------------------------------------
For detailed info, follow this link:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=18794&group_id=1824
|
|
From: Translation P. R. <ro...@tr...> - 2012-11-18 15:12:49
|
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'fetchmail' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/fetchmail/da.po
(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive. Ask at the address below if you want this.)
All other PO files for your package are available in:
http://translationproject.org/latest/fetchmail/
Please consider including all of these in your next release, whether
official or a pretest.
Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below. The tarball may be just a pretest or a
snapshot, it does not even have to compile. It is just used by the
translators when they need some extra translation context.
The following HTML page has been updated:
http://translationproject.org/domain/fetchmail.html
If any question arises, please contact the translation coordinator.
Thank you for all your work,
The Translation Project robot, in the
name of your translation coordinator.
<coo...@tr...>
|
147 messages has been excluded from this view by a project administrator.
