Hi All,

I'm pretty much a linux newbie so please go easy. I'm not sure where this problem lies, but I'll be psyched if someone can help me solve it.

I am running a mailserver and spamassassin 3.1.9 on centos 2.6.18-8.1.8.el5.

All of my email is getting tagged by SpamAssassin as having failed the INVALID_TZ_EST test.

I figure this might have something to do with the March DST change, but from the tests I've found on the internet my OS seems OK.

Can anyone suggest where I might find an answer to this problem? Googling INVALID_TS_EST brings up precious few results that are difficult for me to follow.

Regards,

Jason

87268530

How about updating your system????

yum check-update

FYI: "centos 2.6.18-8.1.8.el5." is really CentOS 5.0 without any updates.

Check what tzdata package you have installed.

rpm -qa | grep tzdata

See if there are updates, then make sure you are linked from /etc/localtime to the correct timezone library.

Thanks Len,

As it is a production mailserver, I try not to do too many mass updates fearing that it'll break something that is harder to fix than what I'm specifically trying to fix. Maybe I'll take a snapshot and do that tonight. I'll let you know if it corrects anything.

Good move. Updating or upgrading a machine is not always the best option in Production without further tests. I'd suggest just going with my suggestion.

I updated

tzdata-2007d-1.el5

to

tzdata-2007k-1.el5

but I'm not 100% sure how to link from /etc/localtime as you describe (looking for links now). if I 'cat /etc/localtime' I get a bunch of garbage but do see 'EDT5EDT' near the end.

Ok, I found a linking guide and created the symlink.

Do I need a reboot for it to take effect?

If not, it doesn't seem to have corrected anything, but then again, I wasn't sure this was the problem.

Yeah, by default /etc/localtime will be a binary format and not a symlink. A reboot will usually not work. Another thing you need to check is to make sure Postfix (if that's what your using with SpamAssassin) is not using it's own /etc/localtime sometimes found in /var/spool/postfix/etc

If the problem still persists, at least you've ruled it out and it's probably a spam assassin issue.

Not sure what you mean - reboot will not work, or not help?

I'm using Scalix as a mailserver (with sendmail), which reports that it uses the local system for all date info.

I'll do a reboot tonight and spend some more time thinking about what could cause it. I'll try disabling the SA rule that is being violated as well, but that seems like a cheesy workaround where I fear this might be a symptom of a bigger problem.

A reboot should not be required or will not affect it. You could possibly try to restart sendmail or any other services that are reflecting bad timezone or errors.

that's the thing - I'm not sure that anything is reflecting bad timezones. SA is tagging all mail with INVALID_TZ_EST from many different servers, so I have to assume that it is a problem on my end. I'll keep poking and see what I find...

shouldn't

yum update spamassassin

work?

Do this I found on a thread after a google search:

Take a message that hit INVALID_TZ_EST when it got scanned run it through "spamassassin" manually. If it doesn't get hit when
run through "spamassassin" it's the synthesized received header, otherwise it's something else.

Something to do with headers from the looks. I found this info by following this mail-list archive on apache mail-lists: http://mail-archives.apache.org/mod_...t@graze.net%3e

I also hit this page that describes the header tests config for spamassassin: http://spamassassin.apache.org/full/..._head_tests.cf

I've never messes with these myself but maybe some tweaking, you can eliminate such emails that aren't passing the correct TZ info, etc.

I'm too old to start trying to understand regular expressions...

Sending myself a test message to gmail, and viewing the original text, it appears that my mailserver is not appending an 'EST' to the time, which I think the regex is looking for...

Thu, 17 Jan 2008 16:12:36 -0500

I have no idea where to start chasing this...

updating amavisd-milter from 1.2.1 to 1.3.1 fixed the problem (strange that so few results exist in google for this problem).

Thanks to everyone for the help!