From: Stéphane L. <ste...@lu...> - 2006-01-01 23:50:02
|
Hi, I hope, that this is the right place for my question regarding fetchmail: I have switched my mailserver from linux to Mac OS X 10.4. I apreciated, that fetchmail was already included in OS 10.4. But on OS X it takes 1-2 minutes for fetchmail to set up a connection: When I start fetchmail, I get this message: fetchmail: starting fetchmail 6.2.5 daemon fetchmail: 6.2.5 querying ... (protocol IMAP) at Sat, 31 Dec 2005 03:03:13 +0100 (CET): poll started Then nothing happens for about one minute (timout?), then fetchmail ist running normaly: fetchmail: IMAP< * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] ... 03:04:11 +0100 (CET) fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX- REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND LOGIN-REFERRALS STARTTLS AUTH=LOGIN When I try to connect manualy, I get an answer at once: mac-mini:/var/root root# telnet ... 143 Trying ... ... Connected to .... Escape character is '^]'. * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] ... IMAP4rev1 2003.339 at Sun, 1 Jan 2006 23:47:33 +0100 (CET) On my linux server it takes only a few seconds for fetchmail to check the mail accounts? What can I do? Is it a DNS or IDENT problem? I'm using a NAT router. Kind regards, Stephane |
From: Rob M. <rob...@gm...> - 2006-01-02 00:32:52
|
On 01/01/06, Stéphane Lux <ste...@lu...> wrote: > > When I start fetchmail, I get this message: > > fetchmail: starting fetchmail 6.2.5 daemon As per my message on the other list - please try 6.3.1. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche |
From: Stéphane L. <ste...@lu...> - 2006-01-02 23:01:06
|
Am 02.01.2006 um 00:32 schrieb Rob MacGregor: > On 01/01/06, Stéphane Lux <ste...@lu...> wrote: >> >> When I start fetchmail, I get this message: >> >> fetchmail: starting fetchmail 6.2.5 daemon > > As per my message on the other list - please try 6.3.1. ;) I still have the same delays wit 6.3.1. |
From: Rob F. <rf...@fu...> - 2006-01-02 16:39:12
|
Stéphane Lux wrote: > fetchmail: starting fetchmail 6.2.5 daemon > fetchmail: 6.2.5 querying ... (protocol IMAP) at Sat, 31 Dec 2005 > 03:03:13 +0100 (CET): poll started > > Then nothing happens for about one minute (timout?), then fetchmail > ist running normaly: Normally delays of a minute or two indicate a DNS problem somewhere. > On my linux server it takes only a few seconds for fetchmail to check > the mail accounts? What can I do? Is it a DNS or IDENT problem? I'm > using a NAT router. Ah, ident could be a possibility too, depending on the server software, but DNS is more likely. As the other Rob recommended, first try fetchmail 6.3.1 from http://fetchmail.berlios.de/. If that doesn't help let us know. -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
From: Stéphane L. <ste...@lu...> - 2006-01-02 23:00:06
|
Am 02.01.2006 um 16:38 schrieb Rob Funk: > Stéphane Lux wrote: >> fetchmail: starting fetchmail 6.2.5 daemon >> fetchmail: 6.2.5 querying ... (protocol IMAP) at Sat, 31 Dec 2005 >> 03:03:13 +0100 (CET): poll started >> >> Then nothing happens for about one minute (timout?), then fetchmail >> ist running normaly: > > Normally delays of a minute or two indicate a DNS problem somewhere. What kind of DNS problem? Server or client? I can telnet to the port 143 without a delay. >> On my linux server it takes only a few seconds for fetchmail to check >> the mail accounts? What can I do? Is it a DNS or IDENT problem? I'm >> using a NAT router. > > Ah, ident could be a possibility too, depending on the server > software, but > DNS is more likely. > > As the other Rob recommended, first try fetchmail 6.3.1 from > http://fetchmail.berlios.de/. If that doesn't help let us know. I have tried fetchmail 6.3.1. I still have the one minute delays for setting up a connection: mac-mini:~/Desktop root# ./fetchmail -Nv -f /var/root/.fetchmailrc fetchmail: WARNING: Running as root is discouraged. fetchmail: starting fetchmail 6.3.1 daemon fetchmail: 6.3.1 querying *** (protocol IMAP) at Mon, 02 Jan 2006 22:56:38 +0100 (CET): poll started fetchmail: IMAP< * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] *** IMAP4rev1 2003.339 at Mon, 2 Jan 2006 22:57:37 +0100 (CET) ... |
From: Rob M. <rob...@gm...> - 2006-01-03 00:50:27
|
[ Please don't CC me - I get the mail on the list ] On 02/01/06, Stéphane Lux <ste...@lu...> wrote: > > I have tried fetchmail 6.3.1. I still have the one minute delays for > setting up a connection: Next thing to do is run fetchmail under truss to get a dump of what's going on. Watching that it should be fairly obvious where the problem lies. The output of that, with the area the pause occurs marked, would help in tracking down the problem. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche |
From: Stéphane L. <ste...@lu...> - 2006-01-03 17:19:32
|
Am 03.01.2006 um 00:50 schrieb Rob MacGregor: > [ Please don't CC me - I get the mail on the list ] > > On 02/01/06, Stéphane Lux <ste...@lu...> wrote: >> >> I have tried fetchmail 6.3.1. I still have the one minute delays for >> setting up a connection: > > Next thing to do is run fetchmail under truss to get a dump of what's > going on. Watching that it should be fairly obvious where the problem > lies. The output of that, with the area the pause occurs marked, > would help in tracking down the problem. Here is the output of kdump: ... 2710 fetchmail RET sigaction 0 12710 fetchmail CALL sigaction(0xd,0xbfffd3d8,0xbfffd450) 12710 fetchmail RET sigaction 0 12710 fetchmail CALL sigprocmask(0x1,0,0x32c28) 12710 fetchmail RET sigprocmask 0 12710 fetchmail CALL setitimer(0,0xbfffd460,0) 12710 fetchmail RET setitimer 0 --- here is the one minute delay --- 12710 fetchmail CALL socket(0x2,0x1,0) 12710 fetchmail RET socket 4 12710 fetchmail CALL connect(0x4,0x3018b0,0x10) 12710 fetchmail RET connect 0 12710 fetchmail CALL setitimer(0,0xbfffd460,0) 12710 fetchmail RET setitimer 0 12710 fetchmail CALL setitimer(0,0xbfffd460,0) 12710 fetchmail RET setitimer 0 12710 fetchmail CALL setitimer(0,0xbfffb3a0,0) 12710 fetchmail RET setitimer 0 12710 fetchmail CALL recvfrom(0x4,0xbfffb450,0x2000,0x2,0,0) 12710 fetchmail GIO fd 4 wrote 147 bytes ... Does this help in tracking down the problem? |
From: Matthias A. <mat...@gm...> - 2006-01-04 18:40:59
|
Stéphane Lux <ste...@lu...> writes: > Am 02.01.2006 um 16:38 schrieb Rob Funk: > >> Stéphane Lux wrote: >>> fetchmail: starting fetchmail 6.2.5 daemon >>> fetchmail: 6.2.5 querying ... (protocol IMAP) at Sat, 31 Dec 2005 >>> 03:03:13 +0100 (CET): poll started >>> >>> Then nothing happens for about one minute (timout?), then fetchmail >>> ist running normaly: >> >> Normally delays of a minute or two indicate a DNS problem somewhere. > > What kind of DNS problem? Server or client? I can telnet to the port > 143 without a delay. Probably the same as <https://bugzilla.mozilla.org/show_bug.cgi?id=231607>. Try this on your fetchmail 6.3.1 source directory (requires Perl installed): perl -ple 's/([AP])F_UNSPEC/\1F_INET/g' -i.bak \ checkalias.c driver.c env.c servport.c Then rebuild and reinstall fetchmail 6.3.1 and let us know if the problem is gone. Merci. -- Matthias Andree |