fetchmail: Update to version 6.4.34

  - Update from version 6.4.32 to 6.4.34
- Update of rootfile not required.
- Changelog
    Fetchmail Release Notes
	# ADVANCE WARNING OF FEATURES TO BE REMOVED OR CHANGED IN FUTURE VERSIONS
		(There are no plans to remove features from a 6.4.X release, but they may be
		removed from a 6.5.0 or newer release.)
		* Future fetchmail releases may require compilers and operating systems
		  that adhere to standards issued 2011 or later.
		  (Currently, C89 and Single Unix Specification V2 should suffice.)
		* Future fetchmail releases may tighten up security and lean towards
		  it a bit more by, for instance, implementing recommendations from
		  RFC-7817 or RFC-8314. This may, for instance, require that TLS v1.1
		  or newer be used.
		* 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 across operating systems.
		* POP2 is obsolete, support will be removed from a future fetchmail version.
		* IMAP2 and IMAP4 (not IMAP4r1) are obsolete, support may be removed from a
		  future fetchmail version.
		* RPOP is obsolete, support will be removed from a future fetchmail release.
		* 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.
		* Kerberos 5 support may be removed from a future fetchmail release.
		* The --principal option 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.
		  This means that fetchmail may only continue to work on C99 and POSIX 2001
		  based systems.
		* The maintainer may migrate fetchmail to C++ with STL or C#, and impose further
		  requirements (dependencies), such as Boost or other class libraries.
		* The softbounce option default will change to "false" in the next release.
		* The --bsmtp - mode of operation may be removed in a future release.
		* SSLv3 support may be removed from a future fetchmail release. It has been
		  obsolete for many years and found insecure. Use TLS.
		* Fetchmailconf is deprecated and will be removed from a future release.
		* Fetchmail does not guarantee compatibility with EOL OpenSSL versions. Support
		  for end-of-life OpenSSL versions may be removed even from patchlevel releases.
		* Nonstandard authentication schemes (such as RPA) may be removed from future
		  fetchmail versions.
		* Nonstandard protocol extensions (such as SDPS/*ENV) may be removed from future
		  fetchmail versions.
		* Future fetchmail releases (even minor ones) may change undocumented parts of
		  the .netrc parser in incompatible ways to enhance compatibility with typical
		  ftp(1) .netrc parsers.
		* Apparently OPIE is dying. I only have this support on FreeBSD, and
		  FreeBSD 14 (slated for release in 2023) is about to remove it.
	# KNOWN BUGS AND WORKAROUNDS
		* Fetchmail does not handle messages without Message-ID header well
		  (See sourceforge.net bug #780933)
		* Fetchmail currently uses 31-bit signed integers in several places
		  where unsigned and/or wider types should have been used, for instance,
		  for mailbox sizes, and misreports sizes of 2 GibiB and beyond.
		  Fixing this requires C89 compatibility to be relinquished.
		* BSMTP is mostly untested and errors can cause corrupt output.
		* Fetchmail does not track pending deletes across 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.
		* For IMAP connections, fetchmail will print "will idle after poll" in
		  verbose mode even though --idle is not given, as an artifact of the 6.4.22
		  security fixes. Fetchmail means "could idle after poll", but this would
		  have required another loop through the translators.
		* aka ... hostnames are not considered for upstream server X.509 certificate
		  verification, aka was meant for alias detection with multidrop mailboxes.
		* When compiled against wolfSSL, some diagnostics and messages of fetchmail are
		  hardcoded to read "OpenSSL"; this was found only after the call for
		  translations had been sent out already.
		* FreeBSD's OPIE implementation cannot be found when using a C++ compiler.
		  This should not affect the normal build, which uses a C compiler.
    fetchmail-6.4.34 (released 2022-10-15, 31701 LoC):
	# CRITICAL BUG FIXES:
		* When an SMTP receiver refuses delivery, a message would be deleted from
		  the mail store in spite of a softbounce option that is enabled.
		  Bug report, analysis and patch by Horváth Zsolt. Gitlab, fixes #50.
	# BUILD NOTE:
		* If you are reusing config.cache from prior builds, this may cause
		  issues with finding Python or some libraries.  In case of trouble,
		  remove config.cache and retry.
	# TRANSLATIONS: language translations were updated by this fine person:
		* sr:    Мирослав Николић (Miroslav Nikolić) [Serbian]
    fetchmail-6.4.33 (released 2022-08-27, 31696 LoC):
	# TRANSLATIONS: language translations were updated by this fine person:
		* fr:    Frédéric Marchal [French]
	# CONTRIBUTED SCRIPT CHANGES:
		* contrib/fetchsetup improvements by Matěj Cepl
		* contrib/runfetchmail improvements by Matěj Cepl

Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
 lfs/fetchmail | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
  

Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>

> On 25 Nov 2022, at 17:37, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> - Update from version 6.4.32 to 6.4.34
> - Update of rootfile not required.
> - Changelog
>    Fetchmail Release Notes
> # ADVANCE WARNING OF FEATURES TO BE REMOVED OR CHANGED IN FUTURE VERSIONS
> (There are no plans to remove features from a 6.4.X release, but they may be
> removed from a 6.5.0 or newer release.)
> * Future fetchmail releases may require compilers and operating systems
>  that adhere to standards issued 2011 or later.
>  (Currently, C89 and Single Unix Specification V2 should suffice.)
> * Future fetchmail releases may tighten up security and lean towards
>  it a bit more by, for instance, implementing recommendations from
>  RFC-7817 or RFC-8314. This may, for instance, require that TLS v1.1
>  or newer be used.
> * 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 across operating systems.
> * POP2 is obsolete, support will be removed from a future fetchmail version.
> * IMAP2 and IMAP4 (not IMAP4r1) are obsolete, support may be removed from a
>  future fetchmail version.
> * RPOP is obsolete, support will be removed from a future fetchmail release.
> * 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.
> * Kerberos 5 support may be removed from a future fetchmail release.
> * The --principal option 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.
>  This means that fetchmail may only continue to work on C99 and POSIX 2001
>  based systems.
> * The maintainer may migrate fetchmail to C++ with STL or C#, and impose further
>  requirements (dependencies), such as Boost or other class libraries.
> * The softbounce option default will change to "false" in the next release.
> * The --bsmtp - mode of operation may be removed in a future release.
> * SSLv3 support may be removed from a future fetchmail release. It has been
>  obsolete for many years and found insecure. Use TLS.
> * Fetchmailconf is deprecated and will be removed from a future release.
> * Fetchmail does not guarantee compatibility with EOL OpenSSL versions. Support
>  for end-of-life OpenSSL versions may be removed even from patchlevel releases.
> * Nonstandard authentication schemes (such as RPA) may be removed from future
>  fetchmail versions.
> * Nonstandard protocol extensions (such as SDPS/*ENV) may be removed from future
>  fetchmail versions.
> * Future fetchmail releases (even minor ones) may change undocumented parts of
>  the .netrc parser in incompatible ways to enhance compatibility with typical
>  ftp(1) .netrc parsers.
> * Apparently OPIE is dying. I only have this support on FreeBSD, and
>  FreeBSD 14 (slated for release in 2023) is about to remove it.
> # KNOWN BUGS AND WORKAROUNDS
> * Fetchmail does not handle messages without Message-ID header well
>  (See sourceforge.net bug #780933)
> * Fetchmail currently uses 31-bit signed integers in several places
>  where unsigned and/or wider types should have been used, for instance,
>  for mailbox sizes, and misreports sizes of 2 GibiB and beyond.
>  Fixing this requires C89 compatibility to be relinquished.
> * BSMTP is mostly untested and errors can cause corrupt output.
> * Fetchmail does not track pending deletes across 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.
> * For IMAP connections, fetchmail will print "will idle after poll" in
>  verbose mode even though --idle is not given, as an artifact of the 6.4.22
>  security fixes. Fetchmail means "could idle after poll", but this would
>  have required another loop through the translators.
> * aka ... hostnames are not considered for upstream server X.509 certificate
>  verification, aka was meant for alias detection with multidrop mailboxes.
> * When compiled against wolfSSL, some diagnostics and messages of fetchmail are
>  hardcoded to read "OpenSSL"; this was found only after the call for
>  translations had been sent out already.
> * FreeBSD's OPIE implementation cannot be found when using a C++ compiler.
>  This should not affect the normal build, which uses a C compiler.
>    fetchmail-6.4.34 (released 2022-10-15, 31701 LoC):
> # CRITICAL BUG FIXES:
> * When an SMTP receiver refuses delivery, a message would be deleted from
>  the mail store in spite of a softbounce option that is enabled.
>  Bug report, analysis and patch by Horváth Zsolt. Gitlab, fixes #50.
> # BUILD NOTE:
> * If you are reusing config.cache from prior builds, this may cause
>  issues with finding Python or some libraries.  In case of trouble,
>  remove config.cache and retry.
> # TRANSLATIONS: language translations were updated by this fine person:
> * sr:    Мирослав Николић (Miroslav Nikolić) [Serbian]
>    fetchmail-6.4.33 (released 2022-08-27, 31696 LoC):
> # TRANSLATIONS: language translations were updated by this fine person:
> * fr:    Frédéric Marchal [French]
> # CONTRIBUTED SCRIPT CHANGES:
> * contrib/fetchsetup improvements by Matěj Cepl
> * contrib/runfetchmail improvements by Matěj Cepl
> 
> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
> ---
> lfs/fetchmail | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lfs/fetchmail b/lfs/fetchmail
> index 6a4860e32..e018861f1 100644
> --- a/lfs/fetchmail
> +++ b/lfs/fetchmail
> @@ -26,7 +26,7 @@ include Config
> 
> SUMMARY    = Full-Featured POP and IMAP Mail Retrieval Daemon
> 
> -VER        = 6.4.32
> +VER        = 6.4.34
> 
> THISAPP    = fetchmail-$(VER)
> DL_FILE    = $(THISAPP).tar.xz
> @@ -34,7 +34,7 @@ DL_FROM    = $(URL_IPFIRE)
> DIR_APP    = $(DIR_SRC)/$(THISAPP)
> TARGET     = $(DIR_INFO)/$(THISAPP)
> PROG       = fetchmail
> -PAK_VER    = 12
> +PAK_VER    = 13
> 
> DEPS       =
> 
> @@ -48,7 +48,7 @@ objects = $(DL_FILE)
> 
> $(DL_FILE) = $(DL_FROM)/$(DL_FILE)
> 
> -$(DL_FILE)_BLAKE2 = 5d6311c46053abc2e5b040273f04d9df5e737dcd938d1370bcd84415e422ec6a05126ecb59efcad9254e37338671cf7bfa224ea1015b83e8e93483cbeb033b7a
> +$(DL_FILE)_BLAKE2 = 796972391a0ac2c71382aaaad3d75fd5c10ddcc58807f6c7ef9940907779e0ec0a8403e077b24afd50e1a7df0646e852cba02ba314e99ea423904e9f8288df01
> 
> install : $(TARGET)
> 
> -- 
> 2.38.1
>