Bug 7898

Summary: DATE_IN_PAST depends on faked Received header
Product: Spamassassin Reporter: hitd <talk.spamassassin>
Component: Rules (Eval Tests)Assignee: SpamAssassin Developer Mailing List <dev>
Status: NEW ---    
Severity: minor    
Priority: P2    
Version: 3.4.2   
Target Milestone: Undefined   
Hardware: PC   
OS: Linux   
Attachments: spam which prevents DATE_IN_PAST_96_XX

Description hitd 2021-04-11 22:14:38 UTC
Created attachment 5741 [details]
spam which prevents DATE_IN_PAST_96_XX

got spam, which doesn't triggers DATE_IN_PAST_96_XX but should.

Received: from ec2-3-85-120-74.compute-1.amazonaws.com ([] helo=EC2AMAZ-566PBPN.ec2.internal)
	by mail.dr-ph.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.90_1)
	(envelope-from <adrian@dr-ph.com>)
	id 1lMSG7-0009pd-Us; Wed, 17 Mar 2021 17:14:32 +0800

prevents DATE_IN_PAST_96_XX ( or other DATE_IN_PAST tests ), but in real we are weeks later.

Maybe a good solution could be to test the first AND the last received header. Usualy the last received header is a trusted one, because it is our own server.

However, i think, there should be a whole set of IN_PAST_DATE_96_XX ... rules, which are using nearly the same code as yet, except compare with the highest difference after sort, not the lowest one.

In general, compare date-header to date from received which is the nearest one to date AND the one which ist far away from date.