Expire message (incorrectly?) shown

[exussum12]

dkim_verifier/modules/dkim/verifier.mjs.js

Lines 996 to 1001 in 5eb1112

	const time = Math.round(Date.now() / 1000);
	// warning if signature expired
	if (this._header.x !== null && this._header.x < time) {
	this._header.warnings.push({ name: "DKIM_SIGWARNING_EXPIRED" });
	log.debug("Warning: DKIM_SIGWARNING_EXPIRED");
	}

https://www.rfc-editor.org/rfc/rfc6376.html

x= Signature Expiration (plain-text unsigned decimal integer;
RECOMMENDED, default is no expiration). The format is the same as
in the "t=" tag, represented as an absolute date, not as a time
delta from the signing timestamp. The value is expressed as an
unsigned integer in decimal ASCII, with the same constraints on
the value in the "t=" tag. Signatures MAY be considered invalid
if the verification time at the Verifier is past the expiration
date. The verification time should be the time that the message
was first received at the administrative domain of the Verifier if
that time is reliably available; otherwise, the current time
should be used. The value of the "x=" tag MUST be greater than
the value of the "t=" tag if both are present.

This should probably use Delivery-date header first and fall back to current time ?

[lieser]

Thanks for bringing this up.

To use the current time was a deliberate choice as I wanted to rely on the message content as less as possible, so that the user does not have to trust the source of there they got the mail from, i.e. in most cases the server.
Note that I'm aware that in practice most people actually do trust their mail server.

But I noticed that in the last months I got more messages with an expiration time, which was already exceeded at the time I viewed the message.
So I was already thinking if the behavior could improve, as this could lead to people starting to simply ignore this warning or even warnings in general.

Regarding the Delivery-date Header, do you have messaged with it? To me it does not look like a standard Header, and not one I see in my messages.
Probably the best we can do is trying to extract the received time from the last Received Header.

[exussum12]

https://www.rfc-editor.org/rfc/rfc4021.html#page-30

Just checked and you are right, it's not everywhere.

An example is
Delivery-date: Fri, 16 Sep 2022 08:43:02 +0000

I think parsing the received header is probably the only standard place, but its not presented as nicely there

[lieser]

The time in the last Received header will now be used as the verification time.