From nobody Tue Nov 30 10:28:34 2021 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0F89618B087D for ; Tue, 30 Nov 2021 10:28:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3JN25fX6z3NNB for ; Tue, 30 Nov 2021 10:28:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9F34814AED for ; Tue, 30 Nov 2021 10:28:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1AUASY0O016399 for ; Tue, 30 Nov 2021 10:28:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1AUASYL9016398 for ports-bugs@FreeBSD.org; Tue, 30 Nov 2021 10:28:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 260137] mail/heirloom-mailx: wrong UTC offset in Date header for Europe/Dublin Date: Tue, 30 Nov 2021 10:28:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: a.biardi@tiscali.it X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter flagtypes.name attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports-bugs@freebsd.org X-BeenThere: freebsd-ports-bugs@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638268114; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=mtKBVFPGuZ60Ohj3/yRrVG7YrXBPQ2nknb88MhDgqrc=; b=wEpUtYeZt3xPEPnp0+aY+26cehkkm/1V0yJqakkvdVqt+A1/L3McT9TRLdL7y0+KVqg9BC FdKpqv2VzXkM0bHteD8gHwdfdd6gRmzsrd11ipLUxDSJuMsYD9iXy/CZp0obQTYzlmF6Lk itSFFrB8qLX4Hwk2NzsftQSOLhgHeh5dVub9W/l25jeEuU6+jJlkybYpg2+RtMwk5t7c1Y xMSe87seZguszWmYMlg6BSfkaNP/FObIS+dYK9r6RYqKZfixfgWvdSxcVgKB62haHbaK4Q cyShifnET7MoLElRA9Q6RKIbpBr7x8rxyCM9mocMpTjgfqHe9GXch0PdNRwawQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638268114; a=rsa-sha256; cv=none; b=txN18sTet0kgz1AUKvplIz27wEyj2uA7qdS5lIP+J1mzPK7FP7BZD9OHeLFKA+y468o5/3 0o0a54cdeV5ssMehzKt59e1N7u2m/dAt67t7smSz/UDz18swxXB6G3ZSlJKbc/FEkP5xHV VxQlxOqa24Ti1EdPOod5unsUyf5gDl/pFAoY5CpCR3ejKbrUxHzAyB+0TjSi5XIeSrENAB yjL69QEN4xlyU3+/6yDIRN5QpB0qoi1509oOQVyUnJhEvudECeOi7IUC0TcIH5drNOdFJy pwZ99CYpwQptLr9slmMHg86IDz44MRvbF9bcPQTmLupwz51xh1mL87mjKvtDgQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260137 Bug ID: 260137 Summary: mail/heirloom-mailx: wrong UTC offset in Date header for Europe/Dublin Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: cy@FreeBSD.org Reporter: a.biardi@tiscali.it Flags: maintainer-feedback?(cy@FreeBSD.org) Assignee: cy@FreeBSD.org Created attachment 229808 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D229808&action= =3Dedit correct calculation of GMT/UTC offset I am reporting this bug with the following disclaimer: - I am aware that the default /bin/mail is from a different package, and probably not many people would install the heirloom-mailx port. - I understand heirloom mailx is no longer maintained upstream, hence no ch= ance of getting a patch accepted upstream (I have submitted a patch to its succe= ssor s-nail, whose current code now behaves correctly). The problem is that sending out an email using Heirloom mailx produces a "Date:" header that is incorrect when the system is in the Europe/Dublin timezone (email appears to have been sent 2 hours earlier). My testcase is as follows (forgive a bit of dark magic here): root@mybsd:~ # make -C /usr/ports/mail/heirloom-mailx/ all install clean PREFIX=3D/test [...] root@mybsd:~ # date -R Mon, 29 Nov 2021 18:59:29 +0000 root@mybsd:~ # rm -f ~/dead.letter; env TZ=3DEurope/Dublin /test/bin/mailx = -S sendmail=3Dno-thank-you root < /dev/null; cat ~/dead.letter No message, no subject; hope that's ok no-thank-you: No such file or directory "/root/dead.letter" 8/195 . . . message not sent. Date: Mon, 29 Nov 2021 18:59:29 +0200 To: root User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=3Dus-ascii Content-Transfer-Encoding: quoted-printable =3D The "Date:" header is wrong (compare with "date -R) because of a naive/incorrect handling of tm->tm_isdst that assumes that DST implies +1h.= It turns out that this is not necessarily a correct assumption. A patch is attached. In the interest of readability, I've tried not to be t= oo clever about optimizing out unnecessary variables, etc. (incidentally, the latest version of heirloom mailx is 12.5; I'm not sure where the official sources are now kept, but both https://ftp.debian.org/debian/pool/main/h/heirloom-mailx/heirloom-mailx_12.= 5.orig.tar.gz and https://mirrors.kernel.org/slackware/slackware64-14.2/source/n/mailx/mailx-= 12.5.tar.xz look authentic to me; the latter is slightly more recent). The rest of the text below provides background and context info that might = be useful to others in the future. Somewhere around 2018, the tzdata maintainers (IANA) corrected a historical mistake with the Europe/Dublin timezone. The mistake was rooted in a misunderstanding of whether IST meant "Irish Summer Time" or "Irish Standard Time". The problem was discussed at great length (http://mm.icann.org/pipermail/tz/2018-January/thread.html) and it was concluded that IST really meant Irish *Standard* Time (in constrast with, s= ay, British *Summer* Time), and that this standard time is defined as UTC+0100. This corresponds to the article at https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Ireland and the notes= at https://en.wikipedia.org/wiki/Winter_time_(clock_lag); the source archive of tzdata has a long section dedicated to this problem and a large set of offi= cial references and links to www.irishstatutebook.ie. Once the question was settled, the only possible solution for keeping the I= rish local time in sync with the rest of the world (timezones aside, the local t= ime in Ireland - as understood by common people - is the same as in London and Belfast) was for IANA to _reverse_ the functioning of the DST flag for Irel= and. The result is that in the current IANA timezone database (2021e), Europe/Du= blin has DST applied in *winter*, with an adjustment of -1h (that is, negative). Digging deeper, one uncovers that there are a few other countries that have= (or once had) the same time-switch mechanism as Ireland; amongst others, https://github.com/MenoData/Time4J/issues/742 also concedes that negative D= ST is a reality. In heirloom mailx, the logic that works out the UTC offset does the right t= hing up to a point (November 2021, Ireland =3D UTC+0100), but then upon inspecti= ng tm->tm_isdst it sees that DST is in effect (remember, flag has been reverse= d, so DST in Ireland is on in winter time) it adds one hour (it should subtract one, because the adjustment is negative, but mailx doesn't know). That's why I get a +0200 instead of +0000 out of mailx. You may wonder why this problem hasn't been noticed by Irish people in the = past three years (hey, there's quite an IT industry over here!). It turns out that the introduction of a negative DST adjustment caused all sorts of bugs back in 2018 (mostly with Java); in the source distribution of IANA's tzdata, one can spot this inside ./europe: # In January 2018 we discovered that the negative SAVE values in the # Eire rules cause problems with tests for ICU [...] and with tests # for OpenJDK [...] # To work around this problem, the build procedure can translate the # following data into two forms, one with negative SAVE values and the # other form with a traditional approximation for Irish timestamps # after 1971-10-31 02:00 UTC; although this approximation has tm_isdst # flags that are reversed, its UTC offsets are correct and this often # suffices. [...] So, a temporary hack was put in place so that downstream maintainers could choose whether to retain the old broken convention of IST and support buggy software ("make DATAFORM=3Drearguard"), but it is clear that the current (a= nd technically, and politically, correct) implementation of a negative DST adjustment for Ireland is there to stay (for example, see "PS." under: https://mm.icann.org/pipermail/tz-announce/2019-March/000055.html). FreeBSD is using the correct tzdata representation (aka "vanguard") which exposes the bug in mailx. The solution boils down to correctly calculating the offset between local t= ime and UTC. Having studied the way this is done in a couple of other programs = (for example, postfix) I have concluded that although manual calculation is the = only portable approach, perhaps the best way to address this is to use tm->tm_gmtoff. I know it is a non-standard extension, but I believe it's be= en there in BSD and GNU's glibc for over a decade and there's little reason to reinvent the wheel. --=20 You are receiving this mail because: You are the assignee for the bug.=