Github messages for voidlinux
 help / color / mirror / Atom feed
From: ffobzb <ffobzb@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: opensmtpd: Does not respect the system time zone in mail header and logfile
Date: Mon, 07 Nov 2022 21:25:00 +0100	[thread overview]
Message-ID: <20221107202500.Fguy5ndnL8iB-a4I-fJjOj5NrS2W3vI2pbubMkxU2ts@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-39918@inbox.vuxu.org>

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

New comment by ffobzb on void-packages repository

https://github.com/void-linux/void-packages/issues/39918#issuecomment-1306145298

Comment:
Thanks a lot for your investigations.

Yes, the Date header isn't from OpenSMTPd, and the Date header is not the problem because it shows local times.

The logging system (socklog) shows the time stamps in UTC, yes. But the time stamps from the processes in the logs use local time. In my example logfile above you can see that when OpenSMTPd starts (PID 2699) it logs correctly with local time, but when processing the mail within a forked process (PID 2703) it jumps to UTC. When stopping the process (PID 2699) it then jumps back to local time.

I don't think that this behaviour is intended or that OpenSMTPd uses generally UTC times in headers. Two reasons for that:
1. In the source code the time stamps for the Received header (and probably also for the logging) are generated in the function `time_to_text` in the source file `to.c`:
```
const char *
time_to_text(time_t when)
{
	struct tm *lt;
	static char buf[40];
	char *day[] = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
	char *month[] = {"Jan","Feb","Mar","Apr","May","Jun",
			 "Jul","Aug","Sep","Oct","Nov","Dec"};
	const char *tz;
	long offset;

	lt = localtime(&when);
	if (lt == NULL || when == 0)
		fatalx("time_to_text: localtime");

#if HAVE_STRUCT_TM_TM_GMTOFF
	offset = lt->tm_gmtoff;
	tz = lt->tm_zone;
#elif defined HAVE_DECL_ALTZONE && defined HAVE_DECL_TIMEZONE
	offset = lt->tm_isdst > 0 ? altzone : timezone;
	tz = lt->tm_isdst > 0 ? tzname[1] : tzname[0];
#endif

	/* We do not use strftime because it is subject to locale substitution*/
	if (!bsnprintf(buf, sizeof(buf),
	    "%s, %d %s %d %02d:%02d:%02d %c%02d%02d (%s)",
	    day[lt->tm_wday], lt->tm_mday, month[lt->tm_mon],
	    lt->tm_year + 1900,
	    lt->tm_hour, lt->tm_min, lt->tm_sec,
	    offset >= 0 ? '+' : '-',
	    abs((int)offset / 3600),
	    abs((int)offset % 3600) / 60,
	    tz))
		fatalx("time_to_text: bsnprintf");

	return buf;
}
```
So the variable `lt` is filled with the libc function `localtime`, then the time zone is extracted etc. The intention is clear: The time stamps should be in the systems time zone. If time stamps should be always just UTC this function would be much simpler.

2. I tested the same on an OpenBSD system with OpenSMTPd. There the Received header and the logging uses time stamps in local time, as expected. And the source code in the concerning areas of `to.c` is the same between the OpenBSD version and the Linux/other version.

Regarding my system config for the time zone: It is set to CET/CEST, because `/etc/localtime` is a symlink to `/usr/share/zoneinfo/Europe/Berlin`, and this means the system is configured to use CET and not UTC.

Is your Fedora installation configured to use UTC as time zone? If no, then that would indicate that the problem is not Void specific, but Linux specific...

A configuration option for the time stamps does not exist - at least not a documented one.

My suspicion is still that the problem has to do with the fork resp. privilege drop to the _smtpd or _smtpq user. Somehow the configured system time zone disappears then.


  parent reply	other threads:[~2022-11-07 20:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 19:48 [ISSUE] " ffobzb
2022-11-04 15:02 ` sdgathman
2022-11-04 15:07 ` sdgathman
2022-11-04 15:17 ` sdgathman
2022-11-04 15:19 ` sdgathman
2022-11-04 16:37 ` sdgathman
2022-11-07 20:25 ` ffobzb [this message]
2023-05-01 15:58 ` vmc-coding
2023-05-01 15:59 ` vmc-coding
2023-05-01 15:59 ` vmc-coding
2024-02-27 20:39 ` ffobzb
2024-02-27 20:41 ` ffobzb

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=20221107202500.Fguy5ndnL8iB-a4I-fJjOj5NrS2W3vI2pbubMkxU2ts@z \
    --to=ffobzb@users.noreply.github.com \
    --cc=ml@inbox.vuxu.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;
as well as URLs for NNTP newsgroup(s).