fetchmail 6.3.19 regression/bug fix release

Matthias Andree <[email protected]> Fri, 10 Dec 2010 18:05:06 +0100
Newsgroups gmane.mail.fetchmail.announce
Message-ID <20101210170506.GA24605__9899.05099054358$1292000723$gmane$org@merlin.emma.line.org>
The 6.3.19 release of fetchmail is now available at the usual locations,
including <http://developer.berlios.de/projects/fetchmail>.

The source archive is available at:
<http://developer.berlios.de/projects/fetchmail/fetchmail-6.3.19.tar.bz2>

Here are the release notes:

fetchmail-6.3.19 (released 2010-12-10, 25945 LoC):

# ERRATUM NOTICE ISSUED
* fetchmail 6.3.18 contains several bug fixes that were considered sufficiently
  grave to warrant the issue of an erratum notice, fetchmail-EN-2010-03.txt.

# BUG FIXES
* When specifying multiple local multidrop lists, do not lose wildcard flag.
  (Affects "user foo is bar baz * is joe here")
* In multidrop configurations, an asterisk can now appear anywhere in the list
  of local users, not just at the end.
* In multidrop mode, header parsing is now more verbose in -vv mode, so that it
  becomes possible to see which header is used.
* Make --antispam work from command line (these used to work in rcfiles).
  Reported by Kees Bakker, BerliOS Bug #17599. (Sunil Shetye)
* Smoke test XHTML 1.1 validation, and if it fails, skip validating HTML
  documents.  Skip validating Mailbox-Names-UTF7.html. Several systems have
  broken XHTML 1.1 DTD installations that jeopardize the build.
  Reported by Mihail Nechkin against FreeBSD port.
  Workaround for 6.3.18: build in a separate directory, i. e:
  mkdir build && cd build && ../configure --options-go-here
* Send a NOOP only after a failed STARTTLS in IMAP. (Sunil Shetye)
* Demote GSSAPI verbose/debug syslog to INFO severity. Requested by Carlos E. R.
  and Derek Simkowiak via the fetchmail-users@ mailing list.
* Do STARTTLS/STLS negotiation in IMAP/POP3 if it is mandatory even if the
  server capabilities do not show support for upgradation to TLS.
  To use this, configure --sslproto tls1. (Sunil Shetye)
* IMAP: Understand empty strings as FETCH response, seen on Yahoo. Reported by
  Yasin Malli to fetchmail-users@ 2010-12-10.
  Note that fetchmail continues to expect literals as FETCH response for now.

# DOCUMENTATION
* The manual page now links to IANA for GSSAPI service names.

# TRANSLATION UPDATES
  [cs]    Czech (Petr Pisar)
  [fr]    French (Frédéric Marchal)
  [de]    German
  [it]    Italian (Vincenzo Campanella)
  [pl]    Polish (Jakub Bogusz)

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


By popular demand, diffs from the previous release have been omitted.

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

iEYEARECAAYFAk0CXcIACgkQvmGDOQUufZWEsgCg74iMqWFMdA3X5rJvQCctRI5X
kesAn1RAmglBy7rxDZz/lNDf4+vrrbnJ
=RI1a
-----END PGP SIGNATURE-----