Stuart D Gathman schrieb am 04.11.2022 17:51 (GMT +01:00): > On Thu, 3 Nov 2022, Nils wrote: > >> The problem is probably Void Linux specific, since I don't have this >> problem on a OpenBSD installation. > >> P.S.: This is a cross-post of >> https://github.com/void-linux/void-packages/issues/39918 > > I did some research and reported on the github issue. > > Summary: > > The Received header field should use -0000, not +0000 when localtime is > not actually UTC. But Received should not necessarily be in localtime. > > NOTE: I am not an opensmtpd dev - just use it for fully decentralized > email (raw IPv6 on encrypted mesh vpn to avoid DNS and TLS cabal > cancelation). > >
I investigated this a bit further meanwhile (more details also in the Github issue). Obviously the cause for the wrong time zone lies in the chroot which OpenSMTPd does after start. After that the file /etc/localtime (where the system time zone is set) can't be read anymore from the chroot'ed process. As a result the libc function localtime() returns the time in UTC, because the system time zone can't be determined. To proof this I did the following: The chroot directory of OpenSMTPd is /var/empty. I made a subdirectory "etc" in /var/empty, copied the file /usr/share/zoneinfo/Europe/Berlin into /var/empty/etc and renamed this file to "localtime". The result is that now the times are in my systems time zone (CET) as expected. Thus the problem is that the chroot'ed processes have no access anymore to /etc/locatime (which is then outside of the chroot) and therefore can't determine the system time zone. My above solution is of course only an ugly workaround. What would be a clean solution? And why does this problem occur in Linux, but *not* in OpenBSD?
