On 2025-03-24 at 10:19:40 UTC-0400 (Mon, 24 Mar 2025 15:19:40 +0100) Andreas Haumer <andr...@xss.co.at> 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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
signature.asc
Description: OpenPGP digital signature
