Menu
▾
▴
fetchmail-users
|
From: Jonathan B. <jon...@er...> - 2011-02-25 15:52:28
|
I've had the following errors in my syslog for some time now - whatever
the problem it doesn't _seem_ to affect mail fetching though.
I'm fetching from Exchange (wish I could find out its version).
I'm using 6.3.19+NTLM+SSL on a SUN with Solaris 10.
My fetchmailrc:
set daemon 10
set syslog
set postmaster "postmaster"
set no bouncemail
set no spambounce
set properties ""
poll mail.<snip> with proto IMAP with auth password
user '<snip>' there with password '<snip>' is '<snip>' here
options fetchall no mimedecode ssl idle
As you can see there is a very regular pattern, happening every 5:14,
more or less. (the "awakened" is just a cron job that makes sure
fetchmail is running)
Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 676216 mail.error] re-poll
failed
Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 831971 mail.error] socket
error while fetching from <snip>
Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 991256 mail.info] Query
status=2 (SOCKET)
Feb 25 14:29:57 jnoblade fetchmail[1588]: [ID 676216 mail.error] re-poll
failed
Feb 25 14:29:57 jnoblade fetchmail[1588]: [ID 831971 mail.error] socket
error while fetching from <snip>
Feb 25 14:29:57 jnoblade fetchmail[1588]: [ID 991256 mail.info] Query
status=2 (SOCKET)
Feb 25 14:30:00 jnoblade fetchmail[1588]: [ID 205005 mail.info] awakened
by signal 16
Feb 25 14:35:04 jnoblade fetchmail[1588]: [ID 676216 mail.error] re-poll
failed
Feb 25 14:35:04 jnoblade fetchmail[1588]: [ID 831971 mail.error] socket
error while fetching from <snip>
Feb 25 14:35:04 jnoblade fetchmail[1588]: [ID 991256 mail.info] Query
status=2 (SOCKET)
Feb 25 14:40:18 jnoblade fetchmail[1588]: [ID 676216 mail.error] re-poll
failed
Feb 25 14:40:18 jnoblade fetchmail[1588]: [ID 831971 mail.error] socket
error while fetching from <snip>
Feb 25 14:40:18 jnoblade fetchmail[1588]: [ID 991256 mail.info] Query
status=2 (SOCKET)
Feb 25 14:45:29 jnoblade fetchmail[1588]: [ID 676216 mail.error] re-poll
failed
Feb 25 14:45:29 jnoblade fetchmail[1588]: [ID 831971 mail.error] socket
error while fetching from
|
|
From: Matthias A. <mat...@gm...> - 2011-02-25 18:04:19
|
Am 25.02.2011 15:52, schrieb Jonathan Buschmann: > I've had the following errors in my syslog for some time now - whatever > the problem it doesn't _seem_ to affect mail fetching though. > I'm fetching from Exchange (wish I could find out its version). > I'm using 6.3.19+NTLM+SSL on a SUN with Solaris 10. > My fetchmailrc: > set daemon 10 > set syslog > set postmaster "postmaster" > set no bouncemail > set no spambounce > set properties "" > poll mail.<snip> with proto IMAP with auth password > user '<snip>' there with password '<snip>' is '<snip>' here > options fetchall no mimedecode ssl idle > > As you can see there is a very regular pattern, happening every 5:14, > more or less. (the "awakened" is just a cron job that makes sure > fetchmail is running) > Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 676216 mail.error] re-poll > failed > Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 831971 mail.error] socket > error while fetching from <snip> > Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 991256 mail.info] Query > status=2 (SOCKET) Hi Jonathan, Probably some docket timeout of ~300s. Can I see a verbose trace? Please run: fetchmail -q env LC_ALL=C fetchmail -vv and check syslog after two "re-poll failed". This should help us closing in on the whats and why it's failing. Thanks. Best regards Matthias |
|
From: Jonathan B. <jon...@er...> - 2011-02-26 16:32:12
|
With verbose logging... I'm including the pertinent part: Feb 26 16:12:03 jnoblade fetchmail[4894]: [ID 425900 mail.info] IMAP> A0004 IDLE Feb 26 16:12:03 jnoblade fetchmail[4894]: [ID 163756 mail.info] IMAP< + IDLE accepted, awaiting DONE command. Feb 26 16:17:04 jnoblade fetchmail[4894]: [ID 676216 mail.error] re-poll failed Feb 26 16:17:04 jnoblade fetchmail[4894]: [ID 831971 mail.error] socket error while fetching from <snip> Feb 26 16:17:04 jnoblade fetchmail[4894]: [ID 547766 mail.info] 6.3.19+jb1 querying <snip> (protocol IMAP) at Sat, 26 Feb 2011 16:17:04 +0100 (CET): poll completed Feb 26 16:17:04 jnoblade fetchmail[4894]: [ID 991256 mail.info] Query status=2 (SOCKET) Feb 26 16:17:04 jnoblade fetchmail[4894]: [ID 342421 mail.info] sleeping at Sat, 26 Feb 2011 16:17:04 +0100 (CET) for 10 seconds Feb 26 16:17:14 jnoblade fetchmail[4894]: [ID 203901 mail.info] awakened at Sat, 26 Feb 2011 16:17:14 +0100 (CET) Feb 26 16:17:14 jnoblade fetchmail[4894]: [ID 562660 mail.info] 6.3.19+jb1 querying <snip> (protocol IMAP) at Sat, 26 Feb 2011 16:17:14 +0100 (CET): poll started Feb 26 16:17:14 jnoblade fetchmail[4894]: [ID 702911 mail.info] Trying to connect to <snip>...connected. and then things proceed normally. At precisely 25/02/2011 18.04, with renowned erudition Matthias Andree eloquently scribed: > Am 25.02.2011 15:52, schrieb Jonathan Buschmann: >> I've had the following errors in my syslog for some time now - whatever >> the problem it doesn't _seem_ to affect mail fetching though. >> I'm fetching from Exchange (wish I could find out its version). >> I'm using 6.3.19+NTLM+SSL on a SUN with Solaris 10. >> My fetchmailrc: >> set daemon 10 >> set syslog >> set postmaster "postmaster" >> set no bouncemail >> set no spambounce >> set properties "" >> poll mail.<snip> with proto IMAP with auth password >> user '<snip>' there with password'<snip>' is'<snip>' here >> options fetchall no mimedecode ssl idle >> >> As you can see there is a very regular pattern, happening every 5:14, >> more or less. (the "awakened" is just a cron job that makes sure >> fetchmail is running) >> Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 676216 mail.error] re-poll >> failed >> Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 831971 mail.error] socket >> error while fetching from<snip> >> Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 991256 mail.info] Query >> status=2 (SOCKET) > Hi Jonathan, > > Probably some docket timeout of ~300s. > > Can I see a verbose trace? Please run: > > fetchmail -q > env LC_ALL=C fetchmail -vv > > and check syslog after two "re-poll failed". > > This should help us closing in on the whats and why it's failing. > > Thanks. > > Best regards > Matthias > _______________________________________________ > fetchmail-users mailing list > fet...@li... > https://lists.berlios.de/mailman/listinfo/fetchmail-users |
|
From: Jonathan B. <jon...@er...> - 2011-02-28 09:57:45
|
BTW. -v gives me verbose logging. -vv turns it off. same for -v -v (get normal logging) Jonathan At precisely 25/02/2011 18.04, with renowned erudition Matthias Andree eloquently scribed: > Am 25.02.2011 15:52, schrieb Jonathan Buschmann: >> I've had the following errors in my syslog for some time now - whatever >> the problem it doesn't _seem_ to affect mail fetching though. >> I'm fetching from Exchange (wish I could find out its version). >> I'm using 6.3.19+NTLM+SSL on a SUN with Solaris 10. >> My fetchmailrc: >> set daemon 10 >> set syslog >> set postmaster "postmaster" >> set no bouncemail >> set no spambounce >> set properties "" >> poll mail.<snip> with proto IMAP with auth password >> user '<snip>' there with password'<snip>' is'<snip>' here >> options fetchall no mimedecode ssl idle >> >> As you can see there is a very regular pattern, happening every 5:14, >> more or less. (the "awakened" is just a cron job that makes sure >> fetchmail is running) >> Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 676216 mail.error] re-poll >> failed >> Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 831971 mail.error] socket >> error while fetching from<snip> >> Feb 25 14:24:43 jnoblade fetchmail[1588]: [ID 991256 mail.info] Query >> status=2 (SOCKET) > Hi Jonathan, > > Probably some docket timeout of ~300s. > > Can I see a verbose trace? Please run: > > fetchmail -q > env LC_ALL=C fetchmail -vv > > and check syslog after two "re-poll failed". > > This should help us closing in on the whats and why it's failing. > > Thanks. > > Best regards > Matthias > _______________________________________________ > fetchmail-users mailing list > fet...@li... > https://lists.berlios.de/mailman/listinfo/fetchmail-users |
|
From: Matthias A. <mat...@gm...> - 2011-02-28 10:37:19
|
Am 28.02.2011 09:57, schrieb Jonathan Buschmann: > BTW. > -v gives me verbose logging. -vv turns it off. same for -v -v (get > normal logging) > Jonathan Please check your syslog configuration -- fetchmail logs at ERR and INFO priorities. Chances are that your syslog provider is configured at "NOTICE" level, which would discard "info"-level logging. In doubt, add --nosyslog --nodetach and check the output in the console. HTH Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2011-02-28 10:27:18
|
Am 28.02.2011 10:01, schrieb Matthias Andree: > Please check your syslog configuration -- fetchmail logs at ERR and INFO > priorities. Chances are that your syslog provider is configured at > "NOTICE" level, which would discard "info"-level logging. Hm... I see in your earlier logs that you do have mail.info and mail.error logs. But yours is the very first report in over half a dozen years that -vv were less verbose than -v, and I don't know how that could happen given the existing code -- try --nodetach --nosyslog. |
|
From: Jonathan B. <jon...@er...> - 2011-02-28 11:43:34
|
Hi Matthias, Your right that it is somehow a syslog problem. --nodetach --nosyslog behaves correctly with -vv OTOH I don't see anymore useful information compared with -v, as I sent earlier. FWIW my syslog is configed at mail.debug... must be a bug in my syslog daemon (IHTA my OS does suffer from some bitrot.) Jonathan At precisely 28/02/2011 10.10, with renowned erudition Matthias Andree eloquently scribed: > Am 28.02.2011 10:01, schrieb Matthias Andree: > >> Please check your syslog configuration -- fetchmail logs at ERR and INFO >> priorities. Chances are that your syslog provider is configured at >> "NOTICE" level, which would discard "info"-level logging. > Hm... I see in your earlier logs that you do have mail.info and > mail.error logs. But yours is the very first report in over half a > dozen years that -vv were less verbose than -v, and I don't know how > that could happen given the existing code -- try --nodetach --nosyslog. > _______________________________________________ > fetchmail-users mailing list > fet...@li... > https://lists.berlios.de/mailman/listinfo/fetchmail-users -- Picture (Device Independent Bitmap) *JONATHAN BUSCHMANN Customer Solution Sales * Ericsson Telecomunicazioni S.p.A. Business Segment Services, Market Unit South East Europe Strada 2, Palazzo C 20090 Assago Milanofiori (MI), Italy Phone +390239572097 Fax +390239572902 Mobile +393351223478 Jon...@er... www.ericsson.com Picture (Device Independent Bitmap) |
|
From: Jonathan B. <jon...@er...> - 2011-02-28 15:25:23
|
In-line... At precisely 28/02/2011 15.01, with renowned erudition Matthias Andree eloquently scribed: > Am 28.02.2011 11:43, schrieb Jonathan Buschmann: >> Hi Matthias, >> Your right that it is somehow a syslog problem. --nodetach --nosyslog >> behaves correctly with -vv >> OTOH I don't see anymore useful information compared with -v, as I sent >> earlier. >> >> FWIW my syslog is configed at mail.debug... must be a bug in my syslog >> daemon (IHTA my OS does suffer from some bitrot.) > Basically the problem appears to be that the IDLE-ing connection gets > somehow closed at socket level prematurely. > > How exactly needs to be established on a lower network layer, possibly > with tcpdump, wireshark, or similar, and see if the connection gets > reset, by whom, and when, or if there is a regular FIN/ACK sequence (in > that case, Exchange would be the suspect). > > Possible reasons include: > > - some firewall on either end expiring stateful rules associated to the > idling connection Can exclude this. > - some masquerade/NAT device (possibly router, usually on the client > side) expiring forwarding rules prematurely Can exclude this. > - the Exchange server closing the connection after 5 minutes of idle > time when it should allow 30 minutes. I've never operated an Exchange > server and know nothing about configuration options. Likely. strange that no one else has seen it, if it's this. Unless it's something configurable on Exchange. > > If you can't find the reason, you can locally modify the imap.c source, > look for the figure 1680 (28 * 60 seconds), lower that to 270 (4.5 * 60 > seconds), recompile and reinstall; however, I am not considering such a > change upstream. I'll give it a try. thanks! Jonathan > Hope that helps > Matthias > _______________________________________________ > fetchmail-users mailing list > fet...@li... > https://lists.berlios.de/mailman/listinfo/fetchmail-users |
|
From: Matthias A. <mat...@gm...> - 2011-02-28 15:01:59
|
Am 28.02.2011 11:43, schrieb Jonathan Buschmann: > Hi Matthias, > Your right that it is somehow a syslog problem. --nodetach --nosyslog > behaves correctly with -vv > OTOH I don't see anymore useful information compared with -v, as I sent > earlier. > > FWIW my syslog is configed at mail.debug... must be a bug in my syslog > daemon (IHTA my OS does suffer from some bitrot.) Basically the problem appears to be that the IDLE-ing connection gets somehow closed at socket level prematurely. How exactly needs to be established on a lower network layer, possibly with tcpdump, wireshark, or similar, and see if the connection gets reset, by whom, and when, or if there is a regular FIN/ACK sequence (in that case, Exchange would be the suspect). Possible reasons include: - some firewall on either end expiring stateful rules associated to the idling connection - some masquerade/NAT device (possibly router, usually on the client side) expiring forwarding rules prematurely - the Exchange server closing the connection after 5 minutes of idle time when it should allow 30 minutes. I've never operated an Exchange server and know nothing about configuration options. If you can't find the reason, you can locally modify the imap.c source, look for the figure 1680 (28 * 60 seconds), lower that to 270 (4.5 * 60 seconds), recompile and reinstall; however, I am not considering such a change upstream. Hope that helps Matthias |
|
From: Matthias A. <mat...@gm...> - 2011-02-28 15:40:00
|
Am 28.02.2011 15:25, schrieb Jonathan Buschmann: > At precisely 28/02/2011 15.01, with renowned erudition Matthias Andree > eloquently scribed: >> Possible reasons include: ... >> - the Exchange server closing the connection after 5 minutes of idle >> time when it should allow 30 minutes. I've never operated an Exchange >> server and know nothing about configuration options. > Likely. strange that no one else has seen it, if it's this. Unless it's > something configurable on Exchange. Possibly other clients reconnect silently. Fetchmail doesn't do that. |
|
From: Matthias A. <mat...@gm...> - 2011-02-28 19:05:11
|
Am 28.02.2011 17:58, schrieb Jerry: > According to the info on > "http://technet.microsoft.com/en-us/library/ff459598.aspx", the default > setting is 30 minutes for the 2010 version. I have not been able to > confirm it, however, it appears that the older 2007 version defaults to > 20 minutes. Now, if the version is <=2005, then all bets are off. > > If the OP could post the version and possible the output of making a > connection to the Exchange server, a better guess could be made as to > where the problem lays. Thanks, Jerry. However, Jonathan stated earlier he had difficulties determining the Exchange server's version. Exchange 2003 as provided by Alice DSL Germany greets me with "version 6.5.mumble" in case that helps. Exchange 2010 apparently reveals its version not in greeting or capability, but when signing off after logout (even if you didn't log in in the first place). > I have confirmed that the settings are configurable on the Exchange > server. Of course, the user has to know what version he/she is going to > configure. ...and have administrative access in the first place which I take he hasn't. Thanks for quoting relevant sections from RFC material (I think the newer reference is RFC 3501.), saved me quite some digging. HTH Matthias |
|
From: Jerry <fet...@se...> - 2011-02-28 23:10:05
|
On Mon, 28 Feb 2011 19:05:07 +0100 Matthias Andree <mat...@gm...> articulated: > Am 28.02.2011 17:58, schrieb Jerry: > > > According to the info on > > "http://technet.microsoft.com/en-us/library/ff459598.aspx", the > > default setting is 30 minutes for the 2010 version. I have not been > > able to confirm it, however, it appears that the older 2007 version > > defaults to 20 minutes. Now, if the version is <=2005, then all > > bets are off. > > > > If the OP could post the version and possible the output of making a > > connection to the Exchange server, a better guess could be made as > > to where the problem lays. > > Thanks, Jerry. > > However, Jonathan stated earlier he had difficulties determining the > Exchange server's version. Exchange 2003 as provided by Alice DSL > Germany greets me with "version 6.5.mumble" in case that helps. > > Exchange 2010 apparently reveals its version not in greeting or > capability, but when signing off after logout (even if you didn't log > in in the first place). > > > I have confirmed that the settings are configurable on the Exchange > > server. Of course, the user has to know what version he/she is > > going to configure. > > ...and have administrative access in the first place which I take he > hasn't. > > Thanks for quoting relevant sections from RFC material (I think the > newer reference is RFC 3501.), saved me quite some digging. For what its worth: http://support.microsoft.com/kb/158530 Exchange Server 4.0 4.0.837 April 1996 Microsoft Exchange Server 4.0 (a) 4.0.993 August 1996 Microsoft Exchange Server 4.0 SP1 4.0.838 May 1996 Microsoft Exchange Server 4.0 SP2 4.0.993 August 1996 Microsoft Exchange Server 4.0 SP3 4.0.994 November 1996 Microsoft Exchange Server 4.0 SP4 4.0.995 April 1997 Microsoft Exchange Server 4.0 SP5 4.0.996 May 1998 Microsoft Exchange Server 5.0 5.0.1457 March 1997 Microsoft Exchange Server 5.0 SP1 5.0.1458 June 1997 Microsoft Exchange Server 5.0 SP2 5.0.1460 February 1998 Microsoft Exchange Server 5.5 5.5.1960 November 1997 Microsoft Exchange Server 5.5 SP1 5.5.2232 July 1998 Microsoft Exchange Server 5.5 SP2 5.5.2448 December 1998 Microsoft Exchange Server 5.5 SP3 5.5.2650 September 1999 Microsoft Exchange Server 5.5 SP4 5.5.2653 November 2000 Microsoft Exchange 2000 Server 6.0.4417 October 2000 Microsoft Exchange 2000 Server (a) 6.0.4417 January 2001 Microsoft Exchange 2000 Server SP1 6.0.4712 July 2001 Microsoft Exchange 2000 Server SP2 6.0.5762 December 2001 Microsoft Exchange 2000 Server SP3 6.0.6249 August 2002 Microsoft Exchange 2000 Server post-SP3 6.0.6487 September 2003 Microsoft Exchange 2000 Server post-SP3 6.0.6556 April 2004 Microsoft Exchange 2000 Server post-SP3 6.0.6603 August 2004 Microsoft Exchange 2000 Server post-SP3 6.0.6620.5 March 2008 Microsoft Exchange 2000 Server post-SP3 6.0.6620.7 August 2008 Microsoft Exchange Server 2003 6.5.6944 October 2003 Microsoft Exchange Server 2003 SP1 6.5.7226 May 2004 Microsoft Exchange Server 2003 SP2 6.5.7638 October 2005 Microsoft Exchange Server 2003 post-SP2 6.5.7653.33 March 2008 Microsoft Exchange Server 2003 post-SP2 6.5.7654.4 August 2008 Microsoft Exchange Server 2007 8.0.685.24 or 8.0.685.25 December 2006 Microsoft Exchange Server 2007 SP1 8.1.0240.006 November 2007 Microsoft Exchange Server 2007 SP2 8.2.0176.002 August 2009 Microsoft Exchange Server 2007 SP3 8.3.0083.006 June 2010 Microsoft Exchange Server 2010 14.00.0639.021 October 2009 Microsoft Exchange Server 2010 SP1 14.01.0218.015 August 2010 Perhaps this might help someone :) -- Jerry ✌ Fet...@se... Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ |
|
From: Jerry <fet...@se...> - 2011-02-28 17:58:13
|
On Mon, 28 Feb 2011 15:39:56 +0100 Matthias Andree <mat...@gm...> articulated: > Am 28.02.2011 15:25, schrieb Jonathan Buschmann: > > > At precisely 28/02/2011 15.01, with renowned erudition Matthias > > Andree eloquently scribed: > > >> Possible reasons include: > > ... > > >> - the Exchange server closing the connection after 5 minutes of > >> idle time when it should allow 30 minutes. I've never operated an > >> Exchange server and know nothing about configuration options. Per RFC-2177 <quote> 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. </quote> > > Likely. strange that no one else has seen it, if it's this. Unless > > it's something configurable on Exchange. > > Possibly other clients reconnect silently. Fetchmail doesn't do that. According to the info on "http://technet.microsoft.com/en-us/library/ff459598.aspx", the default setting is 30 minutes for the 2010 version. I have not been able to confirm it, however, it appears that the older 2007 version defaults to 20 minutes. Now, if the version is <=2005, then all bets are off. If the OP could post the version and possible the output of making a connection to the Exchange server, a better guess could be made as to where the problem lays. I have confirmed that the settings are configurable on the Exchange server. Of course, the user has to know what version he/she is going to configure. -- Jerry ✌ Fet...@se... Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ |
|
From: Jerry <fet...@se...> - 2011-03-01 14:29:19
|
On Mon, 28 Feb 2011 19:05:07 +0100 Matthias Andree <mat...@gm...> articulated: > However, Jonathan stated earlier he had difficulties determining the > Exchange server's version. Exchange 2003 as provided by Alice DSL > Germany greets me with "version 6.5.mumble" in case that helps. I was surprised to discover that servers are not required to disclose their versions. "SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems. Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns. While some systems also identify their contact point for mail problems, this is not a substitute for maintaining the required "postmaster" address (see Section 4)." http://www.ietf.org/rfc/rfc5321.txt Microsoft does by default configure its Exchange servers to display their version information. However, any admin can easily modify that. I don't know of anything that the OP can do to alleviate that problem. -- Jerry ✌ Fet...@se... Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ |
|
From: Matthias A. <mat...@gm...> - 2011-03-01 14:46:39
|
Am 01.03.2011 14:29, schrieb Jerry: > I was surprised to discover that servers are not required to disclose > their versions. > > "SMTP server implementations MAY include identification of their > [...] > http://www.ietf.org/rfc/rfc5321.txt > > Microsoft does by default configure its Exchange servers to display > their version information. However, any admin can easily modify that. I > don't know of anything that the OP can do to alleviate that problem. It would appear that we're talking about Exchange's IMAP support here, where RFC5321 doesn't apply, but instead RFC3501. Not that it matters much for the problem at hand though. |
