Reviewed-by: Michael Tremer > On 25 Nov 2022, at 17:37, Adolf Belka 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 . > * 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 > --- > 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 >