You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Rik <hl...@buzzhost.co.uk> on 2009/04/24 19:44:07 UTC
DATE_IN_FUTURE
I was stumped on a question today about DATE_IN_FUTURE. My googling
offered me nothing more than the obvious 'The message has a date in the
future.
Thing is, I could not see it. The time stamp was 24 Apr 2009 14:20:32
+0800 and matched the firewall connection log OK. Can anyone point me to
a sensible explanation of what this rule looks at so I can troubleshoot
it?
Re: DATE_IN_FUTURE
Posted by Rik <hl...@buzzhost.co.uk>.
On Sat, 2009-04-25 at 22:58 +0200, Matus UHLAR - fantomas wrote:
> > On Sat, 2009-04-25 at 17:36 +0200, Mark Martinec wrote:
> > > It would save us the guesswork if you could provide the header section
> > > of the troublesome message. As Theo pointed out, there may be problem
> > > in Received header fields inserted by your trusted mailer - not necessarily
> > > a problem in the Date header field. This is not a single rule, but a code
> > > section which tries to guess the actual timetamp at the moment of a
> > > message reception.
>
> On 25.04.09 17:02, Rik wrote:
> > Thanks for the response Mark. I've sussed it. Whilst I binned the
> > messages concerned I managed to find another one (pasted below) and I
> > can easily see the problem in the headers now. Sanity is restored;
> >
> > Received: from mail.caucasus.net (localhost [127.0.0.1])
> > by mx.munged.com (Spam Firewall) with ESMTP id 79C392BF2B4
> > for <ab...@munged.com>; Thu, 2 Apr 2009 21:11:40 +0400 (GET)
> > Received: from mail.caucasus.net (mail.caucasus.net [62.168.168.131]) by
> > mx.munged.com with ESMTP id 8Sd65BVE6VAShNZt for <ab...@munged.com>;
> > Thu, 02 Apr 2009 21:11:40 +0400 (GET)
> > Received: from localhost (relay [62.168.168.208])
> > by mail.caucasus.net (Postfix) with ESMTP id 661FF3810AC
> > for <ab...@munged.com>; Thu, 2 Apr 2009 21:11:40 +0400 (GET)
> > Received: from mail.caucasus.net ([62.168.168.131])
> > by localhost (relay.caucasus.net [62.168.168.208]) (amavisd-new, port
> > 10004)
> > with ESMTP id U9a1cdneOGIs for <ab...@munged.com>;
> > Thu, 2 Apr 2009 21:11:40 +0400 (GET)
> > Received: from v (host-88-210-236-219.adsl.caucasus.net
> > [88.210.236.219])
> > by mail.caucasus.net (Postfix) with SMTP id 7C17C38105A
> > for <ab...@munged.com>; Thu, 2 Apr 2009 21:11:38 +0400 (GET)
> > Message-ID: <F6...@v>
> > From: "Ia Peradze" <in...@nic.ge>
> > To: "Alexander Barsegov" <ab...@munged.com>
> > References:
> > <EB...@MAILBOX.munged.com>
> > Subject: Re: orangecab.ge domain re-registration
> > Date: Thu, 2 Apr 2009 21:05:52 -0400
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > MIME-Version: 1.0
> > Content-Type: multipart/alternative;
> > boundary="----=_NextPart_000_0255_01C9B3D6.CE788D30"
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-Mailer: Microsoft Outlook Express 6.00.2900.5512
> > Disposition-Notification-To: "Ia Peradze" <in...@nic.ge>
> > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
> > X-Antivirus: avast! (VPS 090402-0, 04/02/2009), Outbound message
> > X-Antivirus-Status: Clean
>
> The same problem again. The Date: shows 8 hours more than all other
> Received: headers. Yes, the time zone IS important. When it's 21:11 +0400,
> it's only 17:11 +GMT (+0000) and only 13:11 -0400. So, 21:05 -0400 will be
> in aproximately 8 hours.
>
> Setting date to the future is the technique used by spammers to make their
> spam show as the most recent in the mailbox. The sender has misconfigured
> timezone.
>
> The description of the rule says it:
>
> describe DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date
>
I guess you missed the bit where I said 'I sussed it out', but thanks
again.
Re: DATE_IN_FUTURE
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Sat, 2009-04-25 at 17:36 +0200, Mark Martinec wrote:
> > It would save us the guesswork if you could provide the header section
> > of the troublesome message. As Theo pointed out, there may be problem
> > in Received header fields inserted by your trusted mailer - not necessarily
> > a problem in the Date header field. This is not a single rule, but a code
> > section which tries to guess the actual timetamp at the moment of a
> > message reception.
On 25.04.09 17:02, Rik wrote:
> Thanks for the response Mark. I've sussed it. Whilst I binned the
> messages concerned I managed to find another one (pasted below) and I
> can easily see the problem in the headers now. Sanity is restored;
>
> Received: from mail.caucasus.net (localhost [127.0.0.1])
> by mx.munged.com (Spam Firewall) with ESMTP id 79C392BF2B4
> for <ab...@munged.com>; Thu, 2 Apr 2009 21:11:40 +0400 (GET)
> Received: from mail.caucasus.net (mail.caucasus.net [62.168.168.131]) by
> mx.munged.com with ESMTP id 8Sd65BVE6VAShNZt for <ab...@munged.com>;
> Thu, 02 Apr 2009 21:11:40 +0400 (GET)
> Received: from localhost (relay [62.168.168.208])
> by mail.caucasus.net (Postfix) with ESMTP id 661FF3810AC
> for <ab...@munged.com>; Thu, 2 Apr 2009 21:11:40 +0400 (GET)
> Received: from mail.caucasus.net ([62.168.168.131])
> by localhost (relay.caucasus.net [62.168.168.208]) (amavisd-new, port
> 10004)
> with ESMTP id U9a1cdneOGIs for <ab...@munged.com>;
> Thu, 2 Apr 2009 21:11:40 +0400 (GET)
> Received: from v (host-88-210-236-219.adsl.caucasus.net
> [88.210.236.219])
> by mail.caucasus.net (Postfix) with SMTP id 7C17C38105A
> for <ab...@munged.com>; Thu, 2 Apr 2009 21:11:38 +0400 (GET)
> Message-ID: <F6...@v>
> From: "Ia Peradze" <in...@nic.ge>
> To: "Alexander Barsegov" <ab...@munged.com>
> References:
> <EB...@MAILBOX.munged.com>
> Subject: Re: orangecab.ge domain re-registration
> Date: Thu, 2 Apr 2009 21:05:52 -0400
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
> boundary="----=_NextPart_000_0255_01C9B3D6.CE788D30"
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 6.00.2900.5512
> Disposition-Notification-To: "Ia Peradze" <in...@nic.ge>
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
> X-Antivirus: avast! (VPS 090402-0, 04/02/2009), Outbound message
> X-Antivirus-Status: Clean
The same problem again. The Date: shows 8 hours more than all other
Received: headers. Yes, the time zone IS important. When it's 21:11 +0400,
it's only 17:11 +GMT (+0000) and only 13:11 -0400. So, 21:05 -0400 will be
in aproximately 8 hours.
Setting date to the future is the technique used by spammers to make their
spam show as the most recent in the mailbox. The sender has misconfigured
timezone.
The description of the rule says it:
describe DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
We are but packets in the Internet of life (userfriendly.org)
Re: DATE_IN_FUTURE
Posted by Rik <hl...@buzzhost.co.uk>.
On Sat, 2009-04-25 at 17:36 +0200, Mark Martinec wrote:
> On Saturday 25 April 2009 16:31:38 Rik wrote:
> > On Sat, 2009-04-25 at 06:47 -0600, LuKreme wrote:
> > > On 25-Apr-2009, at 01:55, Rik wrote:
> > > > Sadly I have discarded the mail, but the server time stamp and header
> > > > stamp were within seconds of each other, so I don't think it's a time
> > > > zone issue as such.
> > >
> > > Within seconds of each other including the TZ offset?
> >
> > would it be relevant if they are 8 hours ahead of the destination SA or
> > is it too stupid to look at the offset? Hence the question - what is the
> > rule looking at? I'm starting to think it may have been written by a
> > retarded chimp.
>
> It would save us the guesswork if you could provide the header section
> of the troublesome message. As Theo pointed out, there may be problem
> in Received header fields inserted by your trusted mailer - not necessarily
> a problem in the Date header field. This is not a single rule, but a code
> section which tries to guess the actual timetamp at the moment of a
> message reception.
>
> Mark
>
Thanks for the response Mark. I've sussed it. Whilst I binned the
messages concerned I managed to find another one (pasted below) and I
can easily see the problem in the headers now. Sanity is restored;
Received: from mail.caucasus.net (localhost [127.0.0.1])
by mx.munged.com (Spam Firewall) with ESMTP id 79C392BF2B4
for <ab...@munged.com>; Thu, 2 Apr 2009 21:11:40 +0400 (GET)
Received: from mail.caucasus.net (mail.caucasus.net [62.168.168.131]) by
mx.munged.com with ESMTP id 8Sd65BVE6VAShNZt for <ab...@munged.com>;
Thu, 02 Apr 2009 21:11:40 +0400 (GET)
Received: from localhost (relay [62.168.168.208])
by mail.caucasus.net (Postfix) with ESMTP id 661FF3810AC
for <ab...@munged.com>; Thu, 2 Apr 2009 21:11:40 +0400 (GET)
Received: from mail.caucasus.net ([62.168.168.131])
by localhost (relay.caucasus.net [62.168.168.208]) (amavisd-new, port
10004)
with ESMTP id U9a1cdneOGIs for <ab...@munged.com>;
Thu, 2 Apr 2009 21:11:40 +0400 (GET)
Received: from v (host-88-210-236-219.adsl.caucasus.net
[88.210.236.219])
by mail.caucasus.net (Postfix) with SMTP id 7C17C38105A
for <ab...@munged.com>; Thu, 2 Apr 2009 21:11:38 +0400 (GET)
Message-ID: <F6...@v>
From: "Ia Peradze" <in...@nic.ge>
To: "Alexander Barsegov" <ab...@munged.com>
References:
<EB...@MAILBOX.munged.com>
Subject: Re: orangecab.ge domain re-registration
Date: Thu, 2 Apr 2009 21:05:52 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0255_01C9B3D6.CE788D30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
Disposition-Notification-To: "Ia Peradze" <in...@nic.ge>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Antivirus: avast! (VPS 090402-0, 04/02/2009), Outbound message
X-Antivirus-Status: Clean
---- ----------------------
--------------------------------------------------
1.50 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date
0.00 HTML_MESSAGE BODY: HTML included in message
3.10 DATE_IN_FUTURE_06_12_2 DATE_IN_FUTURE_06_12_2
This is a multi-part message in MIME format.
Re: DATE_IN_FUTURE
Posted by Mark Martinec <Ma...@ijs.si>.
On Saturday 25 April 2009 16:31:38 Rik wrote:
> On Sat, 2009-04-25 at 06:47 -0600, LuKreme wrote:
> > On 25-Apr-2009, at 01:55, Rik wrote:
> > > Sadly I have discarded the mail, but the server time stamp and header
> > > stamp were within seconds of each other, so I don't think it's a time
> > > zone issue as such.
> >
> > Within seconds of each other including the TZ offset?
>
> would it be relevant if they are 8 hours ahead of the destination SA or
> is it too stupid to look at the offset? Hence the question - what is the
> rule looking at? I'm starting to think it may have been written by a
> retarded chimp.
It would save us the guesswork if you could provide the header section
of the troublesome message. As Theo pointed out, there may be problem
in Received header fields inserted by your trusted mailer - not necessarily
a problem in the Date header field. This is not a single rule, but a code
section which tries to guess the actual timetamp at the moment of a
message reception.
Mark
Re: DATE_IN_FUTURE
Posted by Rik <hl...@buzzhost.co.uk>.
On Sat, 2009-04-25 at 06:47 -0600, LuKreme wrote:
> On 25-Apr-2009, at 01:55, Rik wrote:
> > Sadly I have discarded the mail, but the server time stamp and header
> > stamp were within seconds of each other, so I don't think it's a time
> > zone issue as such.
>
> Within seconds of each other including the TZ offset?
>
would it be relevant if they are 8 hours ahead of the destination SA or
is it too stupid to look at the offset? Hence the question - what is the
rule looking at? I'm starting to think it may have been written by a
retarded chimp.
Re: DATE_IN_FUTURE
Posted by LuKreme <kr...@kreme.com>.
On 25-Apr-2009, at 01:55, Rik wrote:
> Sadly I have discarded the mail, but the server time stamp and header
> stamp were within seconds of each other, so I don't think it's a time
> zone issue as such.
Within seconds of each other including the TZ offset?
--
Spontaneity has its time and place.
Re: DATE_IN_FUTURE
Posted by Rik <hl...@buzzhost.co.uk>.
On Fri, 2009-04-24 at 23:32 +0200, Matus UHLAR - fantomas wrote:
> On 24.04.09 18:44, Rik wrote:
> > Date: Fri, 24 Apr 2009 18:44:07 +0100
> >
> > I was stumped on a question today about DATE_IN_FUTURE. My googling
> > offered me nothing more than the obvious 'The message has a date in the
> > future.
> >
> > Thing is, I could not see it. The time stamp was 24 Apr 2009 14:20:32
> > +0800 and matched the firewall connection log OK. Can anyone point me to
> > a sensible explanation of what this rule looks at so I can troubleshoot
> > it?
>
> If you got the mentioned mail BEFORE you sent this one, it was in the
> future:
>
> the time you sent the mail was 24 Apr 2009 19:44:07 GMT
> the time reported was 25 Apr 2009 00:20:32 GMT.
>
> Apparently the sender does not have correct timezone set (quite common
> problem).
>
Sadly I have discarded the mail, but the server time stamp and header
stamp were within seconds of each other, so I don't think it's a time
zone issue as such.
The only reason I dropped in and asked here stems from seeing the same
rule hit at 3.5 twice in the last two days for no obvious reasons.
All I really want to know is what the rule is looking at to compare X
with Y. Is it looking at the box SA is running on and comparing the time
with the 'date' field in the header (where it exists) or something else?
>>From the rule name I can get the gist of what the issue is, I just need
to know what it is doing the comparison on for my own sanity.
Re: DATE_IN_FUTURE
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 24.04.09 18:44, Rik wrote:
> Date: Fri, 24 Apr 2009 18:44:07 +0100
>
> I was stumped on a question today about DATE_IN_FUTURE. My googling
> offered me nothing more than the obvious 'The message has a date in the
> future.
>
> Thing is, I could not see it. The time stamp was 24 Apr 2009 14:20:32
> +0800 and matched the firewall connection log OK. Can anyone point me to
> a sensible explanation of what this rule looks at so I can troubleshoot
> it?
If you got the mentioned mail BEFORE you sent this one, it was in the
future:
the time you sent the mail was 24 Apr 2009 19:44:07 GMT
the time reported was 25 Apr 2009 00:20:32 GMT.
Apparently the sender does not have correct timezone set (quite common
problem).
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Emacs is a complicated operating system without good text editor.
Re: DATE_IN_FUTURE
Posted by John Hardin <jh...@impsec.org>.
On Fri, 24 Apr 2009, Rik wrote:
> I was stumped on a question today about DATE_IN_FUTURE. My googling
> offered me nothing more than the obvious 'The message has a date in the
> future.
>
> Thing is, I could not see it. The time stamp was 24 Apr 2009 14:20:32
> +0800 and matched the firewall connection log OK. Can anyone point me to
> a sensible explanation of what this rule looks at so I can troubleshoot
> it?
Did you remember to adjust for timezones?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Win95: Where do you want to go today?
Vista: Where will Microsoft allow you to go today?
-----------------------------------------------------------------------
Today: Max Planck's 151st birthday
Re: DATE_IN_FUTURE
Posted by Theo Van Dinter <fe...@apache.org>.
You'd really want to post the message headers in pastebot or something
so people can look at them. It's not just the Date header, the rule
also looks at the Received headers, etc.
On Fri, Apr 24, 2009 at 1:44 PM, Rik <hl...@buzzhost.co.uk> wrote:
> I was stumped on a question today about DATE_IN_FUTURE. My googling
> offered me nothing more than the obvious 'The message has a date in the
> future.
>
> Thing is, I could not see it. The time stamp was 24 Apr 2009 14:20:32
> +0800 and matched the firewall connection log OK. Can anyone point me to
> a sensible explanation of what this rule looks at so I can troubleshoot
> it?