Re: Rejecting emails with invalid/unlikely dates?
- There are some very definite patterns in the dates of the spam I'm
getting (xx/xx/3609 and 19 Jan 38) so a modification of those regex's
should do the trick for now.
As for SpamAssassin, I don't use it at the moment. I'm running a small
VPS with 128MB of memory and a handful of email accounts. My recent
tally of spam has been about half-a-dozen per day at most, and the
majority of those were cut by checking SPF records to stop emails that
pretend to be from me.
Presumably there is some way of parsing the various formats of date used
in email headers, otherwise email clients couldn't display it. If anyone
knows of or could create a script that could do a more generic job (such
as the 14 day window I mentioned earlier) then that'd be great.
Noel Jones wrote:
> mouss wrote:
>> Darren Pilgrim a écrit :
>>> IBBoard wrote:
>>>> I've been looking around but so far haven't been able to find anything
>>>> (partly because it's difficult to phrase a search query!). If someone
>>>> has a solution/config for this then that'd be great.
>>>> Before anyone points out issues with GMail and lack of control, this
>>>> is all being done on a domain on a VPS. I'm just using my Gmail
>>>> address for the mailing list :)
>>>> Basically, 99% of the spam I get (which is only a small amount
>>>> compared to some people) is either a) purporting to be from me, to me
>>>> or b) has a date that Thunderbird reports as 1976 or 2038 (but is
>>>> really 3609 or just "38"). I've resolved the first part with SPF
>>>> records and checking them in Postfix, but I can't work out how to get
>>>> Postfix to reject mail that is outside a 14 day window from today (or
>>>> silently dispose of it if it's not possible because it has to get too
>>>> far in to the system to fail it).
>>> You need a content filter for this.
>> and to reject, he needs to run it in pre-queue mode (proxy_filter). or
>> he could use a milter such as milter-regex.
>>> Header checks can do this; however,
>>> they're static, so you have the problem of updating them constantly to
>>> keep the validity window moving.
>> He can use a cron to update the header_checks daily. This is "simpler"
>> than milter/proxy_filter.
>>> Plus there's the issue of date
>> This is not a problem here, since he wants to block "known" spam. so he
>> can write expressions for that spam. and if he only wants to block on
>> the year, then it's even easier.
>>> The best way, IMO, is a policy service that can grok a wide
>>> variety of date formats and check if the date is within 14 days of the
>>> current time.
>> a policy service doesn't see headers. a milter or a proxy_filter does.
>>> There are spamassassin rules for future dates in message headers, so you
>>> might try that route instead of rolling your own.
>> this is indeed easier and maybe safer (well, if OP uses spamassassin).
> Once upon a time, these pcre header_checks were posted to this list:
> (beware line wrapping; each of these are a single line)
> ### Date checks
> IF /^Date:/
> HOLD invalid time in Date header
> / \d\d:\d\d:\d\d [^+-][2-9][5-9][0-9][0-9]\s*$/ HOLD invalid time zone
> offset in Date header
> /^Date: .* 19[0-9][0-9]/ HOLD UBE Header - Past Date #1
> /^Date: .* 200[0-6]/ HOLD UBE Header - Past Date #2
> /^Date:.*((3[2-9]|[4-9][0-9]) Jan|[3-9][0-9] Feb|(3[2-9]|[4-9][0-9])
> Mar|(3[1-9]|[4-9][0-9]) Apr|(3[2-9]|[4-9][0-9]) May|(3[
> 1-9]|[4-9][0-9]) Jun|(3[2-9]|[4-9][0-9]) Jul|(3[2-9]|[4-9][0-9])
> Aug|(3[1-9]|[4-9][0-9]) Sep|(3[2-9]|[4-9][0-9]) Oct|(3[1-9]
> |[4-9][0-9]) Nov|(3[2-9]|[4-9][0-9]) Dec)/ HOLD Invalid date header.
> Correct your clock and resend please.
> 7-9][0-9]))/ HOLD Invalid time header. Correct your clock and resend
> ### END DATE CHECKS
> I have these set to HOLD since they rarely catch anything other than the
> occasional legit mail with a bad year. YMMV.