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: Support @ S. N. <su...@ma...> - 2007-01-07 12:56:02
|
Fetchmail Version ---------------------------------------- Fetchmail version 6.2.5+POP2+RPA+NTLM+SDPS+SSL+OPIE+NLS (SLES 9) .fetchmail ---------------------------------------- poll pop3.mailforyou.co.uk proto pop3 envelope "Delivered-To" user remoteusername with password remotepassword to * here Output ---------------------------------------- fetchmail: 6.2.5 querying pop3.mailforyou.co.uk (protocol POP3) at Sun Jan 7 11 :02:08 2007: poll started fetchmail: POP3< +OK barracuda Cyrus POP3 v2.2.3 server ready <43452629314471556 53.1168167727@barracuda> fetchmail: POP3> CAPA fetchmail: POP3< +OK List of capabilities follows fetchmail: POP3< EXPIRE NEVER fetchmail: POP3< LOGIN-DELAY 0 fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< PIPELINING fetchmail: POP3< RESP-CODES fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< USER fetchmail: POP3< IMPLEMENTATION Cyrus POP3 server v2.2.3 fetchmail: POP3< . fetchmail: POP3> USER username fetchmail: POP3< +OK Name is a valid mailbox fetchmail: POP3> PASS * fetchmail: POP3< +OK Mailbox locked and ready fetchmail: POP3> STAT fetchmail: POP3< +OK 1 1721 fetchmail: POP3> LAST fetchmail: POP3< -ERR Unrecognized command <-------------------this dosent look good lol! fetchmail: Unrecognized command fetchmail: POP3> UIDL fetchmail: POP3< +OK unique-id listing follows fetchmail: POP3< 1 1168033347.4 fetchmail: POP3< . 1 message for cladceil at pop3.mailforyou.co.uk (1721 octets). fetchmail: POP3> LIST 1 fetchmail: POP3< +OK 1 1721 fetchmail: POP3> TOP 1 99999999 fetchmail: POP3< +OK Message follows reading message us...@po...:1 of 1 (1721 octets) fetchmail: SMTP< 220 server.fqdomainnameofserver fetchmail: SMTP> EHLO localhost fetchmail: SMTP< 250-server.fqdomainnameofserver fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250-SIZE 83886080 fetchmail: SMTP< 250-VRFY fetchmail: SMTP< 250-ETRN fetchmail: SMTP< 250-AUTH LOGIN PLAIN fetchmail: SMTP< 250-AUTH=LOGIN PLAIN fetchmail: SMTP< 250 8BITMIME fetchmail: SMTP> MAIL FROM:<su...@ma...> SIZE=1721 fetchmail: SMTP< 250 Ok fetchmail: SMTP> RCPT TO:<postmaster@localhost> fetchmail: SMTP< 250 Ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF> #*************************fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 Ok: queued as 005DC62E02 flushed fetchmail: POP3> DELE 1 fetchmail: POP3< +OK message deleted fetchmail: POP3> QUIT fetchmail: POP3< +OK fetchmail: 6.2.5 querying pop3.mailforyou.co.uk (protocol POP3) at Sun Jan 7 11 :02:12 2007: poll completed fetchmail: SMTP> QUIT fetchmail: SMTP< 221 Bye fetchmail: normal termination, status 0 ----- Original Message ----- From: "Rob MacGregor" <rob...@gm...> To: <fet...@li...> Sent: Sunday, January 07, 2007 11:11 AM Subject: Re: [fetchmail-users] Fetchmail to Postfix > On 1/7/07, Support @ Smart Networking <su...@ma...> wrote: >> Thank you for your quick response. >> >> It still dosent seem to work quite right. Fetchmail downloads the emails >> but >> then tries to deliver them to pos...@lo... instead of >> the >> corresponding user/email address :( > > Right, so how about some of the info the FAQ tells you to provide. At > an absolute minimum: > > 1) Version of fetchmail > > 2) Contents of .fetchmailrc > > 3) Output of "fetchmail -v -v -v" showing the problem > > -- > Please keep list traffic on the list. > > Rob MacGregor > Whoever fights monsters should see to it that in the process he > doesn't become a monster. Friedrich Nietzsche > _______________________________________________ > fetchmail-users mailing list > fet...@li... > https://lists.berlios.de/mailman/listinfo/fetchmail-users > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Rob M. <rob...@gm...> - 2007-01-07 12:13:00
|
On 1/7/07, Support @ Smart Networking <su...@ma...> wrote:
> Thank you for your quick response.
>
> It still dosent seem to work quite right. Fetchmail downloads the emails but
> then tries to deliver them to pos...@lo... instead of the
> corresponding user/email address :(
Right, so how about some of the info the FAQ tells you to provide. At
an absolute minimum:
1) Version of fetchmail
2) Contents of .fetchmailrc
3) Output of "fetchmail -v -v -v" showing the problem
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Support @ S. N. <su...@ma...> - 2007-01-07 12:11:04
|
Thank you for your quick response. It still dosent seem to work quite right. Fetchmail downloads the emails but then tries to deliver them to pos...@lo... instead of the corresponding user/email address :( Kind Regards Phil ----- Original Message ----- From: "Rob MacGregor" <rob...@gm...> To: <fet...@li...> Sent: Sunday, January 07, 2007 9:41 AM Subject: Re: [fetchmail-users] Fetchmail to Postfix > On 1/6/07, Support @ Smart Networking <su...@ma...> wrote: >> >> >> Thanks for the help here's my raw email including headers : >> > <---SNIP---> >> X-Original-To: su...@ma... >> >> Delivered-To: MFY...@ba... > <---SNIP---> > > The "Delivered-To" header is the one you're looking for. You'll want > to read the section titled "The Use and Abuse of Multidrop Mailboxes" > and look at the qvirtual keyword for stripping out the "MFY" part. > > So, something like: > > poll pop.isp.net > qvirtual "MFY" > envelope "Delivered-To" > user remote with password secure to * here > > Should do what you're after, assuming that your local SMTP server is > correctly configured :) > > -- > 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 > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Rob M. <rob...@gm...> - 2007-01-07 10:43:09
|
On 1/6/07, Support @ Smart Networking <su...@ma...> wrote: > > > Thanks for the help here's my raw email including headers : > <---SNIP---> > X-Original-To: su...@ma... > > Delivered-To: MFY...@ba... <---SNIP---> The "Delivered-To" header is the one you're looking for. You'll want to read the section titled "The Use and Abuse of Multidrop Mailboxes" and look at the qvirtual keyword for stripping out the "MFY" part. So, something like: poll pop.isp.net qvirtual "MFY" envelope "Delivered-To" user remote with password secure to * here Should do what you're after, assuming that your local SMTP server is correctly configured :) -- 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: Support @ S. N. <su...@ma...> - 2007-01-06 21:50:23
|
Thanks for the help here's my raw email including headers : Return-Path: <MFYsupport@barracuda> Received: from barracuda ([unix socket]) (authenticated user=mailadmin bits=0) by barracuda (Cyrus v2.2.3) with LMTP; Sat, 06 Jan 2007 20:41:06 +0000 X-Sieve: CMU Sieve 2.2 Return-Path: <su...@ma...> X-Original-To: su...@ma... Delivered-To: MFY...@ba... Received: from mx1.mailforyou.co.uk (mx1.mailforyou.co.uk [82.151.249.74]) by barracuda.mailforyou.co.uk (Postfix) with ESMTP id ECE1A880368 for <su...@ma...>; Sat, 6 Jan 2007 20:41:05 +0000 (GMT) Received-SPF: none (mx1.mailforyou.co.uk: domain of su...@ma... does not designate permitted sender hosts) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.mailforyou.co.uk (Postfix) with ESMTP id 8F6D91C7A25 for <su...@ma...>; Sat, 6 Jan 2007 20:42:56 +0000 (GMT) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <200...@aa...> for <su...@ma...>; Sat, 6 Jan 2007 20:40:06 +0000 Received: from computer ([82.5.58.19]) by aamtaout02-winn.ispmail.ntl.com with SMTP id <20070106204006.XCHO17393.aamtaout02-winn.ispmail.ntl.com@computer> for <su...@ma...>; Sat, 6 Jan 2007 20:40:06 +0000 Message-ID: <002001c731d2$d7659380$0a01a8c0@computer> Reply-To: "Support @ Smart Networking" <su...@ma...> From: "Support @ Smart Networking" <su...@ma...> To: "Support @ Smart Networking" <su...@ma...> Cc: "Support @ Smart Networking" <su...@ma...> Subject: Subject Header Date: Sat, 6 Jan 2007 20:40:00 -0000 Organization: Smart Networking MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C731D2.D5B39DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-mx1.mailforyou.co.uk-MailScanner-Information: Please contact the ISP for more information X-mx1.mailforyou.co.uk-MailScanner: Found to be clean X-mx1.mailforyou.co.uk-MailScanner-From: su...@ma... hope this helps Phil |
|
From: Rob M. <rob...@gm...> - 2007-01-06 20:37:06
|
On 1/6/07, Support @ Smart Networking <su...@ma...> wrote:
> Im finding it hard to decide which is the best solution to use.
> It looks like copies of emails could potentially either disapear into the
> etha
Only if you've managed to completely break your postfix setup.
Fetchmail doesn't lose emails (though see the section on Spam
Filtering - fetchmail *will* drop emails with the same message ID if
it's already seen them).
> or even worse be delivered to a user which should not even receive them
> eg. Bcc
Depends on whether your ISP provides the required headers. If the
email contains no details as to the user it was intended for then
you're out of luck. This is documented in the man page under
"multi-drop".
> What is the best solution ?
Depends on the message headers you have to work with.
> Could you show me the location of a .fetchmailrc script that I could look
> at?
They're in the man page :)
If you could provide a sample header from an email (ideally one BCCd)
then I'm sure somebody can provide something a little more.
--
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: Support @ S. N. <su...@ma...> - 2007-01-06 12:12:04
|
Im finding it hard to decide which is the best solution to use. It looks like copies of emails could potentially either disapear into the etha or even worse be delivered to a user which should not even receive them eg. Bcc What is the best solution ? Could you show me the location of a .fetchmailrc script that I could look at? Thanks Phil ----- Original Message ----- From: Support @ Smart Networking To: fet...@li... Sent: Friday, January 05, 2007 11:24 PM Subject: [fetchmail-users] Fetchmail to Postfix Is it possible to use fetchmail to download from a catch all pop account and then place the downloaded email into postfix for local delivery ISP ------> FETCHMAIL -------> POSTFIX -----------> USERMAIL BOX At present to achieve this I have to download the emails from the ISP to a catch all user account on my local server, then filter them using .forward and a procmail recipe. Is there an easier way to make fetchmail download the emails directly to the local server's mail queue so that postfix can the email to the corresponding local user. (I am running postfix and cyrus) Many thanks in advance. Kind Regards Phil Brooks -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------------ _______________________________________________ fetchmail-users mailing list fet...@li... https://lists.berlios.de/mailman/listinfo/fetchmail-users |
|
From: Matthias A. <mat...@gm...> - 2007-01-06 10:51:22
|
One posting is enough. Support @ Smart Networking schrieb am 2007-01-05: > Is there an easier way to make fetchmail download the emails directly > to the local server's mail queue so that postfix can the email to the > corresponding local user. (I am running postfix and cyrus) yes check the manpage, http://home.pages.de/~mandree/mail/multidrop and fetchmail's envelope option. -- Matthias Andree |
|
From: Support @ S. N. <su...@ma...> - 2007-01-06 00:41:35
|
Is it possible to use fetchmail to download from a catch all pop account and then place the downloaded email into postfix for local delivery ISP ------> FETCHMAIL -------> POSTFIX -----------> USERMAIL BOX At present to achieve this I have to download the emails from the ISP to a catch all user account on my local server, then filter them using .forward and a procmail recipe. Is there an easier way to make fetchmail download the emails directly to the local server's mail queue so that postfix can the email to the corresponding local user. (I am running postfix and cyrus) Many thanks in advance. Kind Regards Phil Brooks |
|
From: Support @ S. N. <su...@ma...> - 2007-01-06 00:30:18
|
Is it possible to use fetchmail to download from a catch all pop account and then place the downloaded email into postfix for local delivery ISP ------> FETCHMAIL -------> POSTFIX -----------> USERMAIL BOX At present to achieve this I have to download the emails from the ISP to a catch all user account on my local server, then filter them using .forward and a procmail recipe. Is there an easier way to make fetchmail download the emails directly to the local server's mail queue so that postfix can the email to the corresponding local user. (I am running postfix and cyrus) Many thanks in advance. Kind Regards Phil Brooks -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Matthias A. <mat...@gm...> - 2007-01-06 00:04:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 fetchmail-SA-2006-02: TLS enforcement problem/MITM attack/password exposure Topics: fetchmail cannot enforce TLS Author: Matthias Andree Version: 1.0 Announced: 2007-01-04 Type: secret information disclosure Impact: fetchmail can expose cleartext password over unsecure link fetchmail may not detect man in the middle attacks Danger: medium Credits: Isaac Wilcox (bug report, testing, collaboration on fix) CVE Name: CVE-2006-5867 URL: http://fetchmail.berlios.de/fetchmail-SA-2006-02.txt Project URL: http://fetchmail.berlios.de/ Affects: fetchmail releases <= 6.3.5 fetchmail release candidates 6.3.6-rc1, -rc2, -rc3 Not affected: fetchmail release candidates 6.3.6-rc4, -rc5 fetchmail release 6.3.6 Corrected: 2006-11-26 fetchmail 6.3.6-rc4 0. Release history ================== 2006-11-16 v0.01 internal review draft 2006-11-26 v0.02 revise failure cases, workaround, add acknowledgments 2006-11-27 v0.03 add more vulnerabilities 2006-01-04 v1.0 ready for release 1. Background ============= fetchmail is a software package to retrieve mail from remote POP2, POP3, IMAP, ETRN or ODMR servers and forward it to local SMTP, LMTP servers or message delivery agents. fetchmail ships with a graphical, Python/Tkinter based configuration utility named "fetchmailconf" to help the user create configuration (run control) files for fetchmail. 2. Problem description and Impact ================================= Fetchmail has had several nasty password disclosure vulnerabilities for a long time. It was only recently that these have been found. V1. sslcertck/sslfingerprint options should have implied "sslproto tls1" in order to enforce TLS negotiation, but did not. V2. Even with "sslproto tls1" in the config, fetches would go ahead in plain text if STLS/STARTTLS wasn't available (not advertised, or advertised but rejected). V3. POP3 fetches could completely ignore all TLS options whether available or not because it didn't reliably issue CAPA before checking for STLS support - but CAPA is a requisite for STLS. Whether or not CAPAbilities were probed, depended on the "auth" option. (Fetchmail only tried CAPA if the auth option was not set at all, was set to gssapi, kerberos, kerberos_v4, otp, or cram-md5.) V4. POP3 could fall back to using plain text passwords, even if strong authentication had been configured. V5. POP2 would not complain if strong authentication or TLS had been requested. This can cause eavesdroppers to obtain the password, depending on the authentication scheme that is configured or auto-selected, and subsequently impersonate somebody else when logging into the upstream server. 3. Workaround ============= If your upstream offers SSLv3-wrapped service on a dedicated port, use fetchmail --ssl --sslcertck --sslproto ssl3 on the command line, or equivalent in the run control file. This encrypts the whole session. 4. Solution =========== Download and install fetchmail 6.3.6 or a newer stable release from fetchmail's project site at <http://developer.berlios.de/project/showfiles.php?group_id=1824>. 5. Acknowledgments ================== Isaac Wilcox has been a great help with testing the fixes and getting them right. A. Copyright, License and Warranty ================================== (C) Copyright 2007 by Matthias Andree, <mat...@gm...>. Some rights reserved. This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs German License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/2.0/de/ or send a letter to Creative Commons; 559 Nathan Abbott Way; Stanford, California 94305; USA. THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES. Use the information herein at your own risk. END OF fetchmail-SA-2006-02.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFntkXvmGDOQUufZURAqVdAKC+UZHUWIZPyp1ZaJdKF4/QUGf/ewCeN8uN objiIGL0OdrSIPZf1smU2vA= =faeY -----END PGP SIGNATURE----- |
|
From: Matthias A. <mat...@gm...> - 2007-01-06 00:03:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 fetchmail-SA-2006-03: crash when refusing message delivered through MDA Topics: fetchmail crashes when refusing a message bound for an MDA Author: Matthias Andree Version: 1.0 Announced: 2007-01-04 Type: denial of service Impact: fetchmail aborts prematurely Danger: low Credits: Neil Hoggarth (bug report and analysis) CVE Name: CVE-2006-5974 URL: http://fetchmail.berlios.de/fetchmail-SA-2006-03.txt Project URL: http://fetchmail.berlios.de/ Affects: fetchmail release = 6.3.5 fetchmail release candidates 6.3.6-rc1, -rc2 Not affected: fetchmail release 6.3.6 Corrected: 2006-11-14 fetchmail SVN 0. Release history ================== 2006-11-19 - internal review draft 2007-01-04 1.0 ready for release 1. Background ============= fetchmail is a software package to retrieve mail from remote POP2, POP3, IMAP, ETRN or ODMR servers and forward it to local SMTP, LMTP servers or message delivery agents. fetchmail ships with a graphical, Python/Tkinter based configuration utility named "fetchmailconf" to help the user create configuration (run control) files for fetchmail. 2. Problem description and Impact ================================= Fetchmail 6.3.5 and early 6.3.6 release candidates, when delivering messages to a message delivery agent by means of the "mda" option, can crash (by passing a NULL pointer to ferror() and fflush()) when refusing a message. SMTP and LMTP delivery modes aren't affected. 3. Workaround ============= Avoid the mda option and ship to a local SMTP or LMTP server instead. 4. Solution =========== Download and install fetchmail 6.3.6 or a newer stable release from fetchmail's project site at <http://developer.berlios.de/project/showfiles.php?group_id=1824>. A. Copyright, License and Warranty ================================== (C) Copyright 2007 by Matthias Andree, <mat...@gm...>. Some rights reserved. This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs German License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/2.0/de/ or send a letter to Creative Commons; 559 Nathan Abbott Way; Stanford, California 94305; USA. THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES. Use the information herein at your own risk. END OF fetchmail-SA-2006-03.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFntkCvmGDOQUufZURApmyAKCV50Rs96vyEl8L8oXsMiIam064IwCg08KI HWQ3SfEpc6WV4bS+xZwWj5g= =JZIR -----END PGP SIGNATURE----- |
|
From: Matthias A. <mat...@gm...> - 2007-01-06 00:00:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings and a happy new year, I am announcing the release of fetchmail 6.3.6. This new stable version of fetchmail fixes a major and a minor security issue (CVE-2006-5867 and CVE-2006-5974), fixes some regressions that appeared in 6.3.5 and other minor bugs. - ----------------------------------------------------------------------- NOTE THAT THE CCIL.ORG MAILING LISTS ARE DEPRECATED AND NO LONGER ACCEPT POSTINGS OR SUBSCRIPTIONS. Please subscribe to the new lists at <https://developer.berlios.de/mail/?group_id=1824>: - - for fetchmail-announce subscribers: subscribe to fetchmail-announce - - for fetchmail-friends subscribers: subscribe to fetchmail-users - ----------------------------------------------------------------------- The software is available from: <http://developer.berlios.de/project/showfiles.php?group_id=1824&release_id=11977> The fetchmail home pages are: <http://www.fetchmail.info/> or <http://fetchmail.berlios.de/> These are the relevant changes in 6.3.6 since 6.3.5; unless otherwise noted, changes to this release were made by Matthias Andree: fetchmail 6.3.6 (released 2007-01-04): # SECURITY FIXES: * CVE-2006-5867, fetchmail-SA-2006-02.txt: Password disclosure vulnerability fixed. This has several aspects: - Fetchmail now implies sslproto 'tls1' if the sslfingerprint or sslcertck options are used and the ssl option is not used, in order to be sure that fetchmail gets a certificate from the mail server. - Fetchmail breaks the connection if the TLS negotiation (or verification, if requested) fails with sslproto 'tls1', sslfingerprint or sslcheck enabled. - POP3 connections now use STLS reliably. They used to ignore STLS altogether for serveral values of the "auth" option, when fetchmail forget to probe server capabilities - see fetchmail-SA-2006-02.txt for details. - POP3 connections will no longer fall back USER/PASS authentication if strong challenge-response authenticators such as CRAM-MD5 are configured but the server does not advertise these in its CAPA response. - POP2 is obsolete and does not support STLS or anything beyond password-based authentication. The attempt to use STLS or strong authenticators now causes connection abort. Configurations using both ssl and sslcertck however have been semi-safe in that they would send the password in the clear. The USER/PASS fallback problem however applies to these too, so that the password was only change on trustworthy servers. * CVE-2006-5974, fetchmail-SA-2006-03.txt: Repairs a regression in 6.3.5 that crashes fetchmail when a message with invalid headers is found while fetchmail's mda option is in use. BerliOS bugs #9364, #9412, #9449. Stack backtrace provided by Neil Hoggarth - thanks. # ADVANCE WARNING OF FEATURES TO BE REMOVED OR CHANGED IN FUTURE VERSIONS: (There are no plans to remove these features from a 6.3.X release, but they may be removed from a 6.4.0 or newer release.) * The MX and host alias DNS lookups that fetchmail performs in multidrop mode are based on assumptions that are rarely met in practice, somewhat defective, deprecated and may be removed from a future fetchmail version. They have never supported IPv6 (including IPv6-mapped IPv4). Non-DNS based alias keywords such as "aka" will remain in fetchmail. * The monitor and interface options may be removed from a future fetchmail version as they are not reasonably portable. * POP2 is obsolete, support will be removed from a future fetchmail version. * RPOP is obsolete, support will be removed from a future fetchmail release. * --sslcertck will become a default setting in a future fetchmail version. * The multidrop To/Cc guessing code along with the fragile duplicate suppressor is deprecated and may be removed from a future release. * The "envelope Received" option may be removed from a future release, because the Received header was never meant to be machine-readable, the format varies widely, and various other differences in behavior make parsing Received an unreliable undertaking. The envelope option as such will remain though, in order to support Delivered-To, X-Envelope-To, X-Original-To and similar. See also <http://home.pages.de/~mandree/mail/multidrop>. * The --enable-fallback (fall back to MDA if MTA unavailable) will be removed from a future fetchmail release, because it makes fetchmail's behavior inconsistent and confusing. * The "protocol auto" default inside fetchmail may be removed from a future fetchmail release. Explicit configuration of the protocol is recommended. * Kerberos IV support may be removed from a future fetchmail release. * SIGHUP wakeup support may be removed from a future fetchmail release and cause fetchmail to terminate - it was broken for many years. * Support for operating systems that are not sufficiently POSIX compliant may be removed or operation on such systems may be suboptimal for future releases. # REGRESSION FIXES (recently introduced bugs): * Repair --logfile, broken in 6.3.5. BerliOS Bug #9059, reported by Brian Harring. * Repair --user, broken in 6.3.5 (as a side effect of the authenticate external patch): using SSL certificate/key authentication overrode the --user option. Now the latter takes precedence, and only defaults to the certificate's common name. Debian Bug #400950, reported by Jorgen Schaefer <fo...@de...>. # BUG FIXES (long-standing bugs): * RPOP: used to log the password locally rather than an asterisk as the other protocols do. The password is now shrouded in the local logs. * POP3: Probes capabilities now when Kerberos V5 is enabled, so that we can actually detect if the server supports it. * Robustness: If a stale lockfile cannot be deleted, truncate it so that fetchmail doesn't later believe itself to be running if the PID is recycled by a non-fetchmail process. * DNS: Detect /etc/resolv.conf changes: On systems that have res_search(), assume we also have res_init() and call it (suggested by Ulrich Drepper, glibc bug #3675) in order to make libc or libresolv reread the resolver configuration at the beginning of a poll cycle. This is important when fetchmail is in daemon mode and /etc/resolv.conf is changed later by dhcpcd, dhclient, pppd, openvpn or other ip-up/ipchange scripts. Should fix Debian Bug#389270, Bug#391698. * Robustness: Fix crash on systems that do not provide strdup(), the crash happens only in out-of-memory conditions when fetchmail cannot proceed anyways. Patch by Andreas Krennmair. * Robustness: When HOME and FETCHMAILHOME are unset, be sure to copy user database information, so it is not trashed later. Patch by Jim Correia. # CHANGES: * Workaround: Improve handling of IMAP IDLE, some servers do not reset their time counters after sending information asynchronously. Patch by Sunil Shetye, after report from Andrew Baumann. * Usability: When requesting Kerberos or GSSAPI, complain and exit with syntax error if any of these requested features has not been compiled in. This is to fail early and with precise error message. Reported by Isaac Wilcox. * --version will now add +KRB4 or +KRB5 if Kerberos v4 or v5, respectively, have been compiled in. Reported missing by Isaac Wilcox. # TRANSLATIONS: * New en_GB (British English) translation by David Lodge. * Update Japanese (Takeshi Hamasaki), Polish (Jakub Bogusz), Russian (Pavel Maryanov) and Vietnamese (Clytie Siddall) translations. ! Note that not all these translations are complete -- this isn't the translators' fault though, but due to delays at the BerliOS hosting site and the translation project handlers. You may see a few untranslated messages. # DOCUMENTATION: * Dropped exit status 15 from manual page, it's not used by fetchmail. Reported by Isaac Wilcox. * Documented exit codes 24 - 29 as internal. # KNOWN BUGS AND WORKAROUNDS: (this section floats upwards through the NEWS file so it stays with the current release information) * fetchmail does not handle messages without Message-ID header well (See sourceforge.net bug #780933) * Sun Workshop 6 (SPARC) is known to miscompile the configuration file lexer in 64-bit mode. Either compile 32-bit code or use GCC to compile 64-bit fetchmail. Note that fetchmail doesn't take advantage of 64-bit code, so compiling 32-bit SPARC code should not cause any difficulties. * fetchmail expects Received: headers in a particular, but undocumented, format when parsing envelopes. * fetchmail does not track pending deletes over crashes * the command line interface is a bit narrow-minded sometimes, for instance, fetchmail -s doesn't work with a running daemon * some of the logging output is not very helpful * some of the documentation is still not up to date Regards, - -- Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFnthUvmGDOQUufZURAqyCAJ9M9o7uj3rH4cnU7teWvqQdb6vjQgCg7v0L OaufKzrR7WwaKC28lUepevw= =3FrE -----END PGP SIGNATURE----- |
|
From: Rob M. <rob...@gm...> - 2007-01-04 08:40:59
|
On 1/3/07, Thomas Isenbarger <is...@ch...> wrote:
> I am still having problems with fetchmail and my 3 mail servers. I
> have read the Retrieval Failure Modes section of the fetchmail man
> page, but I still cannot solve my problem. I was able to use nmap to
> determine that the servers I am polling are all pop3, so the issues
> with pop2 listed in that section of the man page are not relevant.
You obviously missed the FAQ about the information needed :-) I'd
point you at the online one, but currently the people that host the
fetchmail website are off the air.d
> Do you have any other advice for using nmap to troubleshoot this?
You're over complicating the solution, honestly.
> Any other suggestions?
Yeah, read the man page :)
> Below is my original message describing the problem. In short, I
> receive all mail from the the 2 problematic servers every time I poll
> them. I only want to receive unread mail.
Try the UIDL option (as specified in the description of the "keep"
keyword in the man page).
> I check my mail from a number of computers, and I want all my mail to
> be available to all the computers, but have each computer only
> download the mail that is new for that particular computer (but which
> I may have read on another one already)
UIDL is the *ONLY* way forwards if you're using POP. Without it then
the server tracks state, which isn't what you want. Quoting the man
page:
| (Keyword: uidl) Force UIDL use (effective only with POP3).
| Force client-side tracking of 'newness' of messages (UIDL stands
| for "unique ID listing" and is described in RFC1939). Use with
| 'keep' to use a mailbox as a baby news drop for a group of
| users.
> defaults
> no fetchall
This is already a fetchmail default, there's no need to specify it.
> poll server1
> protocol pop3
For a (2 line) shorter .fetchmailrc you may as well specify pop3 as
the default protocol since all your remote servers use it.
--
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: Thomas I. <is...@ch...> - 2007-01-04 02:11:55
|
I am still having problems with fetchmail and my 3 mail servers. I have read the Retrieval Failure Modes section of the fetchmail man page, but I still cannot solve my problem. I was able to use nmap to determine that the servers I am polling are all pop3, so the issues with pop2 listed in that section of the man page are not relevant. For the 2 servers that give me trouble, nmap says they are pop3, but cannot determine the server info from the fingerprint. For the server that works correctly, nmap says it is pop3d (notice the 'd') and that it is a Novell Groupwise server. Do you have any other advice for using nmap to troubleshoot this? Any other suggestions? Below is my original message describing the problem. In short, I receive all mail from the the 2 problematic servers every time I poll them. I only want to receive unread mail. -------- I have my .fetchmailrc set to poll 3 mail servers (like below but without the specific servers, usernames, and passwords). As you can see I have all three servers set up the same way. However, both servers 1 and 3 always download all my mail whether it was read previously or not. server2 skips downloading previously read messages and only downloads mail that is new since the last fetch. Because I have the three set up the same here in my .fetchmailrc, there must be something specific to the servers that causes this behavior. 1) How can I figure out the nature of the servers on the other end? And, 2) What can I do in my .fetchmailrc file to make fetchmail skip downloading previously read messages for all servers? I check my mail from a number of computers, and I want all my mail to be available to all the computers, but have each computer only download the mail that is new for that particular computer (but which I may have read on another one already) Thanks in advance, isen defaults no fetchall keep limit 500000 set postmaster "username" set bouncemail poll server1 protocol pop3 user username1 password 'pass1' poll server2 protocol pop3 user username2 password 'pass2' poll server3 protocol pop3 user username3 password 'pass3' |
|
From: Matthias A. <mat...@gm...> - 2006-12-23 01:30:18
|
regisr schrieb am 2006-12-19: > I have a trouble with encoded character on subject line and I would > check where is the problem. > Could fetchmail (version 6.3.5+RPA+SDPS+SSL+OPIE+NLS) change the > text on Subject header? Not in the way you describe the result. It's probably the software that fetchmail forwards to. -- Matthias Andree |
|
From: regisr <re...@po...> - 2006-12-19 22:27:29
|
Hi, I have a trouble with encoded character on subject line and I would check where is the problem. Could fetchmail (version 6.3.5+RPA+SDPS+SSL+OPIE+NLS) change the text on Subject header? If the subject begin by "[OK-" (without ") it becomes "W09LLUxJ" ... any idea to help me? -- regis |
|
From: Matthias A. <mat...@gm...> - 2006-12-19 02:15:35
|
Jim Correia <jim...@po...> writes: > It looks like env.c:105 sets up the user global by making a copy > > user = xstrdup(pwp->pw_name); > > but env.c:111 does not make a copy when setting up the home global > > home = pwp->pw_dir; > > The memory pointed at by home later gets modified because fetchmail > calls getpwname at fetchmail.c:1214 (after setting up the globals. > > The man page for getpwnam says: > > The functions getpwent(), getpwnam(), and getpwuid(), leave their > results > in an internal static object and return a pointer to that object. > Subse- > quent calls to the same function will modify the same object. > > Patch attached. I've taken the patch, thank you! Unfortunately, the patch isn't part of -rc5, but will become part of 6.3.6. Best, -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2006-12-19 01:43:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, After several more bugs had to be fixed, I have uploaded the fifth fetchmail 6.3.6 release candidate to the usual download location: <http://home.pages.de/~mandree/fetchmail/> - this should become the final 6.3.6 release soon. It fixes the --sslcert vs. --user regression seen in 6.3.5, it fixes the long-standing "doesn't detect /etc/resolv.conf changes" issue that broke DNS resolving on so many systems, makes IMAP IDLE handling more robust vs. server timeouts and adds a few other minor changes - see the next section for details. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ fetchmail 6.3.6-rc5 changes (versus -rc4) are: # REGRESSION FIX: * In 6.3.5 (as a side effect of the authenticate external patch), using SSL certificate/key authentication overrode the --user option. Now the latter takes precedence, and only defaults to the certificate's common name. Debian Bug #400950, reported by Jorgen Schaefer <fo...@de...>. # BUG FIXES: * On systems that have res_search(), assume we also have res_init() and call it (suggested by Ulrich Drepper, glibc bug #3675) in order to make libc or libresolv reread the resolver configuration at the beginning of a poll cycle. This is important when fetchmail is in daemon mode and /etc/resolv.conf is changed later by dhcpcd, dhclient, pppd, openvpn or other ip-up/ipchange scripts. Should fix Debian Bug#389270, Bug#391698. * Fix crash on systems that do not provide strdup(), the crash then happens in out-of-memory conditions. Patch by Andreas Krennmair. # CHANGES: * Remove excess no-op strcpy() after strdup() found by Andreas Krennmair. * Remove handling for PS_TRUNCATED (code 27), which was never asserted. * Improve handling of IMAP IDLE, some servers do not reset their time counters after sending information asynchronously. Patch by Sunil Shetye, after report from Andrew Baumann. * When requesting Kerberos V4, V5 or GSSAPI, complain and exit with syntax error if any of these requested features has not been compiled in. Reported by Isaac Wilcox. * --version will now add +KRB4 or +KRB5 if Kerberos v4 or v5, respectively, have been compiled in. Reported by Isaac Wilcox. # DOCUMENTATION: * Dropped exit status 15 from manual page, it's not used by fetchmail. Reported by Isaac Wilcox. * Documented exit codes 24 - 29 as internal. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This message sets the Reply-To: header. When replying to me personally, you need to edit the To: header! Thank you. Happy fetching, Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFhzVfvmGDOQUufZURAqM3AJ94TzwwVttbLXy1IFM4/dXvoj4jtgCgxZdm ATncf/Di6YiqLUddIrBpZ3Q= =2tcR -----END PGP SIGNATURE----- |
|
From: Matthias A. <mat...@gm...> - 2006-12-16 01:39:22
|
Andrew Baumann schrieb am 2006-12-15: > Thanks, this seems to have fixed it. With your patch, fetchmail now terminates > and restarts the IDLE command before the server's time out. Thanks Sunil for the patch, which I've merged into SVN. Thanks Andrew for trying it out and the feedback. Best regards, -- Matthias Andree |
|
From: Andrew B. <an...@cs...> - 2006-12-14 22:45:18
|
On Thursday 14 December 2006 20:57, Sunil Shetye wrote: > > Dec 10 16:52:32 zarquon fetchmail[28439]: IMAP< * OK Still here > > Dec 10 16:54:32 zarquon fetchmail[28439]: re-poll failed > > Dec 10 16:54:32 zarquon fetchmail[28439]: socket error while fetching > > from an...@im... > > The intermediate messages from the IMAP server are causing the timeout > to be reset. Please try this patch: Thanks, this seems to have fixed it. With your patch, fetchmail now terminates and restarts the IDLE command before the server's time out. Andrew |
|
From: Sunil S. <sh...@bo...> - 2006-12-14 10:58:04
|
Quoting from Andrew Baumann's mail on Wed, Dec 13, 2006:
> > The server MAY consider a client inactive if it has an IDLE command
> > running, and if such a server has an inactivity timeout it MAY log
> > the client off implicitly at the end of its timeout period. Because
> > of that, clients using IDLE are advised to terminate the IDLE and
> > re-issue it at least every 29 minutes to avoid being logged off.
> > This still allows a client to receive immediate mailbox updates even
> > though it need only "poll" at half hour intervals.
>
> I've had a quick look in the fetchmail source, and there is some code there
> that claims to do something after 28 minutes, but it doesn't appear to be
> working. Here is the syslog output of fetchmail running, that shows the
> socket being closed 30 minutes after fetchmail last said anything:
>
> Dec 10 16:24:30 zarquon fetchmail[28439]: IMAP> A0013 IDLE
> Dec 10 16:24:31 zarquon fetchmail[28439]: IMAP< + idling
> Dec 10 16:26:31 zarquon fetchmail[28439]: IMAP< * OK Still here
...
> Dec 10 16:52:32 zarquon fetchmail[28439]: IMAP< * OK Still here
> Dec 10 16:54:32 zarquon fetchmail[28439]: re-poll failed
> Dec 10 16:54:32 zarquon fetchmail[28439]: socket error while fetching from
> an...@im...
The intermediate messages from the IMAP server are causing the timeout
to be reset. Please try this patch:
Index: fetchmail-6.3/imap.c
===================================================================
--- fetchmail-6.3/imap.c (revision 4989)
+++ fetchmail-6.3/imap.c (working copy)
@@ -46,7 +46,8 @@
static int actual_deletions = 0;
/* for "IMAP> IDLE" */
-static int saved_timeout = 0;
+static int saved_timeout = 0, idle_timeout = 0;
+static time_t idle_start_time = 0;
static int imap_ok(int sock, char *argbuf)
/* parse command response */
@@ -163,6 +164,15 @@
return(PS_LOCKBUSY);
}
}
+
+ if (stage == STAGE_IDLE)
+ {
+ /* reduce the timeout: servers may not reset their timeout
+ * when they send some information asynchronously */
+ mytimeout = idle_timeout - (time((time_t *) NULL) - idle_start_time);
+ if (mytimeout <= 0)
+ return(PS_IDLETIMEOUT);
+ }
} while
(tag[0] != '\0' && strncmp(buf, tag, strlen(tag)));
@@ -676,7 +686,8 @@
/* special timeout to terminate the IDLE and re-issue it
* at least every 28 minutes:
* (the server may have an inactivity timeout) */
- mytimeout = 1680; /* 28 min */
+ mytimeout = idle_timeout = 1680; /* 28 min */
+ time(&idle_start_time);
stage = STAGE_IDLE;
/* enter IDLE mode */
ok = gen_transact(sock, "IDLE");
@@ -704,7 +715,8 @@
* notification out of the blue. This is in compliance
* with RFC 2060 section 5.3. Wait for that with a low
* timeout */
- mytimeout = 28;
+ mytimeout = idle_timeout = 28;
+ time(&idle_start_time);
stage = STAGE_IDLE;
/* We are waiting for notification; no tag needed */
tag[0] = '\0';
===================================================================
--
Sunil Shetye.
|
|
From: Andrew B. <an...@cs...> - 2006-12-12 23:29:14
|
Hi, I'm trying to use fetchmail 6.3.5 to grab mail off a Dovecot IMAP server, and I want it to use IDLE. This works fine if I keep receiving the occasional email, however after 30 minutes of idling with no activity dovecot closes the connection and exits. According to the IDLE RFC, this is correct: > The server MAY consider a client inactive if it has an IDLE command > running, and if such a server has an inactivity timeout it MAY log > the client off implicitly at the end of its timeout period. Because > of that, clients using IDLE are advised to terminate the IDLE and > re-issue it at least every 29 minutes to avoid being logged off. > This still allows a client to receive immediate mailbox updates even > though it need only "poll" at half hour intervals. I've had a quick look in the fetchmail source, and there is some code there that claims to do something after 28 minutes, but it doesn't appear to be working. Here is the syslog output of fetchmail running, that shows the socket being closed 30 minutes after fetchmail last said anything: Dec 10 16:24:30 zarquon fetchmail[28439]: IMAP> A0013 IDLE Dec 10 16:24:31 zarquon fetchmail[28439]: IMAP< + idling Dec 10 16:26:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:28:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:30:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:32:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:34:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:36:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:38:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:40:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:42:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:44:31 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:46:32 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:48:32 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:50:32 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:52:32 zarquon fetchmail[28439]: IMAP< * OK Still here Dec 10 16:54:32 zarquon fetchmail[28439]: re-poll failed Dec 10 16:54:32 zarquon fetchmail[28439]: socket error while fetching from an...@im... The contents of my .fetchmailrc are (I am using an SSH tunnel): > set no bouncemail > set syslog > set no showdots > > poll imap.cse.unsw.edu.au > protocol imap > preauth ssh > plugin "ssh -T cse-imap" > idle > no rewrite > fetchall The other info asked for in the FAQ about reporting bugs follows: > Your operating system. Linux-2.6.18-1.2849.fc6 > Your compiler version, if you built from source gcc (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30) > A copy of your POP or IMAP server's greeting line. * PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS] Logged in as andrewb > The name and version of the SMTP listener or MDA you are forwarding to. sendmail 8.13.8-2 (I don't think this is relevant) > Any command-line options you used. In the example, -Nvvv, but I normally run with -d 900, and it also happens then. > The output of fetchmail -V called with whatever other command-line options you used. See attached. Regards, Andrew |
|
From: Jim C. <jim...@po...> - 2006-12-06 19:27:11
|
I was successfully using fetchmail 6.3.4 (Apple built/shipped) on Mac
OS X 10.4.8 (ppc), launched at startup by launchd.
I migrated over to Mac OS X 10.4.8 (i386). fetchmail 6.3.4 (Apple
built/shipped) failed to work, reporting that it couldn't create
the .fetchmail.pid file. (In actually debugging the problem, it was
created in / because fmhome was an empty string - details below.)
I'm launching fetchmail with launchd, using it in nodetach daemon
mode. HOME and FETHMAILHOME are *not* set in the environment.
It looks like env.c:105 sets up the user global by making a copy
user = xstrdup(pwp->pw_name);
but env.c:111 does not make a copy when setting up the home global
home = pwp->pw_dir;
The memory pointed at by home later gets modified because fetchmail
calls getpwname at fetchmail.c:1214 (after setting up the globals.
The man page for getpwnam says:
The functions getpwent(), getpwnam(), and getpwuid(), leave
their results
in an internal static object and return a pointer to that
object. Subse-
quent calls to the same function will modify the same object.
Patch attached.
|
|
From: Rob M. <rob...@gm...> - 2006-12-05 19:08:22
|
As it says in my .sig - keep the traffic on the list. On 12/5/06, Richardus Alim <al...@ga...> wrote:> > The reason I wanted to disable DNS lookups because mail.xyz.com is never > registered in internet DNS, do you have another clue so that I can retrive > my mail (from mail.test.com to mail.xyz.com) without get notify bounced > (host or domain name not found) since mail.xyz.com never exit in internet? Well, *something* is telling fetchmail about mail.xyz.com, but because you're obscuring domains I can't help further. Of course, you could simply drop the @xyz.com stuff as it's not necessary unless you've got a setup that requires you specify the domain as you're handling multiple domains. > I've try setup a DNS server in my local MTA but seemed not successfully :p Well, the DNS server has nothing to do with your MTA - it's merely a service the MTA uses. Take your choice of any of the DNS server options available for your (unspecified) OS and follow their instructions. -- 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 |