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: Rob M. <rob...@gm...> - 2006-12-05 08:09:37
|
On 12/5/06, Richardus Alim <al...@ga...> wrote: > > The problem is when I disabled DNS lookup in Zimbra conf the fetchmail > worked good > (fetchmail can retrieve mail in remote MTA and send them to my local MTA) > but if I enabled DNS lookup It didn't work. > Dec 5 01:45:53 mail postfix/lmtp[11957]: DAA00ACB66: to=<al...@xy...>, > relay=none, delay=1, status=bounced (Host or domain name not found. Name > service error for name=mail.xyz.com type=A: Host not found) That's an error from postfix. > Do I have setup a DNS Server in my local MTA ?? Well, that's generally a good idea (or at leasts the host needs to have DNS resolution working). I can't see why you'd want to disable DNS lookups, but you obviously have your reasons. Possibly alternatively, ensure that postfix/Zimbra know to accept the mail for xyz.com. -- 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: Richardus A. <al...@ga...> - 2006-12-05 03:34:52
|
Does any body have experience with zimbra & fetchmail ? My local MTA: CentOS 4.4 Zimbra zcs-4.0.4_GA_457.RHEL4 Fetchmail 6.2.5 I've just setup local MTA using zimbra and I want to retrive email from remote MTA (mail.test.com) below is my .fetchmail conf set admin "ad...@xy..." set syslog set daemon 180 poll mail.test.com proto pop3 user "alim" there with pass "123456" is "al...@xy..." here keep The problem is when I disabled DNS lookup in Zimbra conf the fetchmail worked good (fetchmail can retrieve mail in remote MTA and send them to my local MTA) but if I enabled DNS lookup It didn't work. This is my maillog Dec 5 01:45:50 mail fetchmail[11810]: POP3< +OK Microsoft Exchange POP3 server version 5.5.2653.23 signing off Dec 5 01:45:50 mail fetchmail[11810]: 6.2.5 querying mail.test.com (protocol POP3) at Tue 05 Dec 2006 01:45:50 AM UTC: poll completed Dec 5 01:45:50 mail fetchmail[11810]: SMTP> QUIT Dec 5 01:45:50 mail postfix/smtpd[11584]: disconnect from localhost.localdomain[127.0.0.1] Dec 5 01:45:50 mail fetchmail[11810]: SMTP< 221 Bye Dec 5 01:45:50 mail fetchmail[11810]: sleeping at Tue 05 Dec 2006 01:45:50 AM UTC Dec 5 01:45:52 mail postfix/smtpd[11804]: connect from localhost.localdomain[127.0.0.1] Dec 5 01:45:52 mail postfix/smtpd[11804]: DAA00ACB66: client=localhost.localdomain[127.0.0.1] Dec 5 01:45:52 mail postfix/cleanup[11585]: DAA00ACB66: message-id=<215...@ma...> Dec 5 01:45:52 mail postfix/qmgr[7440]: DAA00ACB66: from=<al...@xy...>, size=2592, nrcpt=1 (queue active) Dec 5 01:45:52 mail postfix/smtpd[11804]: disconnect from localhost.localdomain[127.0.0.1] Dec 5 01:45:52 mail postfix/smtp[11800]: 6792AACB63: to=<al...@xy...>, relay=127.0.0.1[127.0.0.1], delay=2, status=sent (250 2.6.0 Ok, id=05197-01, from MTA([127.0.0.1]:10025): 250 Ok: queued as DAA00ACB66) Dec 5 01:45:52 mail postfix/qmgr[7440]: 6792AACB63: removed Dec 5 01:45:53 mail postfix/lmtp[11957]: DAA00ACB66: to=<al...@xy...>, relay=none, delay=1, status=bounced (Host or domain name not found. Name service error for name=mail.xyz.com type=A: Host not found) Dec 5 01:45:53 mail postfix/cleanup[11585]: 1E2DFACB69: message-id=<200...@ma...> Dec 5 01:45:53 mail postfix/qmgr[7440]: 1E2DFACB69: from=<>, size=4439, nrcpt=1 (queue active) Dec 5 01:45:53 mail postfix/qmgr[7440]: DAA00ACB66: removed Dec 5 01:45:53 mail postfix/lmtp[11957]: 1E2DFACB69: to=<al...@xy...>, relay=none, delay=0, status=bounced (Host or domain name not found. Name service error for name=mail.xyz.com type=A: Host not found) Dec 5 01:45:53 mail postfix/qmgr[7440]: 1E2DFACB69: removed Do I have setup a DNS Server in my local MTA ?? Alim |
|
From: Stuart J. B. <sjb...@bl...> - 2006-12-01 06:32:51
|
Yup, that's it. Thanks > -----Original Message----- > From: fet...@li... > [mailto:fet...@li...]On Behalf Of Rob > MacGregor > Sent: Friday, 1 December 2006 15:57 PM > To: fet...@li... > Subject: Re: [fetchmail-users] 'keep' and 'uidl'. > > > On 11/30/06, Stuart J. Browne <sjb...@bl...> wrote: > > Hi, > > > > Running fetchmail 6.3.5 as a single-instance (not in daemon > mode) with the > > options below, it continuously gets the first 20 messages, instead of > > ignoring those it's downloaded, and getting the fresh messages. > > You're using "keep" (don't delete any messages) and "fetchall" > (download all messages, even those we've seen before), along with a > limit of 20. > > You're NEVER going to get beyond those initial 20. Drop the > "fetchall" line and you'll probably have more luck (and I'm pretty > sure 6.3.x will print warnings when you combine keep, fetchall and > daemon mode). > > -- > 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 > _______________________________________________ > fetchmail-users mailing list > fet...@li... > https://lists.berlios.de/mailman/listinfo/fetchmail-users > |
|
From: Rob M. <rob...@gm...> - 2006-12-01 05:58:17
|
On 11/30/06, Stuart J. Browne <sjb...@bl...> wrote:
> Hi,
>
> Running fetchmail 6.3.5 as a single-instance (not in daemon mode) with the
> options below, it continuously gets the first 20 messages, instead of
> ignoring those it's downloaded, and getting the fresh messages.
You're using "keep" (don't delete any messages) and "fetchall"
(download all messages, even those we've seen before), along with a
limit of 20.
You're NEVER going to get beyond those initial 20. Drop the
"fetchall" line and you'll probably have more luck (and I'm pretty
sure 6.3.x will print warnings when you combine keep, fetchall and
daemon mode).
--
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: Stuart J. B. <sjb...@bl...> - 2006-12-01 05:41:02
|
Hi, Running fetchmail 6.3.5 as a single-instance (not in daemon mode) with the options below, it continuously gets the first 20 messages, instead of ignoring those it's downloaded, and getting the fresh messages. The 20 messages which are fetched are delivered no problem, it just not getting the next 20, or any after that. Can anybody see anything that I'm doing wrong, or is this an issue that needs to be addressed? Note: I've also tried the Cmdline with '--fastuidl' of 0-4 with no success. Bkx -- Config - "poll-file" (0600) -- poll pop.mail.yahoo.com protocol POP3 port 110 uidl timeout 120 user 'user-hidden' with pass 'pass-hidden' is 'local-user-hidden _at_ local-domain-hidden' here smtp host d_mx0,d_mx1 options limit 31457280 fetchlimit 20 fetchall antispam 451,553,550,554 keep -- Config -- -- Cmdline -- /usr/bin/fetchmail -v -i /root/fetchmail/pop.mail.yahoo.com.fetchid -f poll-file -- Cmdline -- -- pop.mail.yahoo.com.fetchid (0600) -- use...@po... ALNk/NgAAXtuRVCsRQZTnzZYj5Q use...@po... AK9k/NgAAClARVCyoABgRVtCONM use...@po... ALFk/NgAAWDPRVJqpghrVRZ1HNQ use...@po... ALJk/NgAAPkIRVMHZQDU2nNO90M use...@po... ALNk/NgAATMIRVq9AAeEGivA9o0 use...@po... ALBk/NgAAH2nRVy2/gc5FC7c0n0 use...@po... ALRk/NgAAEQzRV2ZXQdhqAkSW7Y use...@po... ALFk/NgAANYlRV269wuGYTGAFmg use...@po... ALVk/NgAATtFRV4UqgW0Yzie3M0 use...@po... AK5k/NgAAD6ARWDsDgIZOjyzDlE use...@po... AKxk/NgAAX4QRWcSKQhWolt8TrM use...@po... AK9k/NgAAWwiRWdOSgfYiCnKXd8 use...@po... AKxk/NgAAMw7RWhnDwu+RWUg1XA use...@po... AKtk/NgAARDGRWmCWw0G9EmkZPQ use...@po... AK5k/NgAAJ1SRWmhEgSgxm1kXWk use...@po... ALJk/NgAAP3kRWnPoQpUVlb2e6M use...@po... AK9k/NgAAVtURWqsDw800xb3wsU use...@po... ALJk/NgAAKNgRWtSAAeRgSuaXr4 use...@po... AKpk/NgAAKUQRWtfIw8BGRB528A use...@po... ALBk/NgAAXA8RWt1TQFjWj6hoBQ -- pop.mail.yahoo.com.fetchid -- -- CMD Output (modified) -- fetchmail: WARNING: Running as root is discouraged. fetchmail: 6.3.5 querying pop.mail.yahoo.com (protocol POP3) at Thu Nov 30 20:29:03 2006: poll started Trying to connect to 68.142.206.14/110...connected. fetchmail: POP3< +OK hello from popgate(2.35.8) fetchmail: POP3> CAPA fetchmail: POP3< +OK CAPA list follows fetchmail: POP3< IMPLEMENTATION popgate 2.35.8 fetchmail: POP3< PIPELINING fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< USER fetchmail: POP3< . fetchmail: POP3> USER user-hidden fetchmail: POP3< +OK password required. fetchmail: POP3> PASS * fetchmail: POP3< +OK maildrop ready, 26 messages (1042379 octets) (33339166 2147483648) fetchmail: POP3> STAT fetchmail: POP3< +OK 26 1042379 fetchmail: POP3> UIDL fetchmail: POP3< +OK 26 messages (1042379 octets) fetchmail: POP3< 1 ALNk/NgAAXtuRVCsRQZTnzZYj5Q fetchmail: POP3< 2 AK9k/NgAAClARVCyoABgRVtCONM fetchmail: POP3< 3 ALFk/NgAAWDPRVJqpghrVRZ1HNQ fetchmail: POP3< 4 ALJk/NgAAPkIRVMHZQDU2nNO90M fetchmail: POP3< 5 ALNk/NgAATMIRVq9AAeEGivA9o0 fetchmail: POP3< 6 ALBk/NgAAH2nRVy2/gc5FC7c0n0 fetchmail: POP3< 7 ALRk/NgAAEQzRV2ZXQdhqAkSW7Y fetchmail: POP3< 8 ALFk/NgAANYlRV269wuGYTGAFmg fetchmail: POP3< 9 ALVk/NgAATtFRV4UqgW0Yzie3M0 fetchmail: POP3< 10 AK5k/NgAAD6ARWDsDgIZOjyzDlE fetchmail: POP3< 11 AKxk/NgAAX4QRWcSKQhWolt8TrM fetchmail: POP3< 12 AK9k/NgAAWwiRWdOSgfYiCnKXd8 fetchmail: POP3< 13 AKxk/NgAAMw7RWhnDwu+RWUg1XA fetchmail: POP3< 14 AKtk/NgAARDGRWmCWw0G9EmkZPQ fetchmail: POP3< 15 AK5k/NgAAJ1SRWmhEgSgxm1kXWk fetchmail: POP3< 16 ALJk/NgAAP3kRWnPoQpUVlb2e6M fetchmail: POP3< 17 AK9k/NgAAVtURWqsDw800xb3wsU fetchmail: POP3< 18 ALJk/NgAAKNgRWtSAAeRgSuaXr4 fetchmail: POP3< 19 AKpk/NgAAKUQRWtfIw8BGRB528A fetchmail: POP3< 20 ALBk/NgAAXA8RWt1TQFjWj6hoBQ fetchmail: POP3< 21 ALZk/NgAAWWnRW3DjwcxUl0GTYQ fetchmail: POP3< 22 AK5k/NgAAHnoRW3HtQMMxi7+nFU fetchmail: POP3< 23 AK9k/NgAAOU+RW3nZgnIvH8jhLU fetchmail: POP3< 24 ALBk/NgAAKc7RW9CGgNu2SCRwTg fetchmail: POP3< 25 ALNk/NgAABvVRW+KiAV/RDcxBmw fetchmail: POP3< 26 ALJk/NgAASjYRW+LZQzE6ED8lXg fetchmail: POP3< . 26 messages (20 seen) for user-hidden at pop.mail.yahoo.com (1042379 octets). fetchmail: POP3> LIST 1 fetchmail: POP3< +OK 1 647030 fetchmail: POP3> RETR 1 fetchmail: POP3< +OK 647030 octets reading message use...@po...:1 of 26 (647030 octets) fetchmail: getaddrinfo("host","smtp") error: Name or service not known Trying to connect to ip-hidden/25...connected. fetchmail: SMTP< 220 d_mx0 ESMTP Sendmail 8.13.1/8.13.1; Thu, 30 Nov 2006 20:29:05 -0800 fetchmail: SMTP> EHLO sandbox fetchmail: SMTP< 250-d_mx0 Hello sandbox [ip-hidden], pleased to meet you fetchmail: SMTP< 250-ENHANCEDSTATUSCODES fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250-8BITMIME fetchmail: SMTP< 250-SIZE 41943040 fetchmail: SMTP< 250-DSN fetchmail: SMTP< 250-ETRN fetchmail: SMTP< 250-AUTH DIGEST-MD5 CRAM-MD5 fetchmail: SMTP< 250-STARTTLS fetchmail: SMTP< 250-DELIVERBY fetchmail: SMTP< 250 HELP fetchmail: SMTP> MAIL FROM:<--hidden--> SIZE=647030 fetchmail: SMTP< 250 2.1.0 <--hidden-->... Sender ok fetchmail: SMTP> RCPT TO:<local-user-hidden _at_ local-domain-hidden> fetchmail: SMTP< 250 2.1.5 <local-user-hidden _at_ local-domain-hidden>... Recipient ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself #*<snip>fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 2.0.0 kB14T5Vd023263 Message accepted for delivery not flushed fetchmail: POP3> LIST 2 fetchmail: POP3< +OK 2 10204 fetchmail: POP3> RETR 2 fetchmail: POP3< +OK 10204 octets reading message use...@po...:2 of 26 (10204 octets) fetchmail: SMTP> MAIL FROM:<--hidden--> SIZE=10204 fetchmail: SMTP< 250 2.1.0 <--hidden-->... Sender ok fetchmail: SMTP> RCPT TO:<local-user-hidden _at_ local-domain-hidden> fetchmail: SMTP< 250 2.1.5 <local-user-hidden _at_ local-domain-hidden>... Recipient ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself #*<snip>fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 2.0.0 kB14T5Ve023263 Message accepted for delivery not flushed <snip - repeat for 20 messages> fetchmail: POP3> QUIT fetchmail: POP3< +OK server signing off. fetchmail: SMTP> QUIT fetchmail: SMTP< 221 2.0.0 d_mx0 closing connection fetchmail: 6.3.5 querying pop.mail.yahoo.com (protocol POP3) at Thu Nov 30 20:30:05 2006: poll completed fetchmail: Query status=13 (MAXFETCH) fetchmail: normal termination, status 13 -- CMD Output (modified)-- |
|
From: Matthias A. <mat...@gm...> - 2006-11-29 23:11:47
|
Volker Kuhlmann <hi...@pa...> writes: >> 3. Does fetchmail re-probe capabilities in daemon mode for the 2nd and >> subsequent polls? It shouldn't. > > What if fetchmail runs for 3 months, and the server changed 2.5 months > ago? And with *ix, 3 months is nothing. In that case, the way out is to have fetchmail re-execute itself. To achieve that, just touch the run control file ($HOME/.fetchmailrc, for instance) - if the mtime increases, fetchmail restarts. -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-11-29 23:09:49
|
Jakob Hirsch <jh...@pl...> writes: > Quoting Matthias Andree: > >> 1. You did not ask for SSL, but you did probably not prohibit TLS >> either, so fetchmail will - that's its default - look if it has the >> opportunity to use TLS. Using 'sslproto ""' should defeat this CAPA >> probe. This goes along with <http://www.fetchmail.info/fetchmail-FAQ.html#K6> > > Ok, I get that. Setting sslproto to an empty string prevents CAPA, > indeed. But that wasn't necessary in rc3 (and AFAIR, many versions > before). Not that it bothers me much, I just wonder why this changed. That's actually a bug fix, but the necessary detail is missing from the NEWS file - I've just committed that information to SVN (rev. 4979). It wasn't necessary to suppress these with previous versions, because 6.3.6-rc3/6.3.5 and older were broken and didn't always probe when they should have. CAPA is a requisite for TLS, but these older versions only probe capabilities (which is a requisite for TLS) if you configure no specific authentication for a certain server (but let fetchmail guess), or configure GSSAPI, Kerberos V4, OTP or CRAM-MD5. (For some undocumented reason, Kerberos V5 hasn't been in this list, I presume that was an oversight.) -- Matthias Andree |
|
From: Volker K. <hi...@pa...> - 2006-11-29 19:13:55
|
> 3. Does fetchmail re-probe capabilities in daemon mode for the 2nd and > subsequent polls? It shouldn't. What if fetchmail runs for 3 months, and the server changed 2.5 months ago? And with *ix, 3 months is nothing. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. |
|
From: Jakob H. <jh...@pl...> - 2006-11-29 18:06:26
|
Quoting Matthias Andree: > 1. You did not ask for SSL, but you did probably not prohibit TLS > either, so fetchmail will - that's its default - look if it has the > opportunity to use TLS. Using 'sslproto ""' should defeat this CAPA > probe. This goes along with <http://www.fetchmail.info/fetchmail-FAQ.html#K6> Ok, I get that. Setting sslproto to an empty string prevents CAPA, indeed. But that wasn't necessary in rc3 (and AFAIR, many versions before). Not that it bothers me much, I just wonder why this changed. > 3. Does fetchmail re-probe capabilities in daemon mode for the 2nd and > subsequent polls? It shouldn't. I don't know, I use cron. |
|
From: Matthias A. <mat...@gm...> - 2006-11-29 17:39:27
|
Jakob Hirsch schrieb am 2006-11-29: > But why the superfluous CAPA? I know the server does not support SSL or > TLS, and I have no "ssl" for it in my fetchmailrc, so why look for it at > all? It probably does not harm much, but I think we should not bother > the server unnecessarily, so the extra connect should be avoided. We > could instead try to login despite of the failed CAPA, and only > reconnect after this login failed (which will surely happen with some > servers). 1. You did not ask for SSL, but you did probably not prohibit TLS either, so fetchmail will - that's its default - look if it has the opportunity to use TLS. Using 'sslproto ""' should defeat this CAPA probe. This goes along with <http://www.fetchmail.info/fetchmail-FAQ.html#K6> 2. ESR got reports that some servers dropped the connection later on when probed for capabilities, and a reconnect was chosen as a solution. I don't know many of the details though, if someone knows URLs off-hand, let me know. I'm a bit loathe to change this part of the behavior at this time though. Given that CAPA doesn't cause state change, servers that change behavior after "reconnect without CAPA" are broken anyways. 3. Does fetchmail re-probe capabilities in daemon mode for the 2nd and subsequent polls? It shouldn't. -- Matthias Andree |
|
From: Jakob H. <jh...@pl...> - 2006-11-29 10:45:28
|
Quoting Matthias Andree: > Thank you very much for testing this. > The attached patch should cure this. You're welcome. Thanks for the patch, looks better now: > fetchmail: 6.3.6-rc4 querying pop.guru.de (protocol POP3) at Wed, 29 Nov 2006 10:33:36 +0100 (CET): poll started > Trying to connect to 212.11.227.194/110...connected. > fetchmail: POP3< +OK b1gPOP3 2-1.22 Linux (guru.de) ready > fetchmail: POP3> CAPA > fetchmail: POP3< -ERR Unknown command (in this session state): "CAPA" > fetchmail: Unknown command (in this session state): "CAPA" > fetchmail: Repoll immediately on jh...@gu...@pop.guru.de > Trying to connect to 212.11.227.194/110...connected. > fetchmail: POP3< +OK b1gPOP3 2-1.22 Linux (guru.de) ready > fetchmail: POP3> USER xx...@gu... > fetchmail: POP3< +OK Need password for jh...@gu... > fetchmail: POP3> PASS * > fetchmail: POP3< +OK Logged in, you have 0 message(s) in your mailbox (0 octets) But why the superfluous CAPA? I know the server does not support SSL or TLS, and I have no "ssl" for it in my fetchmailrc, so why look for it at all? It probably does not harm much, but I think we should not bother the server unnecessarily, so the extra connect should be avoided. We could instead try to login despite of the failed CAPA, and only reconnect after this login failed (which will surely happen with some servers). |
|
From: Matthias A. <mat...@gm...> - 2006-11-29 08:07:10
|
"Ian! D. Allen" <id...@id...> writes: > Please do consider an enhancement to tell us both (1) the .fetchmailrc > name and (2) the userid for connections that fail. Editing output to > remove excess verbosity (e.g. using "sed") is easy; it's impossible to > invent output that isn't there. Ian, thank you for the other example. It would surely be nice to have a good session identification (rcfile, if given; user, server, port and perhaps folder for IMAP) logged along with the problem. This, too, will only be fixed for 6.3.7, which will not happen too soon, probably not this year any more. Best regards, -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-11-29 07:58:13
|
Jakob Hirsch <jh...@pl...> writes: > Quoting Matthias Andree: > > It worked here: > >> fetchmail: 6.3.6-rc3 querying pop.guru.de (protocol POP3) at Mon, 27 Nov 2006 10:58:09 +0100 (CET): poll started >> Trying to connect to 212.11.227.194/110...connected. >> fetchmail: POP3< +OK b1gPOP3 2-1.22 Linux (guru.de) ready >> fetchmail: POP3> USER xx...@gu... >> fetchmail: POP3< +OK Need password for xx...@gu... >> fetchmail: POP3> PASS * >> fetchmail: POP3< +OK Logged in, you have 0 message(s) in your mailbox (0 octets) > ... Thank you very much for testing this. The attached patch should cure this. -- Matthias Andree |
|
From: Ian! D. A. <id...@id...> - 2006-11-27 16:07:42
|
> > I'm finding it awkward to make fetchmail give me just the right
> > amount of detail about the messages that are being rejected.
> I'll make a note and see if this can be addressed for 6.3.7
Below is another example of not enough detail. I query two machines:
fetchmail: No mail for idallen at localhost
fetchmail: Query status=2 (SOCKET)
Obviously the first one worked, telling me what userid and what entry in
my .fetchmailrc was used. The second query failed; but, no information
is printed about it. It gets worse when querying more than one machine:
fetchmail: No mail for idallen at localhost
fetchmail: Query status=2 (SOCKET)
fetchmail: Query status=2 (SOCKET)
fetchmail: Query status=2 (SOCKET)
fetchmail: Query status=2 (SOCKET)
fetchmail: Query status=2 (SOCKET)
Which ones failed? Which userids? Sometimes I'm at least told the
.fetchmailrc entry of the error but not the userid being polled:
fetchmail: timeout after 60 seconds waiting for server localhost.
fetchmail: client/server synchronization error while fetching from localhost
fetchmail: Query status=7 (ERROR)
fetchmail: timeout after 60 seconds waiting for server localhost.
fetchmail: client/server synchronization error while fetching from localhost
fetchmail: Query status=7 (ERROR)
Please do consider an enhancement to tell us both (1) the .fetchmailrc
name and (2) the userid for connections that fail. Editing output to
remove excess verbosity (e.g. using "sed") is easy; it's impossible to
invent output that isn't there.
Thanks for a very useful program.
--
| Ian! D. Allen - id...@id... - Ottawa, Ontario, Canada
| Home Page: http://www.idallen.com/ - Contact Improv: http://contactimprov.ca/
| College professor (Open Source / Linux) via: http://teaching.idallen.com/
| Support the public commons and public digital rights: http://eff.org/
|
|
From: Jakob H. <jh...@pl...> - 2006-11-27 11:05:14
|
Quoting Matthias Andree: It worked here: > fetchmail: 6.3.6-rc3 querying pop.guru.de (protocol POP3) at Mon, 27 Nov 2006 10:58:09 +0100 (CET): poll started > Trying to connect to 212.11.227.194/110...connected. > fetchmail: POP3< +OK b1gPOP3 2-1.22 Linux (guru.de) ready > fetchmail: POP3> USER xx...@gu... > fetchmail: POP3< +OK Need password for xx...@gu... > fetchmail: POP3> PASS * > fetchmail: POP3< +OK Logged in, you have 0 message(s) in your mailbox (0 octets) ... but not anymore... > fetchmail: 6.3.6-rc4 querying pop.guru.de (protocol POP3) at Mon, 27 Nov 2006 10:59:54 +0100 (CET): poll started > Trying to connect to 212.11.227.194/110...connected. > fetchmail: POP3< +OK b1gPOP3 2-1.22 Linux (guru.de) ready > fetchmail: POP3> CAPA > fetchmail: POP3< -ERR Unknown command (in this session state): "CAPA" > fetchmail: Unknown command (in this session state): "CAPA" > fetchmail: Authorization failure on xx...@gu...@pop.guru.de > fetchmail: POP3> QUIT > fetchmail: POP3< +OK Bye > fetchmail: 6.3.6-rc4 querying pop.guru.de (protocol POP3) at Mon, 27 Nov 2006 10:59:54 +0100 (CET): poll completed > fetchmail: Query status=3 (AUTHFAIL) > fetchmail: normal termination, status 3 with defaults proto pop3 ... and poll pop.guru.de auth password user xx...@gu... pass yyyyyy fetchall to "guru" There should be no CAPA at all (or at least used to be), but fetchmail should not stumble on that, I guess. |
|
From: Matthias A. <mat...@gm...> - 2006-11-27 10:30:34
|
Doram Greenblat <do...@wd...> writes: > Hey, I been using fetchmail great on some servers of ours, downloads without a problem. > > I'm having a problem with 'qmail' servers and multiple recipients on > a multidrop mailbox. No. You're likely having a misconfigured fetchmail, and probably also an older version - else you'd probably have seen it bitch about a missing envelope option. > if it helps, this is the situation. > qmail -> fetchmail -> postfix -(postfix filters mail through a dspam socket, which feeds back into postfix after scanning). This does indeed help. Be sure to properly configure the envelope and perhaps qvirtual options, and use a recent version, 6.3.4 or 6.3.6-rc4. -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-11-27 10:27:35
|
"Ian! D. Allen" <id...@id...> writes: > My web host has some SMTP spam blocking in place; so, certain messages > that I fetch from other places are not accepted there. I'm finding it > awkward to make fetchmail give me just the right amount of detail about > the messages that are being rejected. I'll make a note and see if this can be addressed for 6.3.7 - but perhaps it's 6.4 stuff. > Also, the output is a hard to read, with the SMTP error in the middle of > another line of output, appearing just before "flushed" or "not flushed". Try 6.3.6-rc4, I've fixed some of this message-mixing/out of order stuff. -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-11-27 10:24:44
|
Michelle Konzack <lin...@fr...> writes: > And I am since years realy happy using fetchmail which > has never leaved me and was/is ALWAYS working perfect. For any reasonably distorted definition of "perfect". Perfectly working software is a mirage. (Or it's trivial, which doesn't count -- and BTW, does your helloworld.c check the printf return value or ferror()? Oops, it's not trivial any more...) -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-11-27 04:20:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, After several more bugs had to be fixed, I have uploaded the fourth fetchmail 6.3.6 release candidate to the usual download location: <http://home.pages.de/~mandree/fetchmail/> - the site also has rpms. It is very important that 6.3.6-rc4 gets as much testing as possible, so as to find incompatibilities between the fixes and your existing setups. Please report all such incompatibilities, else we can't fix them for 6.3.6, obviously, and it may be a long time before the release after this. WARNING: This message sets the Reply-To: header. When replying to me personally, you need to edit the To: header! Can those who use an mda and who have experienced fetchmail crashes after refused messages please test if these are gone? Thank you. Happy fetching, Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFallUvmGDOQUufZURAtEEAKDm5Z2M0Igfldst8uEef8KgHSg/SACfdn1k CBvvTQrhpb72NaQVBzbaAX4= =esf+ -----END PGP SIGNATURE----- |
|
From: Ian! D. A. <id...@id...> - 2006-11-25 08:56:23
|
My web host has some SMTP spam blocking in place; so, certain messages
that I fetch from other places are not accepted there. I'm finding it
awkward to make fetchmail give me just the right amount of detail about
the messages that are being rejected.
Here are some captured fetchmail sessions I run at my web hosting provider
(a cPanel site):
2 messages for someuser at somehost.com (29755 octets).
reading message som...@so...:1 of 2 (26357 octets) fetchmail: SMTP error: 550 Administrative prohibition
fetchmail: SMTP listener refused delivery
flushed
reading message som...@so...:2 of 2 (3398 octets) flushed
Another one:
reading message oth...@ot...:1 of 1 (598 octets) fetchmail: SMTP error: 451 Temporary local problem - please try later
not flushed
Another one:
1 message for someuser at somehost.com (3155 octets).
reading message som...@so...:1 of 1 (3155 octets) fetchmail: SMTP error: 550 Sender verify failed
fetchmail: can't even send to id...@id...!
flushed
Can fetchmail tell me just a bit more detail about the userid that was
being processed (and refused/rejected), without me having to turn on
full verbosity for all email fetching? I'd like to see the userid that
is causing the "Administrative prohibition" and "Sender verify" errors,
without having to make all my sessions fully verbose.
Also, the output is a hard to read, with the SMTP error in the middle of
another line of output, appearing just before "flushed" or "not flushed".
--
| Ian! D. Allen - id...@id... - Ottawa, Ontario, Canada
| Home Page: http://www.idallen.com/ - Contact Improv: http://contactimprov.ca/
| College professor (Open Source / Linux) via: http://teaching.idallen.com/
| Support the public commons and public digital rights: http://eff.org/
|
|
From: Michelle K. <lin...@fr...> - 2006-11-24 18:13:35
|
Am 2006-11-22 18:57:38, schrieb Mitko Rürup: > Hello, > > i changed my network config to have multiple ips on eth0. Since then, > every time the alias eth0:1 is up fetchmail refuses to work. with just > one ip on the interface everything works well. > > my config looks like the following: > > set postmaster "postmaster" > set bouncemail > set no spambounce > set properties "" > set daemon 300 > poll haftbar.de with proto IMAP > interface eth0/141.28.224.224 monitor eth0 > user '#########' there with password '########' is '#######' here > options keep ssl > > > i tried with or without interface option, with or without monitor option > > there is only one nic installes with the following ips: > > eth0 141.28.224.224 hostname homer > eth0:1 141.28.224.70 hostname dump > > fetchmail constantly refuses to use the hostname homer, uses dump > instead and does nothing after telling me that he is polling the server. > > any clues to solve this? Maybe you should use eth0:0 for the first interface in your fetchmailrc? Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ ##################### Debian GNU/Linux Consultant ##################### Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) |
|
From: Michelle K. <lin...@fr...> - 2006-11-24 18:13:27
|
Am 2006-11-22 20:56:41, schrieb Volker Kuhlmann:
> Author: Charles Cazabon (yep!)
> Date: Sun, 12 Oct 2003 21:05:47 -0600
> Private mail to me, saying that getmail is better than fetchmail because
> it wouldn't lose mail or cause bogus bounces in its default
> configuration. He was unable to give specifics though when probed, but
> liked to rant against fetchmail. Personally I found this the best he
> said in the email exchange: "You're free not to use getmail." And I
> don't. :)
As I have already written, loss of messages occur only
on configuration errors.
And I am since years realy happy using fetchmail which
has never leaved me and was/is ALWAYS working perfect.
Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: Michelle K. <lin...@fr...> - 2006-11-24 18:12:32
|
Am 2006-11-22 01:30:18, schrieb Matthias Andree:
> Michelle Konzack <lin...@fr...> writes:
>
> > And the getmail'ers claim that fetchmail is loosing all the times mails...
> > Realy weired; - after 7 years of fetchmail usage!
>
> Author, Date, Subject, URL?
Since I am on many Lists, there was some stuff on <debian-user> and
<debian-user-german> not only one time. Same for procmail<->maildrop.
But in my experience, fetchmail nor getmail have lost messages and
same for procmail and maildrop since I MUST use all four programs at
my customers.
I have seen ONLY user configuration errors and the programs have done
what was requested.
Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: Rob M. <rob...@gm...> - 2006-11-24 14:08:10
|
On 11/24/06, Doram Greenblat <do...@wd...> wrote:
>
> Hey, I been using fetchmail great on some servers of ours, downloads
> without a problem.
>
> I'm having a problem with 'qmail' servers and multiple recipients on a
> multidrop mailbox.
> the mails are duplicating exponentially, based on how many recipients in
> the mail are local.
>
> anyone got any ideas.
> I see fetchmail has some sort of 'discard duplicates' function.
>
> Does it work correctly, how do I utilize it.
From the man page:
"A piece of mail is considered duplicate if it has the same message-ID
as the message immediately preceding and more than one addressee."
If that isn't happening then it suggests they're not in sequence, in
which case you may need to use whatever duplicate suppression your
IMAP/POP server has (I know Cyrus does, don't know about others).
--
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: Doram G. <do...@wd...> - 2006-11-24 13:31:33
|
Hey, I been using fetchmail great on some servers of ours, downloads without a problem. I'm having a problem with 'qmail' servers and multiple recipients on a multidrop mailbox. the mails are duplicating exponentially, based on how many recipients in the mail are local. anyone got any ideas. I see fetchmail has some sort of 'discard duplicates' function. Does it work correctly, how do I utilize it. if it helps, this is the situation. qmail -> fetchmail -> postfix -(postfix filters mail through a dspam socket, which feeds back into postfix after scanning). Regards Doram. |