fetchmail 6.3.18 regression/bug fix release

Matthias Andree <[email protected]> Sun, 10 Oct 2010 01:00:15 +0200
Newsgroups gmane.mail.fetchmail.announce
Message-ID <20101009230015.GB7891__7963.34745032272$1286665235$gmane$org@merlin.emma.line.org>
The 6.3.18 release of fetchmail is now available at the usual locations,
including <http://developer.berlios.de/projects/fetchmail>.

It should fix the nasty authentication errors between fetchmail and
Kerberized (GSSAPI) servers, and more issues - detailed below.

The source archive is available at:
<http://prdownload.berlios.de/fetchmail/fetchmail-6.3.18.tar.bz2>

Here are the release notes:

fetchmail-6.3.18 (released 2010-10-09, 25936 LoC):

# SECURITY IMPROVEMENTS TO DEFANG X.509 CERTIFICATE ABUSE
* Fetchmail now only accepts wildcard certificate common names and subject
  alternative names if they start with "*.". Previous versions would accept
  wildcards even if no period followed immediately.
* Fetchmail now disallows wildcards in certificates to match domain literals
  (such as 10.9.8.7), or wildcards in domain literals ("*.168.23.23").
  The test is overly picky and triggers if the pattern (after skipping the
  initial wildcard "*") or domain consists solely of digits and dots, and thus
  matches more than needed.
* Fetchmail now disallows wildcarding top-level domains.

# CRITICAL BUG FIXES AND REGRESSION FIXES
* Fetchmail 6.3.15, 6.3.16, and 6.3.17 would pick up libmd5 to obtain MD5*
  functions, as an effect of an undocumented Solaris MD5 fix.
  This caused all MD5-related functions to malfunction if, for instance,
  libmd5.so was installed on other operating systems as part of libwww on
  machines where long isn't 32-bits, i. e. usually on 64-bit computers.
  Fixes Gentoo Bug #319283, reported, including libwww hint, by Karl Hakimian.
  Side effect: fetchmail will now use -lmd on Solaris rather than -lmd5.
* Fetchmail 6.3.17 warned about insecure SSL/TLS connections even if a matching
  --sslfingerprint was specified. This is an omission from an SSL usability
  change made in 6.3.17.
  Fixes Debian Bug#580796 reported by Roland Stigge.
* Fetchmail will now apply timeouts to the authentication stage.
  This stage encompasses STARTTLS/STLS negotiation in IMAP/POP3.
  Reported missing by Thomas Jarosch.
* Fetchmail now cancels GSSAPI authentication properly when encountering GSS
  errors, such as no or unsuitable credentials.
  It now sends an asterisk on a line by its own, as required in SASL.
    This fixes protocol synchronization issues that cause Authentication
  failures, often observed with kerberized MS Exchange servers.
  Fixes Debian Bug #568455 reported by Patrick Rynhart, and Alan Murrell, to the
  fetchmail-users list. Fix verified by Thomas Voigtmann.

# BUG FIXES
* Fetchmail will no longer print connection attempts and errors for one host
  in "silent" and "normal" logging modes, unless all connections fail. This
  should reduce irritation around refused-connection logging if services are
  only on an IPv4 socket if the host also supports IPv6. Often observed as
  connections refused to ::1/25 when the subsequent connection to 127.0.0.1/25
  then - silently - succeeds.  Fetchmail, unless in verbose mode, will collect
  all connect errors and only report them if all of them fail.
* Fetchmail will not try GSSAPI authentication automatically, unless it has GSS
  credentials. However, if GSSAPI authentication is requested explicitly,
  fetchmail will always try it.
* Fetchmail now parses response to "FETCH n:m RFC822.SIZE" and "FETCH n
  RFC822.HEADER" in a more flexible manner. (Sunil Shetye)
* The manual page clearly states that --principal is for Kerberos 4 only, not
  for Kerberos 5 or GSSAPI. Found by Thomas Voigtmann.

# CHANGES
* When encountering incorrect headers, fetchmail will refer to the bad-header
  option in the manpage.
  Fixes BerliOS Bug #17272, change suggested by Björn Voigt.
* Fetchmail now decodes and reports GSSAPI status codes upon errors.
* Fetchmail now autoprobes NTLM also for POP3.
* The Fetchmail FAQ has a new item #R15 on authentication failures.

# INTERNAL CHANGES
* The common NTLM authentication code was factored out from pop3.c and imap.c.

# TRANSLATION UPDATES
  [zh_CN] Chinese/simplified (Ji Zheng-Yu)
  [cs]    Czech (Petr Pisar)
  [nl]    Dutch (Erwin Poeze)
  [fr]    French (Frédéric Marchal)
  [de]    German
  [it]    Italian (Vincenzo Campanella)
  [ja]    Japanese (Takeshi Hamasaki)
  [pl]    Polish (Jakub Bogusz)
  [sk]    Slovak (Marcel Telka)

# KNOWN BUGS AND WORKAROUNDS:
  (this section floats upwards through the NEWS file so it stays with the
  current release information - however, it was stuck with 6.3.8 for a while)
* fetchmail does not handle messages without Message-ID header well
  (See sourceforge.net bug #780933)
* BSMTP is mostly untested and errors can cause corrupt output.
* 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 does not track pending deletes over crashes.
* the command line interface is sometimes a bit stubborn, for instance,
  fetchmail -s doesn't work with a daemon running.
* Linux systems may return duplicates of an IP address in some circumstances if
  no or no global IPv6 addresses are configured.
  (No workaround. Ubuntu Bug#582585, Novell Bug#606980.)
* Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error
  messages. This will not be fixed, because the maintainer has no Kerberos 5
  server to test against. Use GSSAPI.

-- 
Matthias Andree

_______________________________________________
fetchmail-announce mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/fetchmail-announce
signature.asc (application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkyw8/8ACgkQvmGDOQUufZWtjQCdEnZ2rYXAeQO0fGx0e6TbQeOi
1SQAoJjG4fYyZESfIbhPrd55J/qf295L
=LkOX
-----END PGP SIGNATURE-----