fetchmail-users — User questions and discussion

[fetchmail-users] fetchmail security announcement 2006-02 (CVE-2006-5867)

[Matthias A. <mat...@gm...>]

-----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-----

[fetchmail-users] fetchmail security announcement 2006-03 (CVE-2006-5974)

[Matthias A. <mat...@gm...>]

-----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-----

[fetchmail-users] fetchmail 6.3.6 security fix release

[Matthias A. <mat...@gm...>]

-----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-----

Re: [fetchmail-users] server problems

[Rob M. <rob...@gm...>]

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

[fetchmail-users] server problems

[Thomas I. <is...@ch...>]

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'

Re: [fetchmail-users] Character encoding

[Matthias A. <mat...@gm...>]

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

[fetchmail-users] Character encoding

[regisr <re...@po...>]

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

Re: [fetchmail-users] BUG: failure to create fetchmail.pid file

[Matthias A. <mat...@gm...>]

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

[fetchmail-users] fetchmail 6.3.6-rc5 final release candidate

[Matthias A. <mat...@gm...>]

-----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-----

Re: [fetchmail-users] [PATCH] Re: possible bug in IMAP IDLE, connection times out after 30 minutes

[Matthias A. <mat...@gm...>]

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

Re: [fetchmail-users] [PATCH] Re: possible bug in IMAP IDLE, connection times out after 30 minutes

[Andrew B. <an...@cs...>]

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

[fetchmail-users] [PATCH] Re: possible bug in IMAP IDLE, connection times out after 30 minutes

[Sunil S. <sh...@bo...>]

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.

[fetchmail-users] possible bug in IMAP IDLE, connection times out after 30 minutes

[Andrew B. <an...@cs...>]

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

[fetchmail-users] BUG: failure to create fetchmail.pid file

[Jim C. <jim...@po...>]

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.

Re: [fetchmail-users] Fetchmail & Zimbra

[Rob M. <rob...@gm...>]

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

Re: [fetchmail-users] Fetchmail & Zimbra

[Rob M. <rob...@gm...>]

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

[fetchmail-users] Fetchmail & Zimbra

[Richardus A. <al...@ga...>]

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

Re: [fetchmail-users] 'keep' and 'uidl'.

[Stuart J. B. <sjb...@bl...>]

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
> 

Re: [fetchmail-users] 'keep' and 'uidl'.

[Rob M. <rob...@gm...>]

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] 'keep' and 'uidl'.

[Stuart J. B. <sjb...@bl...>]

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)--

Re: [fetchmail-users] fetchmail 6.3.6-rc4 release candidate

[Matthias A. <mat...@gm...>]

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

Re: [fetchmail-users] fetchmail 6.3.6-rc4 release candidate

[Matthias A. <mat...@gm...>]

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

Re: [fetchmail-users] fetchmail 6.3.6-rc4 release candidate

[Volker K. <hi...@pa...>]

> 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.

Re: [fetchmail-users] fetchmail 6.3.6-rc4 release candidate

[Jakob H. <jh...@pl...>]

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.

Re: [fetchmail-users] fetchmail 6.3.6-rc4 release candidate

[Matthias A. <mat...@gm...>]

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