Menu
▾
▴
fetchmail-users — User questions and discussion
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(2) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(21) |
Sep
(17) |
Oct
(35) |
Nov
(39) |
Dec
(55) |
| 2006 |
Jan
(70) |
Feb
(11) |
Mar
(55) |
Apr
(27) |
May
(73) |
Jun
(47) |
Jul
(63) |
Aug
(27) |
Sep
(52) |
Oct
(39) |
Nov
(87) |
Dec
(15) |
| 2007 |
Jan
(23) |
Feb
(46) |
Mar
(108) |
Apr
(63) |
May
(54) |
Jun
(34) |
Jul
(29) |
Aug
(103) |
Sep
(46) |
Oct
(69) |
Nov
(29) |
Dec
(17) |
| 2008 |
Jan
(45) |
Feb
(32) |
Mar
(25) |
Apr
(17) |
May
(39) |
Jun
(20) |
Jul
(64) |
Aug
(31) |
Sep
(38) |
Oct
(20) |
Nov
(42) |
Dec
(50) |
| 2009 |
Jan
(10) |
Feb
(38) |
Mar
(3) |
Apr
(29) |
May
(41) |
Jun
(31) |
Jul
(21) |
Aug
(53) |
Sep
(49) |
Oct
(26) |
Nov
(28) |
Dec
(15) |
| 2010 |
Jan
(83) |
Feb
(38) |
Mar
(33) |
Apr
(44) |
May
(9) |
Jun
(16) |
Jul
(35) |
Aug
(38) |
Sep
(11) |
Oct
(35) |
Nov
(68) |
Dec
(19) |
| 2011 |
Jan
(16) |
Feb
(69) |
Mar
(42) |
Apr
(54) |
May
(56) |
Jun
(29) |
Jul
|
Aug
(65) |
Sep
(3) |
Oct
(39) |
Nov
(33) |
Dec
(4) |
| 2012 |
Jan
(31) |
Feb
(21) |
Mar
(26) |
Apr
(13) |
May
(38) |
Jun
(39) |
Jul
(14) |
Aug
(31) |
Sep
(8) |
Oct
(32) |
Nov
(12) |
Dec
(16) |
| 2013 |
Jan
(40) |
Feb
(22) |
Mar
(21) |
Apr
(15) |
May
(13) |
Jun
(9) |
Jul
(34) |
Aug
(10) |
Sep
(10) |
Oct
|
Nov
(7) |
Dec
(1) |
| 2014 |
Jan
(25) |
Feb
(9) |
Mar
(8) |
Apr
(12) |
May
(7) |
Jun
|
Jul
(7) |
Aug
(4) |
Sep
(27) |
Oct
(25) |
Nov
(18) |
Dec
(3) |
| 2015 |
Jan
(18) |
Feb
(13) |
Mar
(4) |
Apr
(19) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(6) |
Oct
(4) |
Nov
(19) |
Dec
(6) |
| 2016 |
Jan
|
Feb
(8) |
Mar
(14) |
Apr
|
May
(11) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(11) |
Dec
(17) |
| 2017 |
Jan
(17) |
Feb
(35) |
Mar
|
Apr
(4) |
May
(8) |
Jun
(2) |
Jul
(16) |
Aug
|
Sep
(5) |
Oct
(11) |
Nov
(15) |
Dec
(10) |
| 2018 |
Jan
|
Feb
(3) |
Mar
|
Apr
(3) |
May
(2) |
Jun
(8) |
Jul
|
Aug
(10) |
Sep
(17) |
Oct
(15) |
Nov
(12) |
Dec
(10) |
| 2019 |
Jan
(4) |
Feb
(14) |
Mar
(33) |
Apr
(17) |
May
(7) |
Jun
(6) |
Jul
(2) |
Aug
(4) |
Sep
(22) |
Oct
(13) |
Nov
|
Dec
|
| 2020 |
Jan
(36) |
Feb
(19) |
Mar
(31) |
Apr
(2) |
May
(22) |
Jun
(7) |
Jul
(25) |
Aug
(9) |
Sep
(17) |
Oct
(52) |
Nov
(13) |
Dec
(9) |
| 2021 |
Jan
(23) |
Feb
(13) |
Mar
(9) |
Apr
(15) |
May
(3) |
Jun
(7) |
Jul
(4) |
Aug
(23) |
Sep
(3) |
Oct
(8) |
Nov
(28) |
Dec
(9) |
| 2022 |
Jan
(38) |
Feb
(2) |
Mar
(56) |
Apr
(24) |
May
(29) |
Jun
(22) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(2) |
Dec
|
| 2023 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(21) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2024 |
Jan
(15) |
Feb
(4) |
Mar
|
Apr
(4) |
May
(11) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(9) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
| 2025 |
Jan
(7) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(10) |
Jul
|
Aug
(1) |
Sep
(12) |
Oct
(24) |
Nov
(14) |
Dec
|
|
From: Matthias A. <mat...@gm...> - 2006-06-29 10:29:47
|
Dhandapani,Padmanabhan schrieb am 2006-06-29: > Hi Team, > I am using the fetchmail release 6.2.5 in my Solaris 5.8. Please update to 6.3.4. > I have installed sucssfully in the solaris box. > Then i have enabled the POP3 for my mail account and i have created the > /etc/fetchmailrc files as guided by internet as below. Please find my Please try to understand what the configuration looks like, everything is documented in the manual page. Alternatively, if Python and the Python-Tk libraries are installed, you can use fetchmailconf to configure fetchmail. > below fetchmailrc file. > > # more fetchmailrc > set syslog > set postmaster "app...@tu..." > set nobouncemail > set properties "" > set idfile /var/run/fetchmail.ids > poll pop3.tui.de.insite proto pop3 Add "uidl" to this line (without quote marks) > user 'app...@tu...' Is the password in .netrc? If not, it is missing. > poll pop3.tui.de.insite > user 'app...@tu...' Remove the second poll and user lines. > Now i am running the below command to fetchmail from my exchange box. > But i am not receiving any mail. What is this "/var/run/fetchmail.ids" > which is not created in my path. It is handled by fetchmail. > This is a plain text file which i have > to create or it will create by itself. > > fetchmail -v -v -f /etc/fetchmailrc Add --nosyslog to this command line to show what goes wrong. Please reply only to the list. -- Matthias Andree |
|
From: Dhandapani,Padmanabhan <Pad...@tu...> - 2006-06-29 10:23:31
|
Hi Team, I am using the fetchmail release 6.2.5 in my Solaris 5.8. I have installed sucssfully in the solaris box. Then i have enabled the POP3 for my mail account and i have created the /etc/fetchmailrc files as guided by internet as below. Please find my below fetchmailrc file. # more fetchmailrc set syslog set postmaster "app...@tu..." set nobouncemail set properties "" set idfile /var/run/fetchmail.ids poll pop3.tui.de.insite proto pop3 user 'app...@tu...' poll pop3.tui.de.insite user 'app...@tu...' Now i am running the below command to fetchmail from my exchange box. But i am not receiving any mail. What is this "/var/run/fetchmail.ids" which is not created in my path. This is a plain text file which i have to create or it will create by itself. fetchmail -v -v -f /etc/fetchmailrc Please help us to resolve this issue to use the fetchmail is better way. Expecting your reply assoonas possible. Many Thanks .... Regards Paddy Padmanabhan Dhandapani ______________________ Unix & Middleware Team TUI InfoTec GmbH Direct Number: +49(0)511-567-55974 Mail to: pad...@tu... Web Site: http://www.tui.de |
|
From: Andrew Longland-M. <an...@lo...> - 2006-06-28 20:24:29
|
Rob, Thanks for the quick reply... > >> My ISP provides forwarding from my own domain, and each and every email >> I receive has a proper Envelope-to; header. > >Sample header, plus contents of .fetchmailrc? > Sample header is Envelope-to: an...@lo... Received: from lists.gnu.org ([199.232.76.165]) by mx14.global.net.uk with esmtp (Exim 4.42) id 1FvZD5-0004RH-RF for an...@lo...; Wed, 28 Jun 2006 13:32:09 +0100 Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FvZD2-00010J-KI for an...@lo...; Wed, 28 Jun 2006 08:31:56 -0400 From: lil...@gn... Subject: lilypond-user Digest, Vol 43, Issue 73 To: lil...@gn... Reply-To: lil...@gn... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-BeenThere: lil...@gn... X-Mailman-Version: 2.1.5 Precedence: list List-Id: LilyPond user discussion <lilypond-user.gnu.org> List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/lilypond-user>, <mailto:lil...@gn...?subject=unsubscribe> List-Archive: <http://lists.gnu.org/pipermail/lilypond-user> List-Post: <mailto:lil...@gn...> List-Help: <mailto:lil...@gn...?subject=help> List-Subscribe: <http://lists.gnu.org/mailman/listinfo/lilypond-user>, <mailto:lil...@gn...?subject=subscribe> Sender: lil...@gn... Errors-To: lil...@gn... X-BV-Spam-Score: 1.6 (+) X-Envelope-From: lil...@gn... I did include my .fetchmailrc in my first post (with some obfuscation!) >> X-Fetchmail-Warning: recipient address (Envelope-to address) didn't >> match any local name >> >> Does anyone have any suggestions? > >Output of "fetchmail --nosyslog --nodetach -v -v -v" showing this, >along with the contents of your SMTP server's mail log for the same >mail would be useful. > Here is the output of "fetchmail --nosyslog --nodetach -v -v -v". I've edited for size, but there is nothing different for any of the other messages. fetchmail: 6.3.4 querying mail.freenetname.co.uk (protocol POP3) at Wed 28 Jun 2006 18:51:32 BST: poll started fetchmail: POP3< +OK freenetname.co.uk POP3 server ready to roll [80.189.80.146] fetchmail: POP3> CAPA fetchmail: POP3< -ERR non-existant command fetchmail: POP3< +OK freenetname.co.uk POP3 server ready to roll [80.189.80.146] fetchmail: POP3> USER mee...@fr... fetchmail: POP3< +OK Password required for mee...@fr... fetchmail: POP3> PASS * fetchmail: POP3< +OK Maildrop locked and loaded fetchmail: selecting or re-polling default folder fetchmail: POP3> STAT fetchmail: POP3< +OK 13 92562 13 messages for mee...@fr... at mail.freenetname.co.uk (92562 octets). fetchmail: POP3> LIST 1 fetchmail: POP3< +OK 1 875 fetchmail: POP3> RETR 1 fetchmail: POP3< +OK 875 octets reading message mee...@fr...@mail.freenetname.co.uk:1 of 13 (875 octets) About to rewrite From: Andrew Longland-Meech <an...@lo...> Rewritten version is From: Andrew Longland-Meech <an...@lo...> About to rewrite To: mee...@fr... Rewritten version is To: mee...@fr... fetchmail: no local matches, forwarding to schmoo fetchmail: SMTP< 220 localhost.localdomain ESMTP Sendmail 8.13.6/8.13.6; Wed, 28 Jun 2006 18:51:33 +0100 fetchmail: SMTP> EHLO localhost.localdomain fetchmail: SMTP< 250-localhost.localdomain Hello localhost.localdomain [127.0.0.1], pleased to meet you fetchmail: SMTP< 250-ENHANCEDSTATUSCODES fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250-8BITMIME fetchmail: SMTP< 250-SIZE fetchmail: SMTP< 250-DSN fetchmail: SMTP< 250-ETRN fetchmail: SMTP< 250-DELIVERBY fetchmail: SMTP< 250 HELP fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM:<an...@lo...> BODY=7BIT SIZE=875 fetchmail: SMTP< 250 2.1.0 <an...@lo...>... Sender ok fetchmail: SMTP> RCPT TO:<schmoo@localhost> fetchmail: SMTP< 250 2.1.5 <schmoo@localhost>... Recipient ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself fetchmail: message mee...@fr...@mail.freenetname.co.uk:1 was not the expected length (903 actual != 875 expected) fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 2.0.0 k5SHpX1K005829 Message accepted for delivery not flushed fetchmail: POP3> LIST 2 fetchmail: POP3< +OK 2 863 fetchmail: POP3> RETR 2 fetchmail: POP3< +OK 863 octets reading message mee...@fr...@mail.freenetname.co.uk:2 of 13 (863 octets) About to rewrite From: Andrew Longland-Meech <an...@lo...> Rewritten version is From: Andrew Longland-Meech <an...@lo...> About to rewrite To: ma...@lo... Rewritten version is To: ma...@lo... fetchmail: no local matches, forwarding to schmoo fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM:<an...@lo...> BODY=7BIT SIZE=863 fetchmail: SMTP< 250 2.1.0 <an...@lo...>... Sender ok fetchmail: SMTP> RCPT TO:<schmoo@localhost> fetchmail: SMTP< 250 2.1.5 <schmoo@localhost>... Recipient ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself fetchmail: message mee...@fr...@mail.freenetname.co.uk:2 was not the expected length (891 actual != 863 expected) fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 2.0.0 k5SHpX1L005829 Message accepted for delivery not flushed <SNIP>--------------------------------------------------------------- fetchmail: POP3> LIST 9 fetchmail: POP3< +OK 9 19866 fetchmail: POP3> RETR 9 fetchmail: POP3< +OK 19866 octets reading message mee...@fr...@mail.freenetname.co.uk:9 of 13 (19866 octets) About to rewrite From: lil...@gn... Rewritten version is From: lil...@gn... About to rewrite To: lil...@gn... Rewritten version is To: lil...@gn... About to rewrite Reply-To: lil...@gn... Rewritten version is Reply-To: lil...@gn... About to rewrite Sender: lil...@gn... Rewritten version is Sender: lil...@gn... fetchmail: no local matches, forwarding to schmoo fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM:<lil...@gn...> BODY=8BITMIME SIZE=19866 fetchmail: SMTP< 250 2.1.0 <lil...@gn...>... Sender ok fetchmail: SMTP> RCPT TO:<schmoo@localhost> fetchmail: SMTP< 250 2.1.5 <schmoo@localhost>... Recipient ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself ..................fetchmail: message mee...@fr...@mail.freenetname.co.uk:9 was not the expected length (20615 actual != 19866 expected) fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 2.0.0 k5SHpX1S005829 Message accepted for delivery not flushed <SNIP>--------------------------------------------------------------- fetchmail: POP3> QUIT fetchmail: POP3< +OK freenetname.co.uk POP3 server signing off fetchmail: SMTP> QUIT fetchmail: SMTP< 221 2.0.0 localhost.localdomain closing connection fetchmail: 6.3.4 querying mail.freenetname.co.uk (protocol POP3) at Wed 28 Jun 2006 18:51:57 BST: poll completed fetchmail: not swapping UID lists, no UIDs seen this query fetchmail: Deleting fetchids file. fetchmail: normal termination, status 0 fetchmail: Deleting fetchids file. Also a copy of /var/spool/maillog. I don't know if this is what you wanted. Jun 28 18:51:35 localhost sendmail[5829]: k5SHpX1K005829: from=<an...@lo...>, size=1156, class=0, nrcpts=1, msgid=<115...@lo...>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:35 localhost sendmail[5830]: k5SHpX1K005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=31356, dsn=2.0.0, stat=Sent Jun 28 18:51:37 localhost sendmail[5829]: k5SHpX1L005829: from=<an...@lo...>, size=1141, class=0, nrcpts=1, msgid=<115...@lo...>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:37 localhost sendmail[5832]: k5SHpX1L005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=31341, dsn=2.0.0, stat=Sent Jun 28 18:51:37 localhost sendmail[5829]: k5SHpX1M005829: from=<an...@lo...>, size=2047, class=0, nrcpts=1, msgid=<115...@lo...>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:38 localhost sendmail[5834]: k5SHpX1M005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:01, mailer=local, pri=32243, dsn=2.0.0, stat=Sent Jun 28 18:51:39 localhost sendmail[5829]: k5SHpX1N005829: from=<an...@lo...>, size=2047, class=0, nrcpts=1, msgid=<115...@lo...>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:39 localhost sendmail[5836]: k5SHpX1N005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=32243, dsn=2.0.0, stat=Sent Jun 28 18:51:41 localhost sendmail[5829]: k5SHpX1O005829: from=<an...@lo...>, size=2047, class=0, nrcpts=1, msgid=<115...@lo...>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:41 localhost sendmail[5838]: k5SHpX1O005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=32243, dsn=2.0.0, stat=Sent Jun 28 18:51:42 localhost sendmail[5829]: k5SHpX1P005829: from=<an...@lo...>, size=1151, class=0, nrcpts=1, msgid=<115...@lo...>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:42 localhost sendmail[5841]: k5SHpX1P005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=31351, dsn=2.0.0, stat=Sent Jun 28 18:51:43 localhost sendmail[5829]: k5SHpX1Q005829: from=<an...@lo...>, size=2035, class=0, nrcpts=1, msgid=<115...@lo...>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:43 localhost sendmail[5843]: k5SHpX1Q005829: to=<schmoo@localhost>, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=32231, dsn=2.0.0, stat=Sent Jun 28 18:51:46 localhost sendmail[5829]: k5SHpX1R005829: from=<an...@lo...>, size=2047, class=0, nrcpts=1, msgid=<115...@lo...>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:46 localhost sendmail[5845]: k5SHpX1R005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=32243, dsn=2.0.0, stat=Sent Jun 28 18:51:51 localhost sendmail[5829]: k5SHpX1S005829: from=<lil...@gn...>, size=20146, class=-30, nrcpts=1, msgid=<200...@lo...>, bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:51 localhost sendmail[5847]: k5SHpX1S005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=104440, dsn=2.0.0, stat=Sent Jun 28 18:51:53 localhost sendmail[5829]: k5SHpX1T005829: from=<su...@th...>, size=19276, class=0, nrcpts=1, msgid=<20060628152751.21600.qmail@keila>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:53 localhost sendmail[5849]: k5SHpX1T005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=49476, dsn=2.0.0, stat=Sent Jun 28 18:51:54 localhost sendmail[5829]: k5SHpX1U005829: from=<su...@th...>, size=20838, class=0, nrcpts=1, msgid=<20060628160510.12010.qmail@keila>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:54 localhost sendmail[5851]: k5SHpX1U005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=51038, dsn=2.0.0, stat=Sent Jun 28 18:51:55 localhost sendmail[5829]: k5SHpX1V005829: from=<lil...@gn...>, size=9176, class=-30, nrcpts=1, msgid=<200...@lo...>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:55 localhost sendmail[5853]: k5SHpX1V005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=93470, dsn=2.0.0, stat=Sent Jun 28 18:51:57 localhost sendmail[5829]: k5SHpX1W005829: from=<su...@th...>, size=13098, class=0, nrcpts=1, msgid=<20060628161055.8573.qmail@keila>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1] Jun 28 18:51:57 localhost sendmail[5856]: k5SHpX1W005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=43298, dsn=2.0.0, stat=Sent Sorry for such a long post. I hope this helps with diagnosing the problem. Thanks in advance for any help. Regards, Andrew |
|
From: Rob M. <rob...@gm...> - 2006-06-28 19:16:02
|
On 6/28/06, Andrew Longland-Meech <an...@lo...> wrote:
> Hello list members,
>
> I hope someone can help me - I can't be the only person to have ever run
> into this problem. I've read the FAQ, but that doesn't seem to describe
> my situation and I've tried everything I can think of.
>
> Here's my setup:
>
> fetchmail version: 6.3.4
> My ISP provides forwarding from my own domain, and each and every email
> I receive has a proper Envelope-to; header.
Sample header, plus contents of .fetchmailrc?
> X-Fetchmail-Warning: recipient address (Envelope-to address) didn't
> match any local name
>
> Does anyone have any suggestions?
Output of "fetchmail --nosyslog --nodetach -v -v -v" showing this,
along with the contents of your SMTP server's mail log for the same
mail would be useful.
--
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: Uli Z. <ul...@ri...> - 2006-06-28 18:43:38
|
Am 28.06.2006 um 18:18 schrieb Matthias Andree:
>> The other are actually 4 occurrences of freeaddrinfo() in
>> checkalias.c that, via several function calls, end up being called
>> in line 1430 in driver.c in the fetch_messages() call. Depending
>> on the method you'll use, these could be tricky to handle, because
>> as I said
>> there are several function calls between the fetch_messages() call
>> and these freeaddrinfo() calls.
>
> I'm not very motivated to fix code that is not of much practical
> value (since it assumes inbound MX and POP3/IMAP server are the
> same) and that is scheduled for removal.
Of course that's up to you to decide. That's why I wrote that it's
probably better you fix this instead of me because you do know the
code much better. I have/had not the slightest idea what checkalias.c
is for, I just parsed the complete fetchmail code for occurrences of
freeaddrinfo() and looked if in the end they would be called from
within do_session() in driver.c and were thus subject to a possible
timeout interference.
Which of these occurrences are important, I leave completely up to
you to decide.
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Matthias A. <mat...@gm...> - 2006-06-28 18:18:24
|
On Wed, 28 Jun 2006, Uli Zappe wrote: > >I wonder if the resolver would finally recover a long time after > >the network connection has been restored > > When I encountered this fetchmail bug for the first time in real > life, fetchmail had stopped fetching mails for several *days*. So > even if it recovered after a "long time", this would be of no > practical value at all. OK, good to know. Thanks. > The other are actually 4 occurrences of freeaddrinfo() in > checkalias.c that, via several function calls, end up being called in > line 1430 in driver.c in the fetch_messages() call. Depending on the > method you'll use, these could be tricky to handle, because as I said > there are several function calls between the fetch_messages() call > and these freeaddrinfo() calls. I'm not very motivated to fix code that is not of much practical value (since it assumes inbound MX and POP3/IMAP server are the same) and that is scheduled for removal. -- Matthias Andree |
|
From: Uli Z. <ul...@ri...> - 2006-06-28 16:37:42
|
Am 28.06.2006 um 11:42 schrieb Matthias Andree:
> I wonder if the resolver would finally recover a long time after
> the network connection has been restored
When I encountered this fetchmail bug for the first time in real
life, fetchmail had stopped fetching mails for several *days*. So
even if it recovered after a "long time", this would be of no
practical value at all.
> - and perhaps if the negative TTL of cache entries can be configured.
I know of no such configuration possibilities in my case, but anyway,
since getaddrinfo() works as it should once freeaddrinfo() is
properly called, I don't think this is a caching issue at all.
> But OTOH, if you say that proper freeaddrinfo() use avoids the
> problem, then we don't need to think about this part, because I
> will add the missed freeaddrinfo() calls.
Exactly.
> I'll defend myself by calling these plain bugs, rather than not
> taking these calls "not ... too seriously".
Just having a cursory glance at the remaining code, there are at
least two other occurrences of freeaddrinfo() calls that could be
prevented by a timeout in do_session() in driver.c:
One is directly in driver.c, line 1043.
The other are actually 4 occurrences of freeaddrinfo() in
checkalias.c that, via several function calls, end up being called in
line 1430 in driver.c in the fetch_messages() call. Depending on the
method you'll use, these could be tricky to handle, because as I said
there are several function calls between the fetch_messages() call
and these freeaddrinfo() calls.
> Alright. Below is a fix to the problem you reported for servport.c
> (it was easy to fix),
Indeed. :-)
> please try and let me know if MacOS X works with the IPPROTO_TCP
> stuff.
Yep, it compiles just fine. Apart from that, there's not much to
test, yet. :-)
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Andrew Longland-M. <an...@lo...> - 2006-06-28 15:23:05
|
Hello list members, I hope someone can help me - I can't be the only person to have ever run into this problem. I've read the FAQ, but that doesn't seem to describe my situation and I've tried everything I can think of. Here's my setup: fetchmail version: 6.3.4 Kernel: 2.6.16-1.2080.13.rdt.rhfc5.ccrma ISP: Freenetname.co.uk My ISP provides forwarding from my own domain, and each and every email I receive has a proper Envelope-to; header. I want to have mail for (mypartner)@(mydomain).me.uk delivered to localuser (mypartner) and everything else delivered to localuser (me). Here's my .fetchmailrc file: set postmaster "(me)" set bouncemail set no spambounce set properties "" #set daemon 900 poll mail.freenetname.co.uk with proto POP3 envelope "Envelope-to" user "(username)@freenetname.co.uk" with password "(*******)" to "(mypartner)@(mydomain).me.uk"="(mypartner)" "(username)@freenetname.co.uk"="(me)" "(myname)@(mydomain).me.uk"="(me)" here options keep fetchall Now, I think this is setup correctly, following the example in the man page for a multi-drop setup, and indeed fetchmail seems to be using the Envelope-to address according to the output of 'fetchmail -v -v' but it simply isn't doing what it's supposed to and matching the server names to the local names! Everything still gets delivered to (me) and contains a header of the form - X-Fetchmail-Warning: recipient address (Envelope-to address) didn't match any local name Does anyone have any suggestions? Regards Andrew |
|
From: Uli Z. <ul...@ri...> - 2006-06-28 15:20:26
|
Am 28.06.2006 um 15:08 schrieb Matthias Andree:
> On Wed, 28 Jun 2006, Uli Zappe wrote:
>> I indeed see no other programming techniques to deal with that
>> issue.)
> Well, some options not yet mentioned are (without regard to their
> usability): [...long list...]
OK, you got me. :-)
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Matthias A. <mat...@gm...> - 2006-06-28 15:15:34
|
On Wed, 28 Jun 2006, Uli Zappe wrote: > The only difference is the OFFSET value of the /dev/null files (these > OFFSET values stay the same after the network outage in several lsof > calls I've performed). Honestly, though, I have no idea what that > means. :-) Whatever. More importantly, there are no sockets leaked, and that's good. -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-06-28 15:08:59
|
On Wed, 28 Jun 2006, Uli Zappe wrote: > >"you'll have to" or "you may have to" sounds more polite than "you > >must" (no offense taken, don't worry). > > Well, the force of the laws of logic isn't polite ... ;-) (This was > not meant to be a social "must" but rather a logical one, as I indeed > see no other programming techniques to deal with that issue.) Well, some options not yet mentioned are (without regard to their usability): - dedicated resource tracking with a specific list - store the address list in one of the per-server or per-poll structures, rather than globally - avoid the crude longjmp() (which should've been siglongjmp anyways) but rely on EINTR or similar. - give up on SIGALRM and use non-blocking I/O and select() instead. I haven't yet checked which way I'll go though. -- Matthias Andree |
|
From: Uli Z. <ul...@ri...> - 2006-06-28 15:08:04
|
Am 28.06.2006 um 02:46 schrieb Matthias Andree:
> Can you check with "lsof" or similar tools (that can
> list open files and sockets) how many files and sockets fetchmail
> holds
> open at the time when the problems start? It might be that the OS
> itself
> is leaking sockets here which might appear in fetchmail's address
> space.
Here is lsof output after a freshly restarted fetchmail that has
fetched mails just once, and works fine:
# lsof -p 5894
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
fetchmail 5894 root cwd VDIR 14,10 1224 2 /
fetchmail 5894 root txt VREG 14,10 217276 4621091 /usr/
bin/fetchmail
fetchmail 5894 root txt VREG 14,10 1797788 4583305 /usr/
lib/dyld
fetchmail 5894 root txt VREG 14,10 4379472 4583478 /usr/
lib/libSystem.B.dylib
fetchmail 5894 root txt VREG 14,10 1227808 4583480 /
System/Library/Frameworks/CoreFoundation.framework/Versions/A/
CoreFoundation
fetchmail 5894 root txt VREG 14,10 801160 4583488 /usr/
lib/libobjc.A.dylib
fetchmail 5894 root txt VREG 14,10 1789252 4583565 /
System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
fetchmail 5894 root 0u VCHR 3,2 0t0 53111684 /dev/null
fetchmail 5894 root 1u VCHR 3,2 0t0 53111684 /dev/null
fetchmail 5894 root 2u VCHR 3,2 0t0 53111684 /dev/null
fetchmail 5894 root 3r PSXSHM 0x0511b424 4096
obj=0x03680ee0
fetchmail 5894 root 4u unix 0x04af53b0 0t0 -
>0x032f3b60
Here is the same output after a 2 hour network outage and then the
Internet up again since 10 minutes or so, without fetchmail resuming
fetching mails:
# lsof -p 5894
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
fetchmail 5894 root cwd VDIR 14,10 1224 2 /
fetchmail 5894 root txt VREG 14,10 217276 4621091 /usr/
bin/fetchmail
fetchmail 5894 root txt VREG 14,10 1797788 4583305 /usr/
lib/dyld
fetchmail 5894 root txt VREG 14,10 4379472 4583478 /usr/
lib/libSystem.B.dylib
fetchmail 5894 root txt VREG 14,10 1227808 4583480 /
System/Library/Frameworks/CoreFoundation.framework/Versions/A/
CoreFoundation
fetchmail 5894 root txt VREG 14,10 801160 4583488 /usr/
lib/libobjc.A.dylib
fetchmail 5894 root txt VREG 14,10 1209056 4583589 /usr/
lib/libcrypto.0.9.7.dylib
fetchmail 5894 root txt VREG 14,10 1789252 4583565 /
System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
fetchmail 5894 root 0u VCHR 3,2 0t293 53111684 /dev/null
fetchmail 5894 root 1u VCHR 3,2 0t293 53111684 /dev/null
fetchmail 5894 root 2u VCHR 3,2 0t293 53111684 /dev/null
fetchmail 5894 root 3r PSXSHM 0x0511b424 4096
obj=0x03680ee0
fetchmail 5894 root 4u unix 0x04af53b0 0t0 -
>0x032f3b60
The only difference is the OFFSET value of the /dev/null files (these
OFFSET values stay the same after the network outage in several lsof
calls I've performed). Honestly, though, I have no idea what that
means. :-)
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Matthias A. <mat...@gm...> - 2006-06-28 11:42:28
|
On Wed, 28 Jun 2006, Uli Zappe wrote: > Well, you *can* call getaddrinfo() a second time before calling > freeaddrinfo() first in Mac OS X without a crash or anything, and > it's thread-safe since Mac OS X 10.2 (though not before). The only > thing is that if you call it again with exactly the same query data > and without calling freeaddrinfo() in between, it will report the > data it cached from the last call. You might call this a bug, but > Apple most probably will call it a feature ... Note that on Mac OS X, > getaddrinfo() is nothing more than a wrapper around the system's so- > called "lookupd" daemon, which handles all network addressing issues > with code that's completely different from all other Unix > implementations. Nothing wrong here. > If with "amount of time" you refer to the fact that the Internet must > be down a certain amount of time for the issue to occur, this seems > to be because the DNS data is cached for a certain amount of time, > either by getaddrinfo() itself, or by Mac OS X's local caching BIND, > or possibly by the caching name server of my router. Only when > there's no cache anymore and getaddrinfo() (unsuccessfully) tries to > retrieve that query data anew from the Internet, the timeout > interruption will occur and prevent freeaddrinfo() from being called. > > At least that's how I interpret all these error lines in my > logfiles. ;-) Well, that's plausible, but I wonder if the resolver would finally recover a long time after the network connection has been restored - and perhaps if the negative TTL of cache entries can be configured. But OTOH, if you say that proper freeaddrinfo() use avoids the problem, then we don't need to think about this part, because I will add the missed freeaddrinfo() calls. > Maybe it's a good idea to check for all occurrences of freeaddrinfo() > whether they are certain to be performed whenever they should. > Glimpsing at the code, e.g. in servport.c, line 65, the default > switch condition is a goto jump that prevents freeaddrinfo() from > being called, although it should be called (getaddrinfo() had > returned 0/success before, so "res" had been allocated). It seems > that calling freeaddrinfo() was not taken all too seriously > throughout fetchmail. I'll defend myself by calling these plain bugs, rather than not taking these calls "not ... too seriously". > Well, the force of the laws of logic isn't polite ... ;-) (This was > not meant to be a social "must" but rather a logical one, as I indeed > see no other programming techniques to deal with that issue.) Perhaps not in C. In the long run (fetchmail 7 or thereabouts), I might switch to something more OOP-like so I can use objects that know how to destruct themselves. (C++ is most likely from today's point of view.) > Well, that's more than OK with me! If you deal with bugs in > connection with Mac OS X, what you are afraid of are months or years > until a fix is applied - days are no problem at all. :-) Alright. Below is a fix to the problem you reported for servport.c (it was easy to fix), please try and let me know if MacOS X works with the IPPROTO_TCP stuff. The other getaddrinfo() calls require more attention and I'll see to them later. The "NEWS" hunk below will probably fail to apply, this is harmless. -- Matthias Andree |
|
From: Dave P. <sd...@gm...> - 2006-06-28 07:33:30
|
* Dave Patterson <sd...@gm...> [2006-06-28 08:58:29 +0700]: > Let me play with a couple settings here and I'll get back > to list. Ok, here it is: set syslog DOES send status report to /var/log/mail.log, file cannot be read by normal user, this setting cannot be overriden by command line option --nodetach set logfile MUST be given the full path to logfile (/home/dave/.fetchmaillog) NOT ~/.fetchmaillog or the .fetchmailrc line 'set logfile' is ignored and status is printed to screen. This option CAN be overridden by the option --nodetach 'set syslog' line before 'set logfile' line in .fetchmailrc has the effect of using 'set syslog' first, the second option ignored... (as most .rc files are executed top to bottom in common usage) -- Cheers, Dave |
|
From: Uli Z. <ul...@ri...> - 2006-06-28 06:01:36
|
Am 28.06.2006 um 02:46 schrieb Matthias Andree:
> While I'll certainly plug the leak (it may take until the week-end
> though), there might still be a related MacOS X bug. There is no
> obligation to call freeaddrinfo() before calling getaddrinfo()
> again, plus this function is required to be thread-safe (i. e. it
> needs to be
> reentrant).
Well, you *can* call getaddrinfo() a second time before calling
freeaddrinfo() first in Mac OS X without a crash or anything, and
it's thread-safe since Mac OS X 10.2 (though not before). The only
thing is that if you call it again with exactly the same query data
and without calling freeaddrinfo() in between, it will report the
data it cached from the last call. You might call this a bug, but
Apple most probably will call it a feature ... Note that on Mac OS X,
getaddrinfo() is nothing more than a wrapper around the system's so-
called "lookupd" daemon, which handles all network addressing issues
with code that's completely different from all other Unix
implementations.
> However, you say that the problems happen after a certain...
>
>> In my test case, getaddrinfo() may need up to 180s to time out.
>> However, I had set fetchmail's "timeout" parameter to only 60s. In
>> my tests, during the time when the Internet connection was down,
>> at least one "timeout after 60 seconds waiting to connect to
>> server xy" did indeed appear in the log for each server.
>
> ...amount of time.
If with "amount of time" you refer to the fact that the Internet must
be down a certain amount of time for the issue to occur, this seems
to be because the DNS data is cached for a certain amount of time,
either by getaddrinfo() itself, or by Mac OS X's local caching BIND,
or possibly by the caching name server of my router. Only when
there's no cache anymore and getaddrinfo() (unsuccessfully) tries to
retrieve that query data anew from the Internet, the timeout
interruption will occur and prevent freeaddrinfo() from being called.
At least that's how I interpret all these error lines in my
logfiles. ;-)
> Can you check with "lsof" or similar tools (that can list open
> files and sockets) how many files and sockets fetchmail holds open
> at the time when the problems start? It might be that the OS itself
> is leaking sockets here which might appear in fetchmail's address
> space.
I don't think there's a problem, but I will test it anyway and report
as soon as I'll find time for another forced network outage.
>> So I'm quite sure that's the bug: Care must be taken that
>> freeaddrinfo() is called even if SockOpen() is interrupted by a
>> timeout.
>
> Certainly, and to avoid leaking memory on disconnected computers
> would be reason enough to justify such a fix.
Maybe it's a good idea to check for all occurrences of freeaddrinfo()
whether they are certain to be performed whenever they should.
Glimpsing at the code, e.g. in servport.c, line 65, the default
switch condition is a goto jump that prevents freeaddrinfo() from
being called, although it should be called (getaddrinfo() had
returned 0/success before, so "res" had been allocated). It seems
that calling freeaddrinfo() was not taken all too seriously
throughout fetchmail.
>> So you must either make ai0 a global variable (which won't work if
>> you plan to make fetchmail open more than one socket
>> simultaneously), or declare it in the calling code (driver.c or
>> whatever) and pass it to SockOpen.
>
> "you'll have to" or "you may have to" sounds more polite than "you
> must" (no offense taken, don't worry).
Well, the force of the laws of logic isn't polite ... ;-) (This was
not meant to be a social "must" but rather a logical one, as I indeed
see no other programming techniques to deal with that issue.)
> Bugs related to signal handling (which is used for timeout
> handling) require extra care. I myself will have to review the code
> again before making changes in that area.
> [...]
> I don't think I'll be able to handle this before Saturday, perhaps
> Sunday; but providing patches for you to test should be feasible.
Well, that's more than OK with me! If you deal with bugs in
connection with Mac OS X, what you are afraid of are months or years
until a fix is applied - days are no problem at all. :-)
> Note that I don't have MacOS X machines to test on either.
No problem, I can test this here.
> Thank you!
Well, thank you (in advance) for the fix! :-)
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Dave P. <sd...@gm...> - 2006-06-28 04:01:11
|
* Matthias Andree <mat...@gm...> [2006-06-28 02:53:30 +0200]: > Hang on - this means that fetchmail was utterly confused because it > couldn't open the literal ~ directory? And handle --version improperly? > Looks a bit odd -- and --nodetach is supposed to override --logfile > <scratches head> > Oh. I was thinking that it tried to write to syslog (which I don't allow userspace to do) first, and reporting instead went to /dev/null due to system config. Let me play with a couple settings here and I'll get back to list. -- Cheers, Dave |
|
From: Matthias A. <mat...@gm...> - 2006-06-28 02:53:35
|
Dave Patterson <sd...@gm...> writes: > * Rob MacGregor <rob...@gm...> [2006-06-26 17:57:10 +0100]: > >> On 6/26/06, Dave Patterson <sd...@gm...> wrote: >> > >> >Contents of .fetchmailrc : >> > >> ><cut> >> > >> >set syslog >> >set logfile=~/.fetchmaillog >> > Removed 'set syslog', edited 'set logfile' line to read: > > set logfile = /home/dave/.fetchmaillog > > All good now. Thanks for your time. I'll go crawl back under my rock. Hang on - this means that fetchmail was utterly confused because it couldn't open the literal ~ directory? And handle --version improperly? Looks a bit odd -- and --nodetach is supposed to override --logfile <scratches head> I think I'll play with this a bit more before 6.3.5 and see if there's something to make fetchmail better behaved. I've put this onto my TODO.txt. Thanks for sharing the details! -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-06-28 02:46:54
|
Uli Zappe <ul...@ri...> writes: > When getaddrinfo() is called while the Internet is down, it may take > quite some time until it returns the respective error. Now, if the > "timeout" variable in fetchmail is set to a value shorter than this > time that getaddrinfo() needs, a call to SockOpen() (socket.c, line > 266) from (at least) line 1053 in driver.c will be interrupted by the > timeout signal handler. In this situation, freeaddrinfo() (line 311 in > socket.c) will never be called to close ai0 correctly. This, in turn, > seems to produce the corrupted behavior of future getaddrinfo() calls > (at least in Mac OS X's implementation). I haven't yet investigated all details, but your research looks valuable and plausible, thank you! While I'll certainly plug the leak (it may take until the week-end though), there might still be a related MacOS X bug. There is no obligation to call freeaddrinfo() before calling getaddrinfo() again, plus this function is required to be thread-safe (i. e. it needs to be reentrant). However, you say that the problems happen after a certain... > In my test case, getaddrinfo() may need up to 180s to time out. However, > I had set fetchmail's "timeout" parameter to only 60s. In my tests, > during the time when the Internet connection was down, at least one > "timeout after 60 seconds waiting to connect to server xy" did indeed > appear in the log for each server. ...amount of time. Can you check with "lsof" or similar tools (that can list open files and sockets) how many files and sockets fetchmail holds open at the time when the problems start? It might be that the OS itself is leaking sockets here which might appear in fetchmail's address space. > I have now set fetchmail's "timeout" variable to 6000 and repeated my > tests. No timeout message occurred, and after the Internet connection > was up again, fetchmail resumed fetching mails just as it should. > > So I'm quite sure that's the bug: Care must be taken that freeaddrinfo > () is called even if SockOpen() is interrupted by a timeout. Certainly, and to avoid leaking memory on disconnected computers would be reason enough to justify such a fix. > So you must either make ai0 a global variable (which won't work if you > plan to make fetchmail open more than one socket simultaneously), or > declare it in the calling code (driver.c or whatever) and pass it to > SockOpen. "you'll have to" or "you may have to" sounds more polite than "you must" (no offense taken, don't worry). > My question now is how to proceed. Since you definitely know fetchmail's > code much better than I do, it would make sense that you fix the bug in > all places where it might occur. Bugs related to signal handling (which is used for timeout handling) require extra care. I myself will have to review the code again before making changes in that area. > However, since the bug is crucial at least for me, I'd need a fix > soon. So do you think you will come up with a fix in a short amount of > time, of should I provide a fix temporarily (but I will probably > overlook some of the situations where this bug might possibly occur - > so far I'm only aware of driver.c line 1053 calling SockOpen())? I don't think I'll be able to handle this before Saturday, perhaps Sunday; but providing patches for you to test should be feasible. Note that I don't have MacOS X machines to test on either. Thank you! -- Matthias Andree |
|
From: Uli Z. <ul...@ri...> - 2006-06-27 14:57:35
|
Am 27.06.2006 um 05:12 schrieb Uli Zappe:
> The only explanation for this is that fetchmail somehow manages to
> do something to the servers it calls that corrupts future
> getaddrinfo() results for these (and only these) servers. Just what
> that could possibly be, I have no idea.
After further inspection af the code and further testing, it seems I
have found this "something":
When getaddrinfo() is called while the Internet is down, it may take
quite some time until it returns the respective error. Now, if the
"timeout" variable in fetchmail is set to a value shorter than this
time that getaddrinfo() needs, a call to SockOpen() (socket.c, line
266) from (at least) line 1053 in driver.c will be interrupted by the
timeout signal handler. In this situation, freeaddrinfo() (line 311
in socket.c) will never be called to close ai0 correctly. This, in
turn, seems to produce the corrupted behavior of future getaddrinfo()
calls (at least in Mac OS X's implementation).
In my test case, getaddrinfo() may need up to 180s to time out.
However, I had set fetchmail's "timeout" parameter to only 60s. In my
tests, during the time when the Internet connection was down, at
least one "timeout after 60 seconds waiting to connect to server xy"
did indeed appear in the log for each server.
I have now set fetchmail's "timeout" variable to 6000 and repeated my
tests. No timeout message occurred, and after the Internet connection
was up again, fetchmail resumed fetching mails just as it should.
So I'm quite sure that's the bug: Care must be taken that freeaddrinfo
() is called even if SockOpen() is interrupted by a timeout. So you
must either make ai0 a global variable (which won't work if you plan
to make fetchmail open more than one socket simultaneously), or
declare it in the calling code (driver.c or whatever) and pass it to
SockOpen.
My question now is how to proceed. Since you definitely know
fetchmail's code much better than I do, it would make sense that you
fix the bug in all places where it might occur. However, since the
bug is crucial at least for me, I'd need a fix soon. So do you think
you will come up with a fix in a short amount of time, of should I
provide a fix temporarily (but I will probably overlook some of the
situations where this bug might possibly occur - so far I'm only
aware of driver.c line 1053 calling SockOpen())?
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Dave P. <sd...@gm...> - 2006-06-27 05:38:02
|
* Rob MacGregor <rob...@gm...> [2006-06-26 17:57:10 +0100]: > On 6/26/06, Dave Patterson <sd...@gm...> wrote: > > > >Contents of .fetchmailrc : > > > ><cut> > > > >set syslog > >set logfile=~/.fetchmaillog > Removed 'set syslog', edited 'set logfile' line to read: set logfile = /home/dave/.fetchmaillog All good now. Thanks for your time. I'll go crawl back under my rock. -- Cheers, Dave |
|
From: Uli Z. <ul...@ri...> - 2006-06-27 05:13:06
|
Hi,
I'm encountering the following bug in fetchmail (versions from at
least 6.2.5 up to 6.3.4) running in daemon mode on Mac OS X (versions
from at least 10.4.2 up to 10.4.7) with a 60s poll interval.
Usually, daemon mode works just fine. If the Internet connection goes
down for whatever reason, fetchmail will produce a SOCKET error ("No
address associated with nodename"), as you would expect. If the
Internet connection comes up again after a "short" amount of time,
fetchmail will resume fetching mails as it should. However, if the
Internet connection is down for a "longer" amount of time, fetchmail
will keep reporting the same SOCKET errors if the Internet connection
is finally up again, and never resume fetching mails until it is
restarted (then everything works just fine again). I can't give an
exact number for "longer", it can be everything from 15 to 90 minutes
it seems (after 90 minutes, the issue *always* occurs, but sometimes
it already occurs after 15 minutes).
Obviously, this makes using fetchmail in daemon mode highly
unreliable as far as timely delivery of mails is concerned, and more
or less unusable.
The issue is obviously tied to the the output of getaddrinfo(). If
the issue occurs, it is because getaddrinfo() erroneously keeps
returning the respective error after the the Internet connection is
up again. At first I thought that this may be a bug in Mac OS X's
getaddrinfo() implementation. However, no such bug was known, so I
performed the following test myself (with extremely weird results):
At the beginning of fetchmail's daemon loop (after line 590 in
fetchmail.c (of 6.3.4)) I inserted the following test code:
struct addrinfo *ai, req;
int gaiRes;
memset(&req, 0, sizeof(struct addrinfo));
req.ai_socktype = SOCK_STREAM;
if (gaiRes=getaddrinfo("pop.1und1.com", "pop3s", &req, &ai))
{
report(stdout, GT_("GAI: 1und1: ERROR: %s\n"), gai_strerror(gaiRes));
}
else
{
freeaddrinfo(ai);
report(stdout, GT_("GAI: 1und1: OK\n"));
}
This is a code snippet basically taken from socket.c where the actual
SOCKET error occurs. The queried host is one of the hosts I actually
use with fetchmail. I repeated this code a second time for another
host I actually use ("popmail.server.uni-frankfurt.de", "pop3s"), and
a third time, as a comparison, for Apple's web server
("www.apple.com", "http").
Then I took *exactly* this code (well, apart from replacing "report"
by "printf") I inserted at the beginning of the fetchmail loop and
put it in an endless loop (with 60s sleep after each loop) in a stand-
alone Unix program.
Finally, I ran fetchmail in daemon mode and the test Unix program
simultaneously (both as root), disrupted the Internet connection and
looked what happened.
The really strange results are:
1. As long as the Internet connection is up, both programs (fetchmail
and my test program) report "OK" for all three servers, as you would
expect.
2. When the Internet connection goes down, for one server after
another, a "No address associated with nodename" is displayed. The
time it takes until this error shows up differs for the three servers
(some caching issue, I suppose); however, it is synchronous on both
programs (as soon as it is displayed on one program, it's also
displayed on the other). Again, kind of what you would expect.
3. Now it gets weird. If the Internet connection comes up again, my
test program immediately displays "OK" again for all three servers -
that's how it should be. fetchmail, however, displays only "OK" for
the Apple server; the two pop servers - that fetchmail actually works
with in its code - keep displaying the "No address associated with
nodename" error, which at least is consistent with the error messages
in fetchmail's own code.
So to sum up:
Exactly the same getaddrinfo() code in fetchmail and a test program,
run every 60s, produces exactly the same results for a server that
otherwise is not called in fetchmail's original code, but different
results for the two servers that are actually called in fetchmail's
original code. In the latter case, the test program works as it
should (no errors after the Internet connection is up again), while
fetchmail does not work as it should (errors although the Internet is
up again).
The only explanation for this is that fetchmail somehow manages to do
something to the servers it calls that corrupts future getaddrinfo()
results for these (and only these) servers. Just what that could
possibly be, I have no idea.
Also, I have no way of knowing if this is only the case in connection
with Mac OS X's getaddrinfo() implementation (I only have Macs here).
My test program shows that Mac OS X's getaddrinfo() works fine under
"normal" conditions, though.
So I guess the first thing to find out is if this bug is reproducible
on other Unix systems, and then proceed from there.
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Dave P. <sd...@gm...> - 2006-06-27 02:48:52
|
* Rob MacGregor <rob...@gm...> [2006-06-26 17:57:10 +0100]: > So, what's in that logfile? > dave@davescrunch:~$ cat .fetchmaillog dave@davescrunch:~$ -- Cheers, Dave |
|
From: Rob M. <rob...@gm...> - 2006-06-26 18:57:11
|
On 6/26/06, Dave Patterson <sd...@gm...> wrote:
>
> Contents of .fetchmailrc :
>
> <cut>
>
> set syslog
> set logfile=~/.fetchmaillog
So, what's in that logfile?
--
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: Dave P. <sd...@gm...> - 2006-06-26 17:49:20
|
* Rob MacGregor <rob...@gm...> [2006-06-26 10:12:26 +0100]:
> Version of fetchmail?
>
Debian's fetchmail package # 6.3.4-1
('fetchmail -V' or fetchmail --version' results in fetchmail retrieving mail and passing it to Procmail, but the version request is ignored - interesting)
>
> Any command line arguments passed to fetchmail (and what are they)?
>
Command line arguments thus far have been '-V' '--version' '--nodetach
--nosyslog' '-v'
Contents of .fetchmailrc :
<cut>
set syslog
set logfile=~/.fetchmaillog
poll pop.gmail.com with proto POP3 and options no dns
user 'XX...@gm...' with pass "XXX" is 'dave' here options
ssl
mda '/usr/bin/procmail -d %T'
poll pop.mail.yahoo.com with protocol pop3,
user XXX there is dave here,
with password XXX;
mda '/usr/bin/procmail -d %T'
poll net1.ji-net.com with protocol pop3,
user XXX there is dave here,
with password XXX;
mda '/usr/bin/procmail -d %T'
poll 127.0.0.1 port 110 with protocol pop3,
user 'XXX' with pass "XXX" is
'dave' here,
mda '/usr/bin/procmail -d %T
<cut>
Hmmm..
Cheers, Dave
|
|
From: Matthias A. <mat...@gm...> - 2006-06-26 12:32:05
|
Dave Patterson <sd...@gm...> writes: > * Matthias Andree <mat...@gm...> [2006-06-26 09:38:17 +0200]: > > >> Add --nodetach --nosyslog to the command line. >> > No luck. >> Otherwise, syslog (/var/log/mail, /var/log/maillog, or thereabouts). >> > None there, either... --logfile (or set logfile) used? -- Matthias Andree |
18 messages has been excluded from this view by a project administrator.
