public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] fetchmail: Update to version 6.4.34
Date: Sun, 27 Nov 2022 11:56:07 +0000	[thread overview]
Message-ID: <29D25DD5-D451-4320-9E06-FD51605911FF@ipfire.org> (raw)
In-Reply-To: <20221125173753.3342497-1-adolf.belka@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 8469 bytes --]

Reviewed-by: Michael Tremer <michael.tremer(a)ipfire.org>

> On 25 Nov 2022, at 17:37, Adolf Belka <adolf.belka(a)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(a)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
> 


      reply	other threads:[~2022-11-27 11:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-25 17:37 Adolf Belka
2022-11-27 11:56 ` Michael Tremer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29D25DD5-D451-4320-9E06-FD51605911FF@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox