Re: DATE_IN_FUTURE
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 ; 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 ; > > 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 ; 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 ; > > 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 ; Thu, 2 Apr 2009 21:11:38 +0400 (GET) > > Message-ID: > > From: "Ia Peradze" > > To: "Alexander Barsegov" > > References: > > > > 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" > > 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 (+) 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
> 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 ; 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 ; > 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 ; 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 ; > 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 ; Thu, 2 Apr 2009 21:11:38 +0400 (GET) > Message-ID: > From: "Ia Peradze" > To: "Alexander Barsegov" > References: > > 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" > 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 (+) 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, uh...@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
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 ; 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 ; 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 ; 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 ; 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 ; Thu, 2 Apr 2009 21:11:38 +0400 (GET) Message-ID: From: "Ia Peradze" To: "Alexander Barsegov" References: 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" 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
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
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
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
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
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, uh...@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
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 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?
Re: DATE_IN_FUTURE
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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
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
Al Probably due to their timezone not being correct. -- Martin Hepworth Snr Systems Administrator Solid State Logic Tel: +44 (0)1865 842300 > -Original Message- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Al Danks > Sent: 16 May 2006 15:54 > To: users@spamassassin.apache.org > Subject: DATE_IN_FUTURE > > We get email from international students from Indonesia, China, Korea, > etc. > Sometimes the email trips one of the DATE_IN_FUTURE rules. > > Does this happen because the sender's computer has bad date/time? Because > of the > time zone they are sending from? Or some other reason? > > Some of this email also ends up tripping one of the RCVD_IN_SORBS rules. > Combined with another rule or two they end up classed as spam. > ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote confirms that this email message has been swept for the presence of computer viruses and is believed to be clean. **
DATE_IN_FUTURE
We get email from international students from Indonesia, China, Korea, etc. Sometimes the email trips one of the DATE_IN_FUTURE rules. Does this happen because the sender's computer has bad date/time? Because of the time zone they are sending from? Or some other reason? Some of this email also ends up tripping one of the RCVD_IN_SORBS rules. Combined with another rule or two they end up classed as spam.
Re: DATE_IN_FUTURE
At 02:44 AM 8/31/2005, Beast wrote: 3. I have train hundreds (or thousands) spam/ham mail to sa-learn but it seems it still not quite good detecting non-english mail. Because SpamAssassin is based on the english language. SpamAssassin doesn't know that in (example) Language X that "blahblahblah" means "Hello, it's your brother. How is the family?" but "blabblabscoobydoo" means "enlarge your ." That means using bayes filter for non-english is useless? No, the bayes will be fine. No it means that most of the body-text rules are useless. Your SA will be limited to bayes, network checks, and message formating rules only. But SA isn't meant to work well based on bayes alone.
Re: DATE_IN_FUTURE
At 01:58 AM 8/31/2005, Beast wrote: --- Received: from notes.trakindo.co.id (notes.trakindo.co.id [202.152.6.165]) by mail.indorama.com (Postfix) with ESMTP id 31F50E7932 for <[EMAIL PROTECTED]>; Wed, 31 Aug 2005 12:15:29 +0700 (WIT) From: [EMAIL PROTECTED] To: "My User" <[EMAIL PROTECTED]> Subject: *[SPAM - score 6.1/5.2 ]* DELIVERY FAILURE: User xxx ([EMAIL PROTECTED]) not listed in public Name & Address Book Date: Wed, 31 Aug 2005 08:59:56 -0700 ... 1. Why it triger DATE_IN_FUTURE_06_12? Convert the Date: header and the timestamp in the Received: header to GMT. If you do that, you'll realize both are dated August 31, but the Date: header claims the message was written 15:59 GMT, but the message was Received at 05:15 GMT. Somebody has a screwed up clock and/or timezone. Was this really sent from a timezone halfway around the world? Is your mailserver clock correct? 2. How do I pass all bounce email? There's no generic feature in SA that detects bounce mail. If you scan on the delivery MTA or post-delivery you might be able to write a rule to look for a Return-Path header that contains <>. 3. I have train hundreds (or thousands) spam/ham mail to sa-learn but it seems it still not quite good detecting non-english mail. You might want to try running the message through spamassassin -D This will show you all the tokens it found, and what bayes probability each token has. That might give you some direction.
Re: DATE_IN_FUTURE
Beast wrote: Evan Platt wrote: Received by your system: Wed, 31 Aug 2005 12:15:29 +0700 Header Date: Wed, 31 Aug 2005 08:59:56 -0700 Isn't that should be date in the past? Sorry, my mistake. It was correct. 15:59:56 GMT vs 5:15:29 GMT. -- --beast
Re: DATE_IN_FUTURE
At 11:44 PM 8/30/2005, you wrote: Isn't that should be date in the past? Nope.. In the future. Bouncing mail / NDR. Not with spamassasin. With your MTA/ procmail or other method, but SA can only scan messages, it has no capabilities to do anything based on the score. That means using bayes filter for non-english is useless? See Loren's response. :) Evan
Re: DATE_IN_FUTURE
Evan Platt wrote: Received by your system: Wed, 31 Aug 2005 12:15:29 +0700 Header Date: Wed, 31 Aug 2005 08:59:56 -0700 Isn't that should be date in the past? 2. How do I pass all bounce email? Sorry, not sure I understand...? Bouncing mail / NDR. 3. I have train hundreds (or thousands) spam/ham mail to sa-learn but it seems it still not quite good detecting non-english mail. Because SpamAssassin is based on the english language. SpamAssassin doesn't know that in (example) Language X that "blahblahblah" means "Hello, it's your brother. How is the family?" but "blabblabscoobydoo" means "enlarge your ." That means using bayes filter for non-english is useless? -- --beast
Re: DATE_IN_FUTURE
You sent the message to the list: Received: from [202.154.34.135] (HELO v6.i6x.org) (202.154.34.135) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Aug 2005 22:59:21 -0700 The spam message header you showed: > Date: Wed, 31 Aug 2005 08:59:56 -0700 The Date header on that mail is some 9 hours after the time you posted your question. Hence: > * 1.3 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after > Received: date Assuming you sent the mail to the list not long after you received it, the Date header on that mail still shows it being between 6 and 12 hours in the future from when you received it. > 3. I have train hundreds (or thousands) spam/ham mail to sa-learn but it > seems it still not quite good detecting non-english mail. > * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% > * [score: 1.] This tells me that bayes is 100% sure that the message is spam. That sounds pretty good to me, unless this isn't spam. However, the date header being mucked up, and the date header and first Received headers showing timezones that are 12 hours apart, makes me think this is spam. SA is written primarily by English speakers, and the rules are primarily aimed at detecting English-language spam. There are some add-on rulesets to detect spam in other languages, but they generally aren't that well maintained. They would have to be maintained by contributions from people who can write rules for spam in other languages. Few people that might be able to write such rules seem to contribute them. Bayes should be pretty good about detecting spam in most languages that do not require double-byte characters. The current release of SA may have some problems with double-byte characters that could make Bayes less effective than it could be. Loren
Re: DATE_IN_FUTURE
At 10:58 PM 8/30/2005, you wrote: --- Received: from notes.trakindo.co.id (notes.trakindo.co.id [202.152.6.165]) by mail.indorama.com (Postfix) with ESMTP id 31F50E7932 for <[EMAIL PROTECTED]>; Wed, 31 Aug 2005 12:15:29 +0700 (WIT) From: [EMAIL PROTECTED] To: "My User" <[EMAIL PROTECTED]> Subject: *[SPAM - score 6.1/5.2 ]* DELIVERY FAILURE: User xxx ([EMAIL PROTECTED]) not listed in public Name & Address Book Date: Wed, 31 Aug 2005 08:59:56 -0700 ... X-Spam-Report: * 0.0 NO_REAL_NAME From: does not include a real name * 1.3 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 0.2 HTML_20_30 BODY: Message is 20% to 30% HTML * 1.0 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME * 0.0 HTML_MESSAGE BODY: HTML included in message * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.] --- 1. Why it triger DATE_IN_FUTURE_06_12? Received by your system: Wed, 31 Aug 2005 12:15:29 +0700 Header Date: Wed, 31 Aug 2005 08:59:56 -0700 2. How do I pass all bounce email? Sorry, not sure I understand...? 3. I have train hundreds (or thousands) spam/ham mail to sa-learn but it seems it still not quite good detecting non-english mail. Because SpamAssassin is based on the english language. SpamAssassin doesn't know that in (example) Language X that "blahblahblah" means "Hello, it's your brother. How is the family?" but "blabblabscoobydoo" means "enlarge your ."
DATE_IN_FUTURE
--- Received: from notes.trakindo.co.id (notes.trakindo.co.id [202.152.6.165]) by mail.indorama.com (Postfix) with ESMTP id 31F50E7932 for <[EMAIL PROTECTED]>; Wed, 31 Aug 2005 12:15:29 +0700 (WIT) From: [EMAIL PROTECTED] To: "My User" <[EMAIL PROTECTED]> Subject: *[SPAM - score 6.1/5.2 ]* DELIVERY FAILURE: User xxx ([EMAIL PROTECTED]) not listed in public Name & Address Book Date: Wed, 31 Aug 2005 08:59:56 -0700 ... X-Spam-Report: * 0.0 NO_REAL_NAME From: does not include a real name * 1.3 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 0.2 HTML_20_30 BODY: Message is 20% to 30% HTML * 1.0 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME * 0.0 HTML_MESSAGE BODY: HTML included in message * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.] --- 1. Why it triger DATE_IN_FUTURE_06_12? 2. How do I pass all bounce email? 3. I have train hundreds (or thousands) spam/ham mail to sa-learn but it seems it still not quite good detecting non-english mail. -- --beast
Re: DATE_IN_FUTURE false positive
Ratchanee Wongwisarnsee wrote on Tue, 19 Jul 2005 16:09:26 +0700: > Iâve some problem with the DATE_IN_FUTURE rules since it cause a false > positive Well, some details may help. Also, if possible, please send text/plain only, thanks :-) Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com IE-Center: http://ie5.de & http://msie.winware.org
DATE_IN_FUTURE false positive
Hi all I’ve some problem with the DATE_IN_FUTURE rules since it cause a false positive. Does anyone have any suggestion? I am considering to decrease the score of this rule but I concern that it will cause more spam get through. Thanks
