https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7585
--- Comment #4 from RW <[email protected]> --- (In reply to John Hardin from comment #3) > (In reply to RW from comment #2) > > IMO if a received header claims to be later than the first trusted relay it > > should be ignored. > > Bear in mind timezones. Would "more than 12h later" (absent making TZ > adjustments before comparing) reduce the effectiveness of such a check? It already works in epoch seconds. > The sample at hand is *years* later, is that common? This applies to any offset. The offset is calculated between the date header time and the Received header time that closest. The bottom received header is skipped if it has an offset of zero, but otherwise the spammer can just forge a Received header and skip these rules entirely. > It looks like the (un)trusted and internal/external relays pseudoheaders do > not include datetime info. I think just using the top received header would be fine. However it might be better to leave it as it is and have a separate rule to find cases where *both* the date and a received header are well ahead (maybe 24h) of the top received header. This targets a specific spamming trick and not just a client with the wrong time set. -- You are receiving this mail because: You are the assignee for the bug.
