Dates used by spammers in e-mail headers

[cppgenius]

I can't seem to get it. Why do spammers fiddle with the dates of e-mails, like using non-existent dates, future dates or dates going back more than 20 years?

SpamAssassin uses a 96 hour age test, is this an industry standard, or do you get spam filters working with a shorter time frame?

I mean if you know it's going to trigger a spam filter, what is the use of the technique, or are these spammers simply waaaaay behind technology?

[Lking]

my guess is that the spammer doesn't care. It is just that the system clock on the zombie system is wrong.

What do you expect? Someone doesn't know that their PC is pumping out spam, why would they care about the clock?

[cppgenius]

Someone doesn't know that their PC is pumping out spam, why would they care about the clock?

That might explain dates in the past and perhaps dates in the future, but how do you get a system to send an e-mail on 35 August 2007, that means the header was forged and not due to an incorrect system clock?

[Telarin]

Maybe the idea is to confuse some spam filters enough that they give up and just let the message through. I know there are some older systems out there that if they are unable to filter a message for some reason, they just let it pass through unchecked.

[rconner]

That might explain dates in the past and perhaps dates in the future, but how do you get a system to send an e-mail on 35 August 2007, that means the header was forged and not due to an incorrect system clock?

One of the first things you have to learn in POSIX programming is how to manipulate time_t values. If you don't do it correctly, you can get weird dates like those described here.

Unless you use a really nitpicky conversion function, it is actually possible to produce text dates of this sort, and even to convert them back to normal time_t values.

One very common error I used to see was when the year was exactly 1900 years behind; this happens when a newbie would-be H4X0R forgets that he must add 1900 to the year value when you decode a time_t by hand.

Poorly-set, drifting, or battery-dead system clocks on zombie senders are certainly a factor here, but the strange date constructions probably come from faulty programming.

-- rick