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: Martin S. <mar...@in...> - 2005-08-31 19:50:59
|
Hello, I'm running fetchmail 6.2.5 version of fetchmail from Debian Etch package. I noticed that the daemon fails retrieving IMAP mails after a certain time. I launch fetchmail as daemon with the init.d script provided by debian. To analyse the problem, I added -v option, and here is the full log illustrating the problem. It is quite long but quite clear too. I'm running Exim 4, procmail, courier imap. 3 polls are configures, POP3, IMAP4 + SSL, IMAP4 here everything's ok: Aug 30 00:51:49 localhost fetchmail[2498]: awakened at Tue Aug 30 00:51:49 2005 Aug 30 00:51:49 localhost fetchmail[2498]: 6.2.5 querying pop3.evhr.net (protocol POP3) at Tue Aug 30 00:51:49 2005: poll started Aug 30 00:51:49 localhost imaplogin: LOGOUT, user=martin, ip=[::ffff:62.129.161.22], headers=0, body=0, time=0 Aug 30 00:51:49 localhost last message repeated 2 times Aug 30 00:51:49 localhost fetchmail[2498]: POP3< +OK POP3 Ready pop.evc.net 0001d8f1 Aug 30 00:51:49 localhost fetchmail[2498]: POP3> CAPA Aug 30 00:51:49 localhost fetchmail[2498]: POP3< +OK Capability list follows, mate Aug 30 00:51:49 localhost fetchmail[2498]: POP3< UIDL Aug 30 00:51:49 localhost fetchmail[2498]: POP3< USER Aug 30 00:51:49 localhost fetchmail[2498]: POP3< . Aug 30 00:51:49 localhost fetchmail[2498]: POP3> USER evhr_mart Aug 30 00:51:49 localhost fetchmail[2498]: POP3< +OK USER evhr_mart set, mate Aug 30 00:51:49 localhost fetchmail[2498]: POP3> PASS * Aug 30 00:51:49 localhost fetchmail[2498]: POP3< +OK You are so in Aug 30 00:51:52 localhost fetchmail[2498]: POP3> STAT Aug 30 00:51:52 localhost fetchmail[2498]: POP3< +OK 0 0 Aug 30 00:51:52 localhost fetchmail[2498]: No mail for evhr_mart at pop3.evhr.net Aug 30 00:51:52 localhost fetchmail[2498]: POP3> QUIT Aug 30 00:51:52 localhost fetchmail[2498]: POP3< +OK Done Aug 30 00:51:52 localhost fetchmail[2498]: 6.2.5 querying pop3.evhr.net (protocol POP3) at Tue Aug 30 00:51:52 2005: poll completed Aug 30 00:51:52 localhost fetchmail[2498]: 6.2.5 querying imap4.orange.fr (protocol IMAP) at Tue Aug 30 00:51:52 2005: poll started Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * OK IMAP4 server ready (6.7.015) Aug 30 00:51:52 localhost fetchmail[2498]: IMAP> A0001 CAPABILITY Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * CAPABILITY IMAP4rev1 UIDPLUS IDLE LOGIN-REFERRALS NAMESPACE QUOTA CHILDREN AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< A0001 OK capabilities listed Aug 30 00:51:52 localhost fetchmail[2498]: IMAP> A0002 AUTHENTICATE CRAM-MD5 Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< + PEExM0JBNTNGRjVBRkNGNUFFMkQwRjE4ODE3NDY3QzkxRkVCOENCMjFAcG9wMS5vcmFuZ2UuZnI+ Aug 30 00:51:52 localhost fetchmail[2498]: IMAP> bWFydC5zY2ggYjE0OTc1OTU2MGI4MzIwMmEwY2FmZmU1NWExZWVjNGY= Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< A0002 OK login successful Aug 30 00:51:52 localhost fetchmail[2498]: IMAP> A0003 SELECT "INBOX" Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * 1 EXISTS Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * 0 RECENT Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent) Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent)] flags can be changed Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * OK [UIDVALIDITY 1055529069] mailbox UID validity Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * OK [UIDNEXT 5194] predicted next UID Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< A0003 OK [READ-WRITE] SELECT complete Aug 30 00:51:52 localhost fetchmail[2498]: IMAP> A0004 EXPUNGE Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< A0004 OK EXPUNGE complete Aug 30 00:51:52 localhost fetchmail[2498]: IMAP> A0005 SEARCH UNSEEN NOT DELETED Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * SEARCH Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< A0005 OK SEARCH complete Aug 30 00:51:52 localhost fetchmail[2498]: 1 message (1 seen) for mart.sch at imap4.orange.fr. Aug 30 00:51:52 localhost fetchmail[2498]: skipping message mar...@im...:1 not flushed Aug 30 00:51:52 localhost fetchmail[2498]: IMAP> A0006 LOGOUT Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< * BYE disconnecting Aug 30 00:51:52 localhost fetchmail[2498]: IMAP< A0006 OK LOGOUT complete Aug 30 00:51:52 localhost fetchmail[2498]: 6.2.5 querying imap4.orange.fr (protocol IMAP) at Tue Aug 30 00:51:52 2005: poll completed Aug 30 00:51:52 localhost fetchmail[2498]: 6.2.5 querying mail.insa-lyon.fr (protocol IMAP) at Tue Aug 30 00:51:52 2005: poll started Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * OK csiges9.insa-lyon.fr Cyrus IMAP4 v2.2.12-INSA-LYON server ready Aug 30 00:51:53 localhost fetchmail[2498]: IMAP> A0001 CAPABILITY Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS LISTEXT LIST-SUBSCRIBED X-NETSCAPE Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< A0001 OK Completed Aug 30 00:51:53 localhost fetchmail[2498]: IMAP> A0002 STARTTLS Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< A0002 OK Begin TLS negotiation now Aug 30 00:51:53 localhost fetchmail[2498]: Issuer Organization: INSA Lyon Aug 30 00:51:53 localhost fetchmail[2498]: Issuer CommonName: mail.insa-lyon.fr Aug 30 00:51:53 localhost fetchmail[2498]: Server CommonName: mail.insa-lyon.fr Aug 30 00:51:53 localhost fetchmail[2498]: mail.insa-lyon.fr key fingerprint: 31:D9:BD:88:82:75:B4:92:62:0E:BB:CC:97:7C:2D:3B Aug 30 00:51:53 localhost fetchmail[2498]: Warning: server certificate verification: self signed certificate Aug 30 00:51:53 localhost fetchmail[2498]: Issuer Organization: INSA Lyon Aug 30 00:51:53 localhost fetchmail[2498]: Issuer CommonName: mail.insa-lyon.fr Aug 30 00:51:53 localhost fetchmail[2498]: Server CommonName: mail.insa-lyon.fr Aug 30 00:51:53 localhost fetchmail[2498]: Warning: server certificate verification: self signed certificate Aug 30 00:51:53 localhost fetchmail[2498]: IMAP> A0003 CAPABILITY Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE AUTH=PLAIN SASL-IR LISTEXT LIST-SUBSCRIBED X-NETSCAPE Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< A0003 OK Completed Aug 30 00:51:53 localhost fetchmail[2498]: IMAP> A0004 LOGIN "mschlienger" * Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< A0004 OK User logged in Aug 30 00:51:53 localhost fetchmail[2498]: IMAP> A0005 SELECT "INBOX" Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * 0 EXISTS Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * 0 RECENT Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * OK [UIDVALIDITY 1094806947] Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * OK [UIDNEXT 1215] Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< A0005 OK [READ-WRITE] Completed Aug 30 00:51:53 localhost fetchmail[2498]: No mail for mschlienger at mail.insa-lyon.fr Aug 30 00:51:53 localhost fetchmail[2498]: IMAP> A0006 LOGOUT Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< * BYE LOGOUT received Aug 30 00:51:53 localhost fetchmail[2498]: IMAP< A0006 OK Completed Aug 30 00:51:53 localhost fetchmail[2498]: 6.2.5 querying mail.insa-lyon.fr (protocol IMAP) at Tue Aug 30 00:51:53 2005: poll completed Aug 30 00:51:53 localhost fetchmail[2498]: sleeping at Tue Aug 30 00:51:53 2005 This check was successful. 5 minutes later... Aug 30 00:56:53 localhost fetchmail[2498]: awakened at Tue Aug 30 00:56:53 2005 Aug 30 00:56:53 localhost fetchmail[2498]: 6.2.5 querying pop3.evhr.net (protocol POP3) at Tue Aug 30 00:56:53 2005: poll started Aug 30 00:56:53 localhost fetchmail[2498]: POP3< +OK POP3 Ready pop.evc.net 0001d8f1 Aug 30 00:56:53 localhost fetchmail[2498]: POP3> CAPA Aug 30 00:56:53 localhost fetchmail[2498]: POP3< +OK Capability list follows, mate Aug 30 00:56:53 localhost fetchmail[2498]: POP3< UIDL Aug 30 00:56:53 localhost fetchmail[2498]: POP3< USER Aug 30 00:56:53 localhost fetchmail[2498]: POP3< . Aug 30 00:56:53 localhost fetchmail[2498]: POP3> USER evhr_mart Aug 30 00:56:53 localhost fetchmail[2498]: POP3< +OK USER evhr_mart set, mate Aug 30 00:56:53 localhost fetchmail[2498]: POP3> PASS * Aug 30 00:56:53 localhost fetchmail[2498]: POP3< +OK You are so in Aug 30 00:56:56 localhost fetchmail[2498]: POP3> STAT Aug 30 00:56:56 localhost fetchmail[2498]: POP3< +OK 0 0 Aug 30 00:56:56 localhost fetchmail[2498]: No mail for evhr_mart at pop3.evhr.net Aug 30 00:56:56 localhost fetchmail[2498]: POP3> QUIT Aug 30 00:56:56 localhost fetchmail[2498]: POP3< +OK Done Aug 30 00:56:56 localhost fetchmail[2498]: 6.2.5 querying pop3.evhr.net (protocol POP3) at Tue Aug 30 00:56:56 2005: poll completed Aug 30 00:56:56 localhost fetchmail[2498]: 6.2.5 querying imap4.orange.fr (protocol IMAP) at Tue Aug 30 00:56:56 2005: poll started Aug 30 00:56:56 localhost fetchmail[2498]: IMAP< * OK IMAP4 server ready (6.7.015) Aug 30 00:56:56 localhost fetchmail[2498]: IMAP> A0001 CAPABILITY Aug 30 00:56:56 localhost fetchmail[2498]: IMAP< * CAPABILITY IMAP4rev1 UIDPLUS IDLE LOGIN-REFERRALS NAMESPACE QUOTA CHILDREN AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN Aug 30 00:56:56 localhost fetchmail[2498]: IMAP< A0001 OK capabilities listed Aug 30 00:56:56 localhost fetchmail[2498]: IMAP> A0002 AUTHENTICATE CRAM-MD5 Aug 30 00:56:56 localhost fetchmail[2498]: IMAP< + PEZCRjkyMEExNDlFQzlBRTEwRjU4MzY0RjY0ODE0RENFOUY0RDFFMzhAcG9wMS5vcmFuZ2UuZnI+ Aug 30 00:56:56 localhost fetchmail[2498]: IMAP> bWFydC5zY2ggNGE5MzA2NDNhZWEzZjA1ZTJhY2Y3OWVjODE3NWZkNGQ= Here comes a timeout on one IMAP Server. Then every IMAP check doesn't work on both server. Aug 30 01:01:56 localhost fetchmail[2498]: timeout after 300 seconds waiting for server imap4.orange.fr. Aug 30 01:01:56 localhost fetchmail[2498]: socket error while fetching from imap4.orange.fr Aug 30 01:01:56 localhost fetchmail[2498]: 6.2.5 querying imap4.orange.fr (protocol IMAP) at Tue Aug 30 01:01:56 2005: poll completed Aug 30 01:01:56 localhost fetchmail[2498]: Query status=2 (SOCKET) Failure on next IMAP Server. Aug 30 01:01:56 localhost fetchmail[2498]: 6.2.5 querying mail.insa-lyon.fr (protocol IMAP) at Tue Aug 30 01:01:56 2005: poll started Aug 30 01:01:56 localhost fetchmail[2498]: IMAP< * OK csiges9.insa-lyon.fr Cyrus IMAP4 v2.2.12-INSA-LYON server ready Aug 30 01:01:56 localhost fetchmail[2498]: IMAP> CAPABILITY Aug 30 01:01:56 localhost fetchmail[2498]: IMAP< * BAD Invalid tag Aug 30 01:01:56 localhost fetchmail[2498]: IMAP> LOGIN "mschlienger" * Aug 30 01:01:56 localhost fetchmail[2498]: IMAP< LOGIN BAD Null command Aug 30 01:01:56 localhost fetchmail[2498]: IMAP> SELECT "INBOX" Aug 30 01:01:56 localhost fetchmail[2498]: IMAP< SELECT BAD Null command Aug 30 01:01:56 localhost fetchmail[2498]: No mail for mschlienger at mail.insa-lyon.fr Aug 30 01:01:56 localhost fetchmail[2498]: IMAP> LOGOUT Aug 30 01:01:57 localhost fetchmail[2498]: IMAP< * BAD Invalid tag Aug 30 01:01:57 localhost fetchmail[2498]: 6.2.5 querying mail.insa-lyon.fr (protocol IMAP) at Tue Aug 30 01:01:57 2005: poll completed Aug 30 01:01:57 localhost fetchmail[2498]: sleeping at Tue Aug 30 01:01:57 2005 Next poll checks: every IMAP fails indefinitely... Aug 30 01:06:57 localhost fetchmail[2498]: awakened at Tue Aug 30 01:06:57 2005 Aug 30 01:06:57 localhost fetchmail[2498]: 6.2.5 querying pop3.evhr.net (protocol POP3) at Tue Aug 30 01:06:57 2005: poll started Aug 30 01:06:57 localhost fetchmail[2498]: POP3< +OK POP3 Ready pop.evc.net 0001d8f1 Aug 30 01:06:57 localhost fetchmail[2498]: POP3> CAPA Aug 30 01:06:57 localhost fetchmail[2498]: POP3< +OK Capability list follows, mate Aug 30 01:06:57 localhost fetchmail[2498]: POP3< UIDL Aug 30 01:06:57 localhost fetchmail[2498]: POP3< USER Aug 30 01:06:57 localhost fetchmail[2498]: POP3< . Aug 30 01:06:57 localhost fetchmail[2498]: POP3> USER evhr_mart Aug 30 01:06:57 localhost fetchmail[2498]: POP3< +OK USER evhr_mart set, mate Aug 30 01:06:57 localhost fetchmail[2498]: POP3> PASS * Aug 30 01:06:57 localhost fetchmail[2498]: POP3< +OK You are so in Aug 30 01:07:00 localhost fetchmail[2498]: POP3> STAT Aug 30 01:07:00 localhost fetchmail[2498]: POP3< +OK 0 0 Aug 30 01:07:00 localhost fetchmail[2498]: No mail for evhr_mart at pop3.evhr.net Aug 30 01:07:00 localhost fetchmail[2498]: POP3> QUIT Aug 30 01:07:00 localhost fetchmail[2498]: POP3< +OK Done Aug 30 01:07:00 localhost fetchmail[2498]: 6.2.5 querying pop3.evhr.net (protocol POP3) at Tue Aug 30 01:07:00 2005: poll completed Aug 30 01:07:00 localhost fetchmail[2498]: 6.2.5 querying imap4.orange.fr (protocol IMAP) at Tue Aug 30 01:07:00 2005: poll started Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< * OK IMAP4 server ready (6.7.015) Aug 30 01:07:00 localhost fetchmail[2498]: IMAP> CAPABILITY Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< CAPABILITY BAD no space between tag and command Aug 30 01:07:00 localhost fetchmail[2498]: IMAP> LOGIN "mart.sch" * Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< LOGIN BAD unrecognized IMAP4 command Aug 30 01:07:00 localhost fetchmail[2498]: IMAP> SELECT "INBOX" Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< SELECT BAD unrecognized IMAP4 command Aug 30 01:07:00 localhost fetchmail[2498]: No mail for mart.sch at imap4.orange.fr Aug 30 01:07:00 localhost fetchmail[2498]: IMAP> LOGOUT Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< LOGOUT BAD no space between tag and command Aug 30 01:07:00 localhost fetchmail[2498]: 6.2.5 querying imap4.orange.fr (protocol IMAP) at Tue Aug 30 01:07:00 2005: poll completed Aug 30 01:07:00 localhost fetchmail[2498]: 6.2.5 querying mail.insa-lyon.fr (protocol IMAP) at Tue Aug 30 01:07:00 2005: poll started Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< * OK csiges9.insa-lyon.fr Cyrus IMAP4 v2.2.12-INSA-LYON server ready Aug 30 01:07:00 localhost fetchmail[2498]: IMAP> CAPABILITY Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< * BAD Invalid tag Aug 30 01:07:00 localhost fetchmail[2498]: IMAP> LOGIN "mschlienger" * Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< LOGIN BAD Null command Aug 30 01:07:00 localhost fetchmail[2498]: IMAP> SELECT "INBOX" Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< SELECT BAD Null command Aug 30 01:07:00 localhost fetchmail[2498]: No mail for mschlienger at mail.insa-lyon.fr Aug 30 01:07:00 localhost fetchmail[2498]: IMAP> LOGOUT Aug 30 01:07:00 localhost fetchmail[2498]: IMAP< * BAD Invalid tag Aug 30 01:07:00 localhost fetchmail[2498]: 6.2.5 querying mail.insa-lyon.fr (protocol IMAP) at Tue Aug 30 01:07:00 2005: poll completed Aug 30 01:07:00 localhost fetchmail[2498]: sleeping at Tue Aug 30 01:07:00 2005 Thanks for any help! regards, martin. |
|
From: Matthias A. <mat...@gm...> - 2005-08-28 17:47:26
|
Greetings, I have just released fetchmail 6.2.9-rc2, another release candidate for 6.3.0. The IPv6 protocol support turned out to be rather intrusive, and as a side effect may have harmed domain alias detection for multidrop, the --monitor or --interface option and other systems I am not using. I seek everyone to test it out, report remaining bugs (I know that the IPv6 support is still not 100% complete), update outdated translations or send patches for documentation. The release notes are available at: <http://developer.berlios.de/project/shownotes.php?group_id=1824&release_id=7035> The software is available from: <http://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=7035> <http://home.pages.de/~mandree/fetchmail/> ----------------------------------------------------------------------- Fetchmail needs your support - please consider a donation via: <https://developer.berlios.de/developer/make_donation.php?user_id=2007> ----------------------------------------------------------------------- Regards, -- Matthias Andree |
|
From: Rob M. <rob...@gm...> - 2005-08-25 18:29:33
|
On 25/08/05, Raffael Schmid <fet...@yu...> wrote:
> Hi,
>
> First I want to excuse me for my bad English, I'm from Switzerland...
>
> I set up a Mailserver, using fetchmail, postfix, amavisd-new, cyrus.
>
> I fetch the mails with fetchmail, and "send" them to postfix.
>
> But the mails are empty! No subject, no body.
> When I send the mails to the Server with a client, the Mails are ok.
>
> I've spent a lot of time now...
>
> What's wrong?
What's wrong is that you've not provided any real information.
Let's start with:
1) Version of fetchmail and contents of .fetchmailrc
2) Output of "fetchmail -v -v" for a problem email
3) Contents of your postfix and cyrus logs for the same email
4) Full header and body of same email, before being passed through
fetchmail and once it's been received by postfix
5) Whether the problem occurs when amavisd-new is not being used
6) Whether or not fetchmail is running on the same host as postfix (I assume so)
7) Does the problem occur if you send a mail, using the command line,
on the postfix server
--
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: Raffael S. <fet...@yu...> - 2005-08-25 17:39:44
|
Hi, First I want to excuse me for my bad English, I'm from Switzerland... I set up a Mailserver, using fetchmail, postfix, amavisd-new, cyrus. I fetch the mails with fetchmail, and "send" them to postfix. But the mails are empty! No subject, no body. When I send the mails to the Server with a client, the Mails are ok. I've spent a lot of time now... What's wrong? greetings rs |
|
From: Matthias A. <mat...@gm...> - 2005-08-25 15:45:48
|
Greetings, I have just released fetchmail 6.2.9-rc1, a release candidate for 6.3.0. I seek everyone to test it out, report remaining bugs (I know that the IPv6 support is still not 100% complete), update outdated translations or send patches for documentation. The release notes are available at: <http://developer.berlios.de/project/shownotes.php?group_id=1824&release_id=7010> The software is available from: <http://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=7010> <http://home.pages.de/~mandree/fetchmail/> If you like fetchmail, and wish to show your appreciation of my maintaining fetchmail, consider donating to me via <https://developer.berlios.de/developer/make_donation.php?user_id=2007> Regards, -- Matthias Andree |
|
From: Ray W. <ray...@in...> - 2005-08-20 06:17:10
|
On Fri, Aug 19, 2005 at 07:15:40PM -0400, Charles Levert wrote: > * On Wednesday 2005-08-17 at 04:03:41 -0500, Ray Warren wrote: > > On Tue, Aug 16, 2005 at 04:07:01AM -0400, Charles Levert wrote: > > > > > Can you tell me if your more recent Konqueror > > > is more standard-compliant than mine? Also, > > > is Opera (which I don't have)? > > > > You can get a copy without a cash outlay if you can deal with a thin > > advertising bar at the top.It is rated as being very standard compliant. > > I downloaded Opera 8.02 and it gets this right; > my question was specific to this very issue, > not about standard compliance in general. Possibly I was not clear in describing where the problem showed up.It was not the initial display,but after i zoomed in to enlarge the text enough that I could read it. > > Can you still tell me about Konqueror 3.2.3, > with respect to this very issue? > > > > > > > > <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> > > > > This link is not working for me tonight but a horizontal scrollbar would > > alleviate my biggest problem. > > Very strange. This is on the public internet. > The site has not reported any down time in quite a while. I tried again a few minutes ago and the scroll bar that popped up when I zoomed in did allow me to view the entire line at a size I could read > > > > As long as you can somehow view the content > > > (i.e., the page at least loads), then this > > > > The problem is that at least part of the content is not available.It > > disappeared off the right side of the window. > > You mentioned having tried Mozilla and Opera. > These have no problem displaying the whole content > with a horizontal scrollbar for the whole page. I have never had a horizontal scroll bar for the whole page on any of the three browsers,and still do not. > This very much qualifies as "available", > albeit with a minor annoyance, > which you can fix by adding > > overflow: auto; > > to the pre {} block of the embedded style sheet. > > Should I post a patch for this one-liner? > Should I repost the whole document with just this change? The change you have already made is adequate for me to view the document, and it looks interesting,it will be later this weekend before I have time to study it. Ray Warren |
|
From: Charles L. <cha...@gm...> - 2005-08-20 01:15:48
|
* On Wednesday 2005-08-17 at 04:03:41 -0500, Ray Warren wrote: > On Tue, Aug 16, 2005 at 04:07:01AM -0400, Charles Levert wrote: > > > Can you tell me if your more recent Konqueror > > is more standard-compliant than mine? Also, > > is Opera (which I don't have)? > > You can get a copy without a cash outlay if you can deal with a thin > advertising bar at the top.It is rated as being very standard compliant. I downloaded Opera 8.02 and it gets this right; my question was specific to this very issue, not about standard compliance in general. Can you still tell me about Konqueror 3.2.3, with respect to this very issue? > > > > <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> > > This link is not working for me tonight but a horizontal scrollbar would > alleviate my biggest problem. Very strange. This is on the public internet. The site has not reported any down time in quite a while. > > As long as you can somehow view the content > > (i.e., the page at least loads), then this > > The problem is that at least part of the content is not available.It > disappeared off the right side of the window. You mentioned having tried Mozilla and Opera. These have no problem displaying the whole content with a horizontal scrollbar for the whole page. This very much qualifies as "available", albeit with a minor annoyance, which you can fix by adding overflow: auto; to the pre {} block of the embedded style sheet. Should I post a patch for this one-liner? Should I repost the whole document with just this change? |
|
From: Ray W. <ray...@in...> - 2005-08-17 11:03:43
|
On Tue, Aug 16, 2005 at 04:07:01AM -0400, Charles Levert wrote: > * On Tuesday 2005-08-16 at 01:34:37 -0500, Ray Warren wrote: > > On Sun, Aug 14, 2005 at 05:44:31PM -0400, Charles Levert wrote: > > > > > I have tested the following browsers and > > > they have no problem with it: Firefox 1.0.6, > > > Konqueror 3.1.4, links 0.4.2, and w3m 0.4.1. > > > > With Konqueror 3.2.3 and Opera 7.5.4 and Mozilla 1.7.5 and Galeon 1.3.18 > > if I attempt to enlarge the text sufficiently that the text in the > > shaded regions is legible,the text continues out the right side of the > > window instead of wrapping or triggering a horizontal scroll bar. > > Wrapping? No! > Avoiding it is the whole point of <pre>. > > It does trigger a horizontal scroll bar, but > for the whole page. > > I have now added a "overflow: auto" for <pre> in > the style sheet. My Gecko-based browsers have > no problem picking up on it thus triggering a > per-<pre> scrollbar when needed, but my older > Konqueror doesn't (not with "auto" nor with > "scroll"). > > Can you tell me if your more recent Konqueror > is more standard-compliant than mine? Also, > is Opera (which I don't have)? You can get a copy without a cash outlay if you can deal with a thin advertising bar at the top.It is rated as being very standard compliant. > > <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> This link is not working for me tonight but a horizontal scrollbar would alleviate my biggest problem. > > > This may not be classified as officially broken > > Indeed, this has nothing to do with SGML or HTML > being broken. It has to do with design. > > > > but is not viable for me. > > As long as you can somehow view the content > (i.e., the page at least loads), then this The problem is that at least part of the content is not available.It disappeared off the right side of the window. > > Feedback on the actual content is more relevant > for now and would be much appreciated. True, and if I can read the content I will comment on how useful/relevant it is for me. Thanks. |
|
From: Charles L. <cha...@gm...> - 2005-08-16 10:07:07
|
* On Tuesday 2005-08-16 at 01:34:37 -0500, Ray Warren wrote: > On Sun, Aug 14, 2005 at 05:44:31PM -0400, Charles Levert wrote: > > > I have tested the following browsers and > > they have no problem with it: Firefox 1.0.6, > > Konqueror 3.1.4, links 0.4.2, and w3m 0.4.1. > > With Konqueror 3.2.3 and Opera 7.5.4 and Mozilla 1.7.5 and Galeon 1.3.18 > if I attempt to enlarge the text sufficiently that the text in the > shaded regions is legible,the text continues out the right side of the > window instead of wrapping or triggering a horizontal scroll bar. Wrapping? No! Avoiding it is the whole point of <pre>. It does trigger a horizontal scroll bar, but for the whole page. I have now added a "overflow: auto" for <pre> in the style sheet. My Gecko-based browsers have no problem picking up on it thus triggering a per-<pre> scrollbar when needed, but my older Konqueror doesn't (not with "auto" nor with "scroll"). Can you tell me if your more recent Konqueror is more standard-compliant than mine? Also, is Opera (which I don't have)? <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> > This may not be classified as officially broken Indeed, this has nothing to do with SGML or HTML being broken. It has to do with design. > but is not viable for me. As long as you can somehow view the content (i.e., the page at least loads), then this discussion becomes more irrelevant, as all this will have to be retrofitted at some point to match the design used for fetchmail's FAQ anyway. Feedback on the actual content is more relevant for now and would be much appreciated. Thanks. |
|
From: Ray W. <ray...@in...> - 2005-08-16 08:34:42
|
On Sun, Aug 14, 2005 at 05:44:31PM -0400, Charles Levert wrote: > * On Sunday 2005-08-14 at 18:31:13 +0200, Michelle Konzack wrote: > > > > You have send it broken... > > Ok. If it wasn't damaged, then we know it's > not the MUAs or the mail transport system. > > > > > What is the tool you are using that generates > > > this error? > > > Could it be this tool that's broken? > > > Are you using its latest version? > > > > Yes > > But what's the name and specific version of this > tool from which you quoted an error message? > I'd like to be able to duplicate this myself. > > > > and your file seems to be: > [...] > > which is definitivly broken. > > The initial segment you quoted here is indeed > intact compared to the original. > > I see nothing that's so obviously broken about > it, whether from an SGML or from an HTML point > of view. > > > > Many Webbrowser claims about it. > > I have tested the following browsers and > they have no problem with it: Firefox 1.0.6, > Konqueror 3.1.4, links 0.4.2, and w3m 0.4.1. > > With Konqueror 3.2.3 and Opera 7.5.4 and Mozilla 1.7.5 and Galeon 1.3.18 if I attempt to enlarge the text sufficiently that the text in the shaded regions is legible,the text continues out the right side of the window instead of wrapping or triggering a horizontal scroll bar.This may not be classified as officially broken but is not viable for me. Ray Warren |
|
From: Charles L. <cha...@gm...> - 2005-08-15 03:14:45
|
* On Monday 2005-08-15 at 00:34:08 +0200, Jakob Hirsch wrote: > > And I didn't see any broken HTML, > maybe Michelle received a broken mail. Maybe it's my peculiar (but still valid) SGML/HTML coding/formatting style that throws some tools off. > Anyway, would have been better to put the file > on some web server and post the link here. I have uploaded it here: <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> > But what is so special about gmail that it needs its own documentation? Remember, this is the original document I wrote with the Gmail Help Center in mind. I am willing to evolve it for the fetchmail FAQ. Change the Gmail-specific details (such as the URL for Thawte's root certificate bundle) and it can become generic. Although, it could be nice to document how to figure out who the server certificate issuer is in the first place, and to list a few URLs for the most important CAs (such as Thawte and Entrust). > The SSL stuff is really helpful, I had some problems setting this up > properly, but not only with gmail. This is something (configuration of the fetchmail/OpenSSL combination) I had not seen documented in one place anywhere before. This was a big part of my motivation to write this. For instance, my system comes with a /usr/share/ssl/certs/ca-bundle.crt file with all the root certificates one could want, but fetchmail/OpenSSL is unable to use it in this form (i.e., all in a single file). I had to figure out from various sources that: -- you need the root certificate installed alone in its own file for fetchmail's sslcertck to be able to pick it up and do its checking-job; -- you have to run c_rehash to generates the symlinks, because those are the only file names that will be looked up; -- each of these files needs to have a ".pem" extension for c_rehash to pick it up in the first place (".txt" or ".cer" won't do). > btw, AFAIK fingerprint is only useful if the cert is not signed by a CA. That's why I used the word "mitigated", as opposed to a stronger word such as "necessary". It still has some useful value in this case; see below. > The downside is that is has to be changed if the cert changes (e.g. > expired). Without CRL verification, the following scenario is possible. Remember that this is about security, so you either attempt to provide it fully or you don't. -- The old server certificate, which forever remains properly signed by its issuer CA, is revocated (and so is included in the CRL) because its associated private key was compromised. -- The legitimate server starts using a new non-compromised server certificate. -- A man-in-the-middle attacker with the compromised private key pretends to be this server. I.e., it seems from our point-of-view that it has either the IP address or maybe just the domain name of the legitimate server. -- This attacker provides the old server certificate at SSL connection establishment. This server certificate's common name (CN) matches the domain name. This server certificate still is properly signed by its issuer CA (forever). -- We didn't configure fetchmail to verify the server certificate's MD5 signature. -- Fetchmail, as SSL client, cannot do CRL verification and so then fully accepts this form of authentication by the fake server pretending to be the legitimate one. Fetchmail then proceeds to feed (i.e., reveal to) this rogue server the client authentication information using POP3's USER and PASS commands, within the SSL connection. Checking the MD5 signature will at least alert us that the server certificate has changed if we succeed in connecting at least once to the legitimate server after this change. We will still be an unaware victim if (or, as long as) we are _systematically_ man-in-the-middled with the above scenario every single time after the change. The pop.gmail.com server certificate does point to the CRL's URI: <http://crl.thawte.com/ThawteServerCA.crl> In this case, it's a 99978-octet file that is updated every day and that has a sliding 28-day validity period. Fetchmail/OpenSSL doesn't but should download it _after_ the server certificate has been validated (so we know that this URI is dependable) and check the validity of the CRL itself (signature and time period) and the absence of the server certificate in it. Having fetchmail cache the CRL somewhere in /var or in a user-specified directory would also be a possibility. |
|
From: Jakob H. <jh...@pl...> - 2005-08-15 00:37:46
|
Charles Levert wrote: > I wrote a web page fragment entitled > "Configuring your incoming email client: fetchmail" > with the intent of submitting it for inclusion > on the Gmail Help Center's POP section at > <http://mail.google.com/support/bin/topic.py?topic=194>. Nice done (though I didn't check the exact details). And I didn't see any broken HTML, maybe Michelle received a broken mail. Anyway, would have been better to put the file on some web server and post the link here. But what is so special about gmail that it needs its own documentation? The SSL stuff is really helpful, I had some problems setting this up properly, but not only with gmail. btw, AFAIK fingerprint is only useful if the cert is not signed by a CA. The downside is that is has to be changed if the cert changes (e.g. expired). |
|
From: Charles L. <cha...@gm...> - 2005-08-14 23:44:33
|
* On Sunday 2005-08-14 at 18:31:13 +0200, Michelle Konzack wrote:
>
> You have send it broken...
Ok. If it wasn't damaged, then we know it's
not the MUAs or the mail transport system.
> > What is the tool you are using that generates
> > this error?
> > Could it be this tool that's broken?
> > Are you using its latest version?
>
> Yes
But what's the name and specific version of this
tool from which you quoted an error message?
I'd like to be able to duplicate this myself.
> and your file seems to be:
[...]
> which is definitivly broken.
The initial segment you quoted here is indeed
intact compared to the original.
I see nothing that's so obviously broken about
it, whether from an SGML or from an HTML point
of view.
> Many Webbrowser claims about it.
I have tested the following browsers and
they have no problem with it: Firefox 1.0.6,
Konqueror 3.1.4, links 0.4.2, and w3m 0.4.1.
If the problem is at the SGML level, can you
pinpoint a specific SGML production that is not
respected by this code?
<http://www.w3.org/MarkUp/SGML/productions.html>
<ftp://ftp.ifi.uio.no/pub/SGML/productions>
Otherwise, if it's at the HTML level, can you
pinpoint something specific in the DTD (or in
the specification itself) that is not respected
by this code?
<http://www.w3.org/TR/html4/strict.dtd>
<http://www.w3.org/TR/html4/>
> Better you update your HTML generator.
This is handwritten.
Then successfully validated as I described using
online tools.
So I'd like to understand precisely what I am
doing wrong at the standards level, since I am
doing it manually entirely myself.
|
|
From: Michelle K. <lin...@fr...> - 2005-08-14 18:31:14
|
Hi Charles,
Am 2005-08-14 10:14:10, schrieb Charles Levert:
> * On Sunday 2005-08-14 at 15:33:58 +0200, Michelle Konzack wrote:
> > The HTML code is broken!
>
> First, let's make sure that the file has not
> been damaged in transit:
You have send it broken...
> > > File "/tmp/gmail-pop-howto.html", line 228, column 0: CDATA terminal not found
>
> The original file only has 227 lines.
> What is the tool you are using that generates
> this error?
> Could it be this tool that's broken?
> Are you using its latest version?
Yes and your file seems to be:
------------------------------------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"
><html lang="en"
><head
><meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"
><title
>Configuring your incoming email client: fetchmail</title
><link rel="author" rev="made" title="Charles Levert"
href="mailto:cha...@gm..."
><style type="text/css"
> body {
color: black;
background-color: white;
}
h1, h2, h3, h4, h5, h6 {
font-family: sans-serif;
color: #006;
}
h1 { text-align: center }
a:link, a:visited { color: blue }
a:active { color: red }
a:hover { background-color: #FF9 }
p, li { font-family: serif }
pre {
margin-left: 3em;
padding: 5px;
font: smaller monospace;
color: #036;
background-color: #CCC;
}
tt, code, samp, kbd, var { color: #036 }</style
></head
><body
><h1
>Configuring your incoming email client: fetchmail</h1
><ol
><li
><p
><a href="http://gmail.google.com/support/bin/answer.py?answer=13273"
>Enable POP in your Gmail account.</a
></p
></li
><li
><p
------------------------------------------------------------------------
which is definitivly broken. Many Webbrowser claims about it.
Better you update your HTML generator.
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: Charles L. <cha...@gm...> - 2005-08-14 16:14:12
|
* On Sunday 2005-08-14 at 15:33:58 +0200, Michelle Konzack wrote:
> The HTML code is broken!
First, let's make sure that the file has not
been damaged in transit:
sh$ md5sum gmail-pop-howto.html
f0939d677611ad7579d6d02af9c9fe08 gmail-pop-howto.html
sh$ sha1sum gmail-pop-howto.html
a22910f102afaf001bfbf7a61a7f3ab136fdfd4a gmail-pop-howto.html
I tested the file with W3C's Markup Validation
Service at <http://validator.w3.org/> and got
"This Page Is Valid HTML 4.01 Strict!" as
a response.
I also tested its embedded style sheet
with W3C's CSS Validation Service at
<http://jigsaw.w3.org/css-validator/> and got
"No error or warning found" as a response.
> > File "/tmp/gmail-pop-howto.html", line 228, column 0: CDATA terminal not found
The original file only has 227 lines.
What is the tool you are using that generates
this error?
Could it be this tool that's broken?
Are you using its latest version?
|
|
From: Michelle K. <lin...@fr...> - 2005-08-14 15:34:01
|
The HTML code is broken! Am 2005-08-14 09:16:19, schrieb Charles Levert: > Hello. > > I wrote a web page fragment entitled > "Configuring your incoming email client: fetchmail" > with the intent of submitting it for inclusion > on the Gmail Help Center's POP section at > <http://mail.google.com/support/bin/topic.py?topic=194>. > > The Gmail Help Center currently lacks such an > item and fetchmail configuration can be more > involved than that of other email clients, > especially when OpenSSL configuration is taken > into full account. > > So far, I have simply been brushed off by the > "Gmail Team" <gma...@go...> with a > generic scripted answer stating that I wouldn't > receive a direct human response, at the point > when I hadn't even yet submitted my HTML code. > > This situation might change (as this is a > typical level-1 response from a help-desk), > but in the mean time, would you be interested > in this content? > > The idea would be to turn it into a > "How can I use fetchmail with Gmail's POP3 servers?" > fetchmail FAQ answer. > > I am attaching my original "gmail-pop-howto.html" > file to this email message for your > consideration. > > Thanks. > File "/tmp/gmail-pop-howto.html", line 228, column 0: CDATA terminal not found ------------------------- END OF REPLYED MESSAGE ------------------------- ****************************************************************** * Do not Cc: me, because I am on THIS list, if I write here * * Keine Cc: am mich, bin auf DIESER Liste wenn ich hier schreibe * ****************************************************************** Hello, Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com) |
|
From: Charles L. <cha...@gm...> - 2005-08-14 15:16:22
|
Hello. I wrote a web page fragment entitled "Configuring your incoming email client: fetchmail" with the intent of submitting it for inclusion on the Gmail Help Center's POP section at <http://mail.google.com/support/bin/topic.py?topic=194>. The Gmail Help Center currently lacks such an item and fetchmail configuration can be more involved than that of other email clients, especially when OpenSSL configuration is taken into full account. So far, I have simply been brushed off by the "Gmail Team" <gma...@go...> with a generic scripted answer stating that I wouldn't receive a direct human response, at the point when I hadn't even yet submitted my HTML code. This situation might change (as this is a typical level-1 response from a help-desk), but in the mean time, would you be interested in this content? The idea would be to turn it into a "How can I use fetchmail with Gmail's POP3 servers?" fetchmail FAQ answer. I am attaching my original "gmail-pop-howto.html" file to this email message for your consideration. Thanks. |
|
From: Matthias A. <mat...@gm...> - 2005-08-02 04:57:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have released a new fetchmail snapshot, 6.2.6-pre9, available from: <http://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=6730> mirror: <http://home.pages.de/~mandree/fetchmail/> Please test, particularly if you're running a multidrop setup. Also, we still need translators, we have some old translations that need to be updated and aren't enabled by default, but new translations will also be welcome. Contact me if you're interested and fetchmail doesn't currently ship with a translation into your favorite language. Notes: This release has fairly large internal cleanups - I decided to get rid of the obsolete inet6_apps/inner_connect/ipv6-connect code rather than carrying it into a new release - the "--netsec" and "-T" options are now gone. The INET6_ENABLE code was also simplified, everything is now a "service" internally, port is converted into service, although this should be transparent. There will be some more IPv6 awareness fixes, too many places still use the hardcoded IPv4-only gethostbyname function, so we'll have one or two more releases down the road before calling out for other release candidates. Summarized changes: * The multidrop code was severely broken in several places: o a fairly fundamental RFC822 parser bug was fixed that stripped the last character of bare addresses i. e. addresses without <> angle brackets (from Delivered-To: headers, for instance), responsible for many unrecognized domains in multidrop mode. o The multidrop IP address matching code was broken and checked only the first address of the configured servername against the aliases of the domain found in the envelope. o The multidrop MX matching code was broken and didn't resolve the MX hosts into IP addresses. * The netsec and -T options are gone, corresponding code was removed. See Notes above. * The gettext code (intl/ directory) was removed from the fetchmail package and, if NLS is desired, needs to be installed separately before fetchmail is built. * The default distribution format has been switched to bzip2. * The Python script is now optimized, byte-compiled and installed into the Python site-packages directory. * Some internal code shuffling and cleanups. - -- Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC7t0hvmGDOQUufZURAkDnAJ0aWzDHscE+O+HmtA3XanZ9clumcgCff9x+ p9HVT6Ri+Qaf0SCyNgSLFfw= =V4bi -----END PGP SIGNATURE----- |
|
From: mbox m. <ba...@at...> - 2005-07-12 17:22:14
|
If there was an rpm for this...I'd willingly test it. Mike B. |
|
From: Michelle K. <lin...@fr...> - 2005-07-11 12:48:26
|
Hello Matthias, Am 2005-07-11 03:09:11, schrieb Matthias Andree: > Greetings, > da el gl ja pt_BR sk sq tr - these are the translations that have been > removed from this release because they lag too far behind. They are: > Danish, Greek, Galician, Japanese, Brazilian Portuguese, Slovak, > Albanian and Turkish. Please help updating these translations. Please can you send me the po file for the turkish translation please? Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com) |
|
From: Matthias A. <mat...@gm...> - 2005-07-11 03:09:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I deem the current fetchmail SVN code approaching official release. I rolled another snapshot, labelled as fetchmail-6.2.6-pre4. I consider this a release candidate, if nothing serious shows up in the next few days, this can become 6.3.0. da el gl ja pt_BR sk sq tr - these are the translations that have been removed from this release because they lag too far behind. They are: Danish, Greek, Galician, Japanese, Brazilian Portuguese, Slovak, Albanian and Turkish. Please help updating these translations. If you have a test machine available, please test this version and report back if it worked for you, if it fixed your favourite 6.2.5 bugs, or if it introduced new bugs, or if you tested it without anything in particular. In case this fails to compile, please state your ./configure options, the exact error message with a few lines leading up to the error, your operating system and version and installed packages - or just gzip and attach the config.log file. Note this all comes without warranty, as usual for GPL'd software. Download from: <http://home.pages.de/~mandree/fetchmail/fetchmail-6.2.6-pre4.tar.bz2> Detached GnuPG Signature at: <http://home.pages.de/~mandree/fetchmail/fetchmail-6.2.6-pre4.tar.bz2.sig> The important visible changes since -pre3 are: - - the manual page is more verbose on the differences of single- vs. multidrop, courtesy of Hannes Beinert - - the FAQ has additional information on SSL verification, courtesy of Brian Candler - - the .spec file for RPM building was updated (note that this currently requires you to override the version, RPM doesn't like the dash in -pre4 - this will not affect the final release). - - the POP3 client will not attempt to send "PASS secret" if "USER login" failed previously. - - some translations disabled as detailed above - - new Russian translation added - - some translations updated - - proto RPOP in the configuration file is now supported (used to be supported only on the command line) Regards, - -- Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC0ca3vmGDOQUufZURAhD1AKCs/jporuw0N9KLvZqI5ZerkSLQnwCeLq3S XWgLuWQBc5JsuWqkSt+DhuU= =jU2o -----END PGP SIGNATURE----- |
|
From: Matthias A. <mat...@gm...> - 2005-07-04 21:25:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I have released a snapshot of the current fetchmail development code, labelled as fetchmail-6.2.6-pre3. If fixes some things since .alpha2 and was dubbed -pre3 rather than .alpha3 to help the translation project. The chances since .alpha2 summarized: - - IPv6 (--enable-inet6) fixes - - the .html documents were fixed to be conformant XHTML - - the .fetchmailrc parser was broken in .alpha1, now fixed. - - the message when .fetchids was to be deleted contained garbage, now fixed - - documentation was updated a bit If you have a test machine available, please test this version and report back if it worked for you, if it fixed your favourite 6.2.5 bugs, or if it introduced new bugs, or if you tested it without anything in particular. I am aware that some translations are not up to date, so in that case, help out with the translation project instead. In case it fails to compile, please state your ./configure option, the exact error message, your operating system and version - or just gzip and attach the config.log file. Note this all comes without warranty, as usual. Download from: <http://home.pages.de/~mandree/fetchmail/fetchmail-6.2.6-pre3.tar.bz2> Regards, - -- Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCyY0gvmGDOQUufZURAixtAJ4pZTBmvwM4GcqfE/mlbp21xFPYgwCgjhuZ lhXMgR71t5j8bCQyr7CUV20= =Et/R -----END PGP SIGNATURE----- |
|
From: Jakob H. <jh...@pl...> - 2005-07-03 23:19:23
|
Matthias Andree wrote: > Download from: > <http://home.pages.de/~mandree/fetchmail/fetchmail-6.2.6.alpha2.tar.bz2> I sent this before, but you probably didn't read it, as you set reply-to fet...@li... and this list is subscribers-only. But at least the error message and the garbage at the end seems to be fixed. :) |
|
From: Brian C. <B.C...@po...> - 2005-07-03 22:18:43
|
On Sun, Jul 03, 2005 at 09:41:17PM +0200, Matthias Andree wrote: > I have released a snapshot of the current fetchmail development code, > labelled as fetchmail-6.2.6.alpha2. The INSTALL file is very Linux-specific (talking about required versions of glibc, for example). I run FreeBSD 5.4 and I note: "Fetchmail has had serious grief from buggy versions of the gettext suite. If your version is older than 1.10.40, you should use the configure option --with-included-gettext'." I have package gettext-0.14.1 installed, and the one in the ports tree is currently 0.14.5. Any indication of the compatibility of those? It seems to work for me, but then again, I'm not translating into any non-English language. Separate point: it might be worth documenting how to set up certificate verification. I always have to rummage through the OpenSSL source to find out how to do this. For reference I did the following: - mkdir /etc/openssl/certs - from the openssl/certs directory: cp *.pem /etc/openssl/certs/ - in the openssl/tools directory: edit c_rehash and set $dir = "/etc/ssl" then run "perl c_rehash" - in .fetchmailrc, set option "sslcertpath /etc/ssl/certs" Regards, Brian. |
|
From: Matthias A. <mat...@gm...> - 2005-07-03 21:41:21
|
Greetings, I have released a snapshot of the current fetchmail development code, labelled as fetchmail-6.2.6.alpha2. If you have a test machine available, please test this version and report back if it worked for you, if it fixed your favourite 6.2.5 bugs, or if it introduced new bugs, or if you tested it without anything in particular. I am aware that some translations are not up to date, so in that case, help out with the translation project instead. In case it fails to compile, please state your ./configure option, the exact error message, your operating system and version - or just gzip and attach the config.log file. Note this all comes without warranty, as usual. Download from: <http://home.pages.de/~mandree/fetchmail/fetchmail-6.2.6.alpha2.tar.bz2> Regards, -- Matthias Andree |
18 messages has been excluded from this view by a project administrator.
