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