The “Date:” field is added after the user instructs neomutt to send
their message, so there is no opportunity for the user to edit the
timestamp of the message. Perhaps rightly so, for RFC-compliance.  But
the timestamp that mutt generates exposes the timezone of the
author. It’s too much information.  E.g. this reveals to the recipient
and all mail servers enroute that the sender is physically in the
central Europe timezone:

  Date: Fri, 12 Aug 2022 13:21:24 +0200

This exposes the presence of senders in the eastern US timezone:

  Date: Fri, 12 Aug 2022 13:21:24 -0400

It would be surprising if Google or Microsoft did not exploit that
information in some way.  For privacy, users need control over the
format of that date. The RFC likely dictates the format, but the time
should be expressed in UTC. And UTC should in fact be the *default*
timezone as well.

If a user really wants to reveal the timezone they are in for some
reason (i.e. the status quo), perhaps there should be a new config
parameter for that case.  The parameter could be an enum that enables
you to name a timezone, or perhaps it could be a simple boolean like
“compose_timezone_local” or “compose_timezone_zulu”.

FWIW, it’s perhaps also worth mentioning that it might be useful to be
able to dynamically select the timezone of the /recipient/, as a
courtesy to them in cases where the recipient’s timezone is known by
the sender. Of course that brings in a bit of complexity.

But in any case, the current behavior is a security issue because
confidentiality is compromized.

Hello,

I suggest to unset the local_date_header configuration option.

From the manual:

	3.171. local_date_header

	Type: boolean
	Default: yes

	If set, the date in the Date header of emails that you send will be in your
	local timezone. If unset a UTC date will be used instead to avoid leaking
	information about your current location.

Best regards
Uwe

Hi,

As it's an option that you can set on your config, I'm tagging wontfix.
If you disagree with the Default option, I'd ask you to open an issue
and discuss directly with upstream [1].

Cheers,
Charles

[1] https://github.com/neomutt/neomutt/issues/new?assignees=&labels=type%3Abug&projects=&template=bug-report.md

@Charles,

This is a security problem and defaults are important. The bug is
about the default behavior. Security by default calls for wise
defaults most particularly when there is no compelling justification
for reduced security by default.

MS Github is a place I will not go. It gives me problems.

It’s true that the defect is upstream. But it is also downstream and
the Debian project’s commitment to “provide an integrated system of
high-quality materials”¹ implies security as a goal, at least in my
interpretation. So reguardless of what happens upstream (e.g. if
upstream devs were hypothetically to reject the bug), it should still
be corrected in Debian nonetheless.

That said, I do not mean to impose work on anyone. But /wontfix/ is an
objectionable state for this bug. It should remain a live bug until it
is fixed in Debian (which could happen either by way of upstream
efforts or by a debian maintainer).

① https://www.debian.org/social_contract