Re: Wrong timestamp added by sendmail in Received: header?

Bill Cole <[email protected]> Mon, 24 Mar 2025 15:37:16 -0400
Newsgroups	gmane.mail.spam.spamassassin.general
Message-ID	<[email protected]>
On 2025-03-24 at 10:19:40 UTC-0400 (Mon, 24 Mar 2025 15:19:40 +0100)
Andreas Haumer <[email protected]>
is rumored to have said:

> Hi!
>
> Recently I noticed a (at least for me) very strange problem
> with a mailserver running sendmail + SpamAssassin: sometimes
> (not always!) the Received: header inserted by sendmail is completely wrong,
> triggering SpamAssassin rules like "T_DATE_IN_FUTURE_96_Q"

There's no way for SpamAssassin to detect an insane MTA. It cannot do anything else when it sees a bogus date inserted by a trusted source.

> More details: this is an internet-facing mail MX, currently running Debian 10
> with sendmail 8.15.2 and spamass-milter 0.4.0
>
> This server is the primary MX for some domains and thus receives almost
> all mail for that domains. For spam filtering purposes, it connects
> to a SpamAssassin server using spamass-milter. Mails above a given
> spam score are rejected, all other mail is forwarded to some internal
> mail server for further processing.
>
> The system also uses milters for DKIM, SPF and DMARC functionality,
> resulting in the following sendmail config:

[ many details read but elided for readability... ]

[...]
> This mail was actually received today at 09:27:30, according to the mailserver logfile:

[...]
> But this time sendmail added the timestamp "Fri, 13 Dec 2024 10:41:57 +0100"

[...]

> which of course is a bad thing...
>
> Now: "Fri, 13 Dec 2024 10:41:57 +0100" is actually the exact timestamp the machine was last rebooted!
>
> root@bernhard:~# last reboot
> reboot   system boot  4.19.0-27-amd64  Fri Dec 13 10:41   still running
>
> So it looks like sendmail(really?) sometimes(why?) doesn't add the current timestamp
> (as one would expect), but the timestamp the process was started to the Received: header.

That definitely sounds like a Sendmail problem... I don't much use Sendmail these days, but I've never seen anything like that and don't have an explanation for what happened.

> This really puzzles me. I haven't found an explanation for that behaviour, much less a
> rule, under which circumstances it happens.

Can you share all of the headers for that mis-timestamped message? There might be a clue in a prior Received header. (grasping at straws...)

The timestamp embedded in the Sendmail Queue-ID translates to Mon Mar 24 08:27:29 UTC 2025, so that is when the queue files were created.

> This server setup is in use for some time now, but I noticed this problem only recently.
> Usually, security updates require servers to be rebooted from time to time. But this
> particular server now is running since last December and SpamAssassin recently started
> to trigger the T_DATE_IN_FUTURE_96_Q rule, resulting in more and more FalsePositives,
> so I investigated and found this problem.
>
> Of course I could restart sendmail, or even disable the T_DATE_IN_FUTURE_* rules,
> but I'd rather find out what is going on here and fix the real problem.

It is absolutely a problem in Sendmail or possibly in spamass-milter (which IS NOT part of SpamAssassin.) Under no circumstances will SA itself modify a Received header, however it may be the milter rather than Sendmail actually constructing that header.

> I'm not sure if this has anything to do with SpamAssassin at all, so this might be
> the wrong place to report. But if anyone on this list has any clue of what is going
> on here I'd be happy if he or she could give me a hint.

It is out of scope for SpamAssassin, which does not trust Received headers not written by hosts in trusted_networks and NEVER modifies one.

Some milters (e,g. MIMEDefang) call SA only after prepending an artificial Received header for the current transaction. I would expect that spamass-milter needs to do the same. How it is picking the reboot time for that header is beyond my imagination.


-- 
 Bill Cole
 [email protected] or [email protected]
 (AKA @[email protected] and many *@billmail.scconsult.com addresses)
 Not Currently Available For Hire
signature.asc (application/pgp-signature, 285 B)