Bug 7898 - DATE_IN_PAST depends on faked Received header
Summary: DATE_IN_PAST depends on faked Received header
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (Eval Tests) (show other bugs)
Version: 3.4.2
Hardware: PC Linux
: P2 minor
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-11 22:14 UTC by hitd
Modified: 2021-04-11 22:14 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
spam which prevents DATE_IN_PAST_96_XX text/plain None hitd [NoCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.

Faked
Received: from ec2-3-85-120-74.compute-1.amazonaws.com ([3.85.120.74] 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.