|Summary:||DATE_IN_PAST depends on faked Received header|
|Component:||Rules (Eval Tests)||Assignee:||SpamAssassin Developer Mailing List <dev>|
|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. Faked Received: from ec2-3-85-120-74.compute-1.amazonaws.com ([126.96.36.199] 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 <firstname.lastname@example.org>) 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.