Re: False positives due to __BITCOIN_ID

On Wed, Dec 04, 2019 at 08:59:42AM +0100, Benny Pedersen wrote: > On 2019-12-03 20:15, RW wrote: > > On Tue, 3 Dec 2019 14:05:10 -0500 > > Mark London wrote: > > > >> It seems to me that the rule for detecting a BITCOIN in an email, is > >> incorrect. See below: > >> > >> body __BITCOIN_ID /\b(

Re: False positives due to __BITCOIN_ID

On 2019-12-03 20:15, RW wrote: On Tue, 3 Dec 2019 14:05:10 -0500 Mark London wrote: It seems to me that the rule for detecting a BITCOIN in an email, is incorrect. See below: body __BITCOIN_ID /\b(? It doesn't, but spammers have started splitting them up to evade detections. if clients be

Re: False positives due to __BITCOIN_ID

On Tue, 3 Dec 2019 11:27:11 -0800 (PST) John Hardin wrote: > On Tue, 3 Dec 2019, Mark London wrote: > > > It seems to me that the rule for detecting a BITCOIN in an email, > > is incorrect. See below: > > > > body __BITCOIN_ID /\b(? > > > Why is there a \s in this rule?I didn't think that a

Re: False positives due to __BITCOIN_ID

On Tue, 3 Dec 2019, Mark London wrote: It seems to me that the rule for detecting a BITCOIN in an email, is incorrect. See below: body __BITCOIN_ID /\b(?Why is there a \s in this rule?I didn't think that a BITCOIN id has a space. Recent obfuscation seen in RL extortion spams. This ru

Re: False positives due to __BITCOIN_ID

On Tue, 3 Dec 2019 14:05:10 -0500 Mark London wrote: > It seems to me that the rule for detecting a BITCOIN in an email, is > incorrect. See below: > > body __BITCOIN_ID /\b(? > Why is there a \s in this rule?I didn't think that a BITCOIN id > has a space. It doesn't, but spammers have s

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

On Thu, 20 Apr 2017 10:41:21 -0400 Lyle Evans wrote: > I have been getting false positives from Yahoo due to > FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo > about 3/31/17 I've been looking into this and IMO Yahoo have exposed a problem with the rule: https://bz.apache.org/S

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

> On Thu, 20 Apr 2017, Lyle Evans wrote: > >> At 01:00 PM 4/20/2017, John Hardin wrote: >>> On Thu, 20 Apr 2017, Merijn van den Kroonenberg wrote: >>> >>> > > On Thu, 20 Apr 2017 10:41:21 -0400 >>> > > Lyle Evans wrote: >>> > > >>> > > > I have been getting false positives from Yahoo due to >>> > >

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

At 01:00 PM 4/20/2017, John Hardin wrote: On Thu, 20 Apr 2017, Merijn van den Kroonenberg wrote: On Thu, 20 Apr 2017 10:41:21 -0400 Lyle Evans wrote: I have been getting false positives from Yahoo due to FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo about 3/31/17 The X-Mai

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

At 01:00 PM 4/20/2017, John Hardin wrote: On Thu, 20 Apr 2017, Merijn van den Kroonenberg wrote: On Thu, 20 Apr 2017 10:41:21 -0400 Lyle Evans wrote: I have been getting false positives from Yahoo due to FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo about 3/31/17 The X-Mai

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

On Thu, 20 Apr 2017, Lyle Evans wrote: At 01:00 PM 4/20/2017, John Hardin wrote: On Thu, 20 Apr 2017, Merijn van den Kroonenberg wrote: > > On Thu, 20 Apr 2017 10:41:21 -0400 > > Lyle Evans wrote: > > > > > I have been getting false positives from Yahoo due to > > > FORGED_MUA_MOZILLA hittin

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

On Thu, 20 Apr 2017, Merijn van den Kroonenberg wrote: On Thu, 20 Apr 2017 10:41:21 -0400 Lyle Evans wrote: I have been getting false positives from Yahoo due to FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo about 3/31/17 The X-Mailer line reads: X-Mailer: WebService/1.1.9

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

On Thu, 20 Apr 2017 17:02:57 +0200 Merijn van den Kroonenberg wrote: > > My guess is that they are including the http user-agent header of > > the browser that connected to their webmail server. > > > > Correct, I also noticed this a few days ago. Maybe the rule could be > changed to exclude y

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

> On Thu, 20 Apr 2017 10:41:21 -0400 > Lyle Evans wrote: > >> I have been getting false positives from Yahoo due to >> FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo >> about 3/31/17 >> >> The X-Mailer line reads: >> >> X-Mailer: WebService/1.1.9272 YahooMailNeo Mozilla/5.0 (Windo

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

On Thu, 20 Apr 2017 10:41:21 -0400 Lyle Evans wrote: > I have been getting false positives from Yahoo due to > FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo > about 3/31/17 > > The X-Mailer line reads: > > X-Mailer: WebService/1.1.9272 YahooMailNeo Mozilla/5.0 (Windows NT > 1

Re: False positives with Razor2

On Sun, 06 Dec 2015 09:28:08 +0100 Torsten Bronger wrote: > Hallöchen! > > Bill Cole writes: > > > [...] > > > > Indicates that someone has sabotaged your SA scores. Those are > > entirely insane scores for those tests. If the default values were > > used, that message would not have been miscla

Re: False positives with Razor2

Am 06.12.2015 um 09:28 schrieb Torsten Bronger: And don't trust whoever set your BAYES and RAZOR scores to have anything to do with your spam control. Well, I don't trust Razor anymore! If there is such a thing as "the opposite of spam", then these mails. nonsense, hence this is a scoring

Re: False positives with Razor2

Hallöchen! Bill Cole writes: > [...] > > Indicates that someone has sabotaged your SA scores. Those are > entirely insane scores for those tests. If the default values were > used, that message would not have been misclassified. I myself set those values, almost 10 years ago. They have served v

Re: False positives with Razor2

On 5 Dec 2015, at 14:46, Torsten Bronger wrote: Hallöchen! Bill Cole writes: On 5 Dec 2015, at 4:42, Torsten Bronger wrote: In http://wilson.bronger.org/37196 Nope: Sorry, works now. This: -5.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%

Re: False positives with Razor2

Hallöchen! Bill Cole writes: > On 5 Dec 2015, at 4:42, Torsten Bronger wrote: > >> In http://wilson.bronger.org/37196 > > Nope: Sorry, works now. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de

Re: False positives with Razor2

On 5 Dec 2015, at 4:42, Torsten Bronger wrote: > Hallöchen! > > In http://wilson.bronger.org/37196 Nope: * Trying 176.199.175.106... * Connected to wilson.bronger.org (176.199.175.106) port 80 (#0) > GET /37196 HTTP/1.1 > Host: wilson.bronger.org > User-Agent: curl/7.45.0 > Accept: */* > < HT

Re: false positives by FREEMAIL_FORGED_REPLYTO

Interesting, thanks for pointing it out This syntax has been used in a while by some other software, like JIRA, RT, … so not something new. In general, I would say spamassassin needs a few extra rules to now handle domain reputation/blocking (as it seems this is where we are going), I even fou

Re: false positives by FREEMAIL_FORGED_REPLYTO

Michael Storz skrev den 2014-04-24 16:30: linkedin.com is not a freemail domain, gmx.de is. Therefore the rule fires. then add it, freemail_domain linkedin.com but only if you at sametime add freemail_whitelist untested do linkedin break there own dkim ? No. good, others do ?

Re: false positives by FREEMAIL_FORGED_REPLYTO

John Hardin skrev den 2014-04-24 16:23: add a meta with DKIM_VALID to subtract some points? or shortcicuit it based on just that ? shortcircuit DKIM_VALID spam no no use DKIM_VALID_AU if anything its just that this rule is not specific to linkedin :( end of life

Re: false positives by FREEMAIL_FORGED_REPLYTO

Am 2014-04-24 16:11, schrieb Benny Pedersen: Michael Storz skrev den 2014-04-24 15:22: I have answered that already, why this is not a good idea. so freemail_whitelist *@linkedin.com ? Does not work: rule: meta FREEMAIL_FORGED_REPLYTO __freemail_hdr_replyto && !FREEMAIL_FROM && !__f

Re: false positives by FREEMAIL_FORGED_REPLYTO

On 04/24/2014 04:23 PM, John Hardin wrote: On Thu, 24 Apr 2014, Axb wrote: On 04/24/2014 02:20 PM, Michael Storz wrote: Am 2014-04-24 13:27, schrieb Axb: > On 04/24/2014 01:22 PM, Michael Storz wrote: > > Am 2014-04-24 12:58, schrieb Axb: > > > On 04/24/2014 12:52 PM, Michael Storz wrote:

Re: false positives by FREEMAIL_FORGED_REPLYTO

On Thu, 24 Apr 2014, Axb wrote: On 04/24/2014 02:20 PM, Michael Storz wrote: Am 2014-04-24 13:27, schrieb Axb: > On 04/24/2014 01:22 PM, Michael Storz wrote: > > Am 2014-04-24 12:58, schrieb Axb: > > > On 04/24/2014 12:52 PM, Michael Storz wrote: > > > > Since Yahoo and AOL have moved to a

Re: false positives by FREEMAIL_FORGED_REPLYTO

Michael Storz skrev den 2014-04-24 15:22: I have answered that already, why this is not a good idea. so freemail_whitelist *@linkedin.com ? do linkedin break there own dkim ?

Re: false positives by FREEMAIL_FORGED_REPLYTO

On 04/24/2014 03:22 PM, Michael Storz wrote: Am 2014-04-24 14:31, schrieb Axb: On 04/24/2014 02:20 PM, Michael Storz wrote: Am 2014-04-24 13:27, schrieb Axb: On 04/24/2014 01:22 PM, Michael Storz wrote: Am 2014-04-24 12:58, schrieb Axb: On 04/24/2014 12:52 PM, Michael Storz wrote: Since Yah

Re: false positives by FREEMAIL_FORGED_REPLYTO

Am 2014-04-24 14:31, schrieb Axb: On 04/24/2014 02:20 PM, Michael Storz wrote: Am 2014-04-24 13:27, schrieb Axb: On 04/24/2014 01:22 PM, Michael Storz wrote: Am 2014-04-24 12:58, schrieb Axb: On 04/24/2014 12:52 PM, Michael Storz wrote: Since Yahoo and AOL have moved to a DMARC policy of rej

Re: false positives by FREEMAIL_FORGED_REPLYTO

On 04/24/2014 02:20 PM, Michael Storz wrote: Am 2014-04-24 13:27, schrieb Axb: On 04/24/2014 01:22 PM, Michael Storz wrote: Am 2014-04-24 12:58, schrieb Axb: On 04/24/2014 12:52 PM, Michael Storz wrote: Since Yahoo and AOL have moved to a DMARC policy of reject, mail senders are changing the

Re: false positives by FREEMAIL_FORGED_REPLYTO

Am 2014-04-24 13:27, schrieb Axb: On 04/24/2014 01:22 PM, Michael Storz wrote: Am 2014-04-24 12:58, schrieb Axb: On 04/24/2014 12:52 PM, Michael Storz wrote: Since Yahoo and AOL have moved to a DMARC policy of reject, mail senders are changing the way they are sending their emails. Instead of

Re: false positives by FREEMAIL_FORGED_REPLYTO

Michael Storz skrev den 2014-04-24 13:22: Sure, that's what I have done already. shuting your own foots with it Well, if we want to do hairsplitting, then the answer is no: it is not forged anymore, therefore the name is wrong ;-) +1, if its not forged, compensate with the fact its not for

Re: false positives by FREEMAIL_FORGED_REPLYTO

Michael Storz skrev den 2014-04-24 12:52: From: GIVENNAME_SURNAME_via_LinkedIn_ (dkim:AUTHOR) From: NAME_via_Dropbox_ (dkim:AUTHOR) Since more and more such emails will occur, for example all web forms will send their emails in this way, the rule does not make sense anymore. let it fire, ope

Re: false positives by FREEMAIL_FORGED_REPLYTO

On 04/24/2014 01:22 PM, Michael Storz wrote: Am 2014-04-24 12:58, schrieb Axb: On 04/24/2014 12:52 PM, Michael Storz wrote: Since Yahoo and AOL have moved to a DMARC policy of reject, mail senders are changing the way they are sending their emails. Instead of using the email address of an user

Re: false positives by FREEMAIL_FORGED_REPLYTO

Am 2014-04-24 12:58, schrieb Axb: On 04/24/2014 12:52 PM, Michael Storz wrote: Since Yahoo and AOL have moved to a DMARC policy of reject, mail senders are changing the way they are sending their emails. Instead of using the email address of an user in RFC5322.From they use their own address a

Re: false positives by FREEMAIL_FORGED_REPLYTO

On 04/24/2014 12:52 PM, Michael Storz wrote: Since Yahoo and AOL have moved to a DMARC policy of reject, mail senders are changing the way they are sending their emails. Instead of using the email address of an user in RFC5322.From they use their own address and put the address of the user in the

Re: False positives with Bayes_99

On Thu, 20 Dec 2007 15:18:45 +0100, "Matthias Haegele" <[EMAIL PROTECTED]> said: > Merlin schrieb: > > On Thu, 20 Dec 2007 03:08:34 -0800, "Merlin" <[EMAIL PROTECTED]> said: > >> > >> > >> On Thu, 20 Dec 2007 11:59:32 +0100, "Matthias Haegele" > >> <[EMAIL PROTECTED]> said: > >>> Merlin schrieb: >

Re: False positives with Bayes_99

On Thu, 20 Dec 2007, Merlin wrote: > I looked it up and found that Spamassasin believes that it is to > 99% spam by training from users. I believe there is more to it, as > I can not believe that users mark such msges as spam. An unfortunate reality of system administration is that most people a

Re: False positives with Bayes_99

Merlin schrieb: On Thu, 20 Dec 2007 03:08:34 -0800, "Merlin" <[EMAIL PROTECTED]> said: On Thu, 20 Dec 2007 11:59:32 +0100, "Matthias Haegele" <[EMAIL PROTECTED]> said: Merlin schrieb: Hi there, I am running a well trusted travel community page that sends system e-mails like register, notice

Re: False positives with Bayes_99

On Thu, 20 Dec 2007 03:08:34 -0800, "Merlin" <[EMAIL PROTECTED]> said: > > > > On Thu, 20 Dec 2007 11:59:32 +0100, "Matthias Haegele" > <[EMAIL PROTECTED]> said: > > Merlin schrieb: > > > Hi there, > > > > > > I am running a well trusted travel community page that sends system > > > e-mails li

Re: False positives with Bayes_99

Merlin schrieb: Hi there, I am running a well trusted travel community page that sends system e-mails like register, notice on comments etc. to its opt-in signed up users. Since two days all E-Mails from that server get an aditional spam score of 3.5!! by Bayes_99. I looked it up and found that

Re: False positives

On Mon, 20 Aug 2007, FaberK wrote: > Hi, > following your suggestions, I've noticed that those mails got as > > Return-Path: > > my address that is in whitelist. It is trivially easy for an external mail client to forge the sender address to make the message appear as if it is coming from your

Re: False positives

Thanks to all. ;o) 2007/8/20, SM <[EMAIL PROTECTED]>: > > At 06:48 20-08-2007, FaberK wrote: > >Into my sendmail.cf I got this: > > This has nothing to do with sendmail. The Return-Path: address is > what gets passed through the SMTP envelope. Don't whitelist your domain. > >

Re: False positives

At 06:48 20-08-2007, FaberK wrote: Into my sendmail.cf I got this: This has nothing to do with sendmail. The Return-Path: address is what gets passed through the SMTP envelope. Don't whitelist your domain. Regards, -sm

Re: False positives

Into my sendmail.cf I got this: -- # # Format of headers # # H?P?Return-Path: <$g> HReceived: $?sfrom $s $.$?_($?s$|from $.$_) $.$?{auth_type}(authenticated$?{auth_ssf} bits=${auth_ssf}$.) $.by $j ($v/$Z)$?r with $r$. id $

Re: False positives

Hi, following your suggestions, I've noticed that those mails got as Return-Path: my address that is in whitelist. Also, normally the first record in any mail is: From: but not in this cases. More, I'm using Sendmail 8.14.1 Spamassassin 3.2.3 Thanks 2007/8/20, Jari Fredriksson <[EMAIL PROTECTED]

Re: False positives

> Hi, > today I'm receiving spam messages as good ones as follow: > - > X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) > on ns2.dms.it X-Spam-Level: > X-Spam-Status: No, score=-76.1 required=5.0 > tests=DRUGS_ANXIETY, > DRUGS_ANXIETY_EREC,DRUGS_ERECTILE,DRUGS_MANYKINDS,DRUGS_MUSCLE, >

Re: False positives

FaberK schrieb: Where I'm wrong? URIBL_JP_SURBL,URIBL_SBL,URIBL_WS_SURBL,USER_IN_WHITELIST autolearn=no ^ -- Martin

Re: False Positives on Spamhaus?

It seems the data was cached. Let's see if it is correct after 24 hours later. Rick Macdougall wrote: Marc Perkel wrote: Getting a ton of false positives today on spamhaus. Generally they never get it wrong. Anyone else seeing this or is it just me? I see it on one of my servers trying to

Re: False Positives on Spamhaus?

Dan Barker wrote: > That's not "Consumer Friendly", that's just WRONG! > > Glad you found it. > ...well If you were doing "RBL-style" lookups, don't they exclusively return 127.* addresses on matches - i.e. "no such host" or "address 204.4.4.4" should both be treated as "no such host" as far as

RE: False Positives on Spamhaus?

That's not "Consumer Friendly", that's just WRONG! Glad you found it. Dan The caching DNS servers we not accessable to the email serrves so they had no DNS. I decided to point the /etc/resolv.conf file to opendns.org's DNS servers and it does some tricky things and what it returned caching

Re: False Positives on Spamhaus?

Jason Haar wrote: Marc Perkel wrote: Never mind - my fault. I don't think it was spamhaus but a screwed up DNS server. Care to share? I'm a bit concerned a "screwed up" DNS server could cause RBL software to start declaring IP addresses were blacklisted. How did that happen? Kin

RE: False Positives on Spamhaus?

> Getting a ton of false positives today on spamhaus. Generally > they never get it wrong. Anyone else seeing this or is it just me? That's a lot of confidence in a system over which you have no control. - Skip

Re: False Positives on Spamhaus?

Marc Perkel wrote: > Never mind - my fault. I don't think it was spamhaus but a screwed up > DNS server. Care to share? I'm a bit concerned a "screwed up" DNS server could cause RBL software to start declaring IP addresses were blacklisted. How did that happen? -- Cheers Jason Haar Information S

Re: False Positives on Spamhaus?

Marc Perkel wrote: Getting a ton of false positives today on spamhaus. Generally they never get it wrong. Anyone else seeing this or is it just me? Never mind - my fault. I don't think it was spamhaus but a screwed up DNS server.

Re: False Positives on Spamhaus?

Marc Perkel wrote: Getting a ton of false positives today on spamhaus. Generally they never get it wrong. Anyone else seeing this or is it just me? I see it on one of my servers trying to send to a fido.ca account (mobile phone account). www.dnsstuff.com and a local lookup says we aren't l

Re: False positives: [SPF failed: ]

Dave Pooser wrote: This looks familiar... as in I think I've fixed this before familiar. What version of SA are you using? SA 3.1.5, Perl 5.8.6, on Mac OS X Some more reading found that [SPF failed: ] is a normal result for an SPF timeout, so I set spf_timeout 30 and will see if that helps any

Re: False positives: [SPF failed: ]

> This looks familiar... as in I think I've fixed this before familiar. > What version of SA are you using? SA 3.1.5, Perl 5.8.6, on Mac OS X Some more reading found that [SPF failed: ] is a normal result for an SPF timeout, so I set spf_timeout 30 and will see if that helps any. -- Dave Pooser

Re: False positives: [SPF failed: ]

Dave Pooser wrote: So I've seen a few messages get falsely flagged in my quarantine range (5.0-9.9) and a common theme seems to be SPF_SOFTFAIL and SPF_HELO_SOFTFAIL both firing. An example is below; please forgive the minor obfuscation of sender and recipients local parts. Domains and all other

Re: false positives

http://wiki.apache.org/spamassassin/AutoWhitelist Thanks. > > From: Kamen TOMOV > Sent: Thu 07-Dec-06 18:00 > To: users@spamassassin.apache.org > Subject: Re: false positives > > > On четвъртък, Декември 07 2006, Sietse van Zanen wrote: > >> They contain too little

RE: false positives

good thing. More info on the AWL can be found here: http://wiki.apache.org/spamassassin/AutoWhitelist -Sietse From: Kamen TOMOV Sent: Thu 07-Dec-06 18:00 To: users@spamassassin.apache.org Subject: Re: false positives On четвъртък, Декември 07 2006, Sietse van Zanen wrote: > They contain to

Re: false positives

On четвъртък, Декември 07 2006, Sietse van Zanen wrote: > They contain too little information. All right - here is more information. I sent a message to a group and I got it classified as spam. Here is the report: * 1.7 SUBJECT_ENCODED_TWICE Subject: MIME encoded twice Here is how the subject

RE: false positives

They contain too little information. -Sietse From: Kamen TOMOV Sent: Thu 07-Dec-06 14:34 To: users@spamassassin.apache.org Subject: false positives Hi, I constantly have problems with spamcop these days. Could you tell me what's wrong with my messages so that I can fix it? Thanks, -- Камен

RE: False positives with RCVD_IN_NJABL_DUL, RCVD_IN_DSBL and RCVD_IN_SORBS_DUL

ינסקי; users@spamassassin.apache.org Subject: RE: False positives with RCVD_IN_NJABL_DUL, RCVD_IN_DSBL and RCVD_IN_SORBS_DUL Might be because of this header: Received: from IBM-707AC13EF89 (unknown [82.166.48.182]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requ

Re: False positives with RCVD_IN_NJABL_DUL, RCVD_IN_DSBL and RCVD_IN_SORBS_DUL

Leon, > I see a lot of FP with RCVD_IN_NJABL_DUL, RCVD_IN_DSBL and > RCVD_IN_SORBS_DUL from particulars users. > > This is very strange because a lot of those are coming from users on my > server (server with static IP and not a relay server). http://wiki.apache.org/spamassassin/TrustPath http:/

RE: False positives with RCVD_IN_NJABL_DUL, RCVD_IN_DSBL and RCVD_IN_SORBS_DUL

Might be because of this header: Received: from IBM-707AC13EF89 (unknown [82.166.48.182]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mydomain.ac.il (Postfix) with ESMTP id D17F019F2C for <[EMAIL PROTECTED]>; Mon, 27 Nov 2006 09:56:13 +0200 (IST) [EMAIL P

RE: False positives and Bayes

lists. Justin -Original Message- From: Anthony Peacock [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 2:25 AM To: users@spamassassin.apache.org Subject: Re: False positives and Bayes Hi, Justin Lloyd wrote: > Hello, all. > > A couple of months ago I built new mail s

Re: False positives and Bayes

Hi, Justin Lloyd wrote: Hello, all. A couple of months ago I built new mail servers to replace our existing ones that had aging mail configurations (and disparate OS configurations), running sendmail 8.12.6 and SA 3.0.2. Our configuration now consists of 2 RHEL 4 ES servers that share the load

Re: False positives in mails from dynamic IP addresses

Jarek 111 wrote: > Hello! > > I'm connecting to internet by ISP which gives me different IP every > time, but I'm sending mails by relay on fixed ip. As I see, spamassassin > is checking my dynamic IP address (RCVD_IN_DSBL, RCVD_IN_NJABL_DUL) and > marks my emails as spam. > Can I conf

Re: False positives "received from localhost"

Matt Kettler wrote: SA should ignore 127.0.0.1. However, you might want to double-check to see if your SA box resolves "localhost" as 127.0.0.1 or as some other IP. (I have seen boxes configured to do this...) There are also some older versions of NSCD that were vulnerable to a sort of revers

Re: False positives "received from localhost"

[EMAIL PROTECTED] wrote: I've had a couple of these since upgrading to 3.0.4. Headers with NO IP address in it, just this: Received: from localhost by (our server) I assume that if it's not a bug on my end, some users and/or servers are sending out from 127.0.0.1, which in turn sets off: RCVD

Re: false positives and negatives

It doesn't appear anyone else has replied so... > Sorry for the stupid question, but referring to the SpamAssassin web-site I > could not get an answer to the following question: > How do I safely remove my existing bayes database? Just have to remove the files. There are usually three as best

Re: false positives and negatives

On Tuesday 31 May 2005 10:13, Loren Wilton wrote: > The spam you show is difficult to handle. One important thing is there is > no url or other link in the message body to a drug site where people could > get the spammed product. I am assuking the original spam much have had > such, since a spam

Re: false positives and negatives

You have several options. I run about 40 of them. Most of them are found at http://www.rulesemporium.com/ the human generated Bayes databases that work on phrases rather than single words. {^_-} - Original Message - From: "Chavdar Videff" <[EMAIL PROTECTED]> On Tuesday 31 May 2005 05:16

Re: false positives and negatives

> Sorry for my late reply - my evening is your morning. > There is 1000 spam a week that leaks through and perhaps another 500-600 that > get filtered by spamassassin. > If my Bayes is poorly trained what options do I have. > Here is a typical letter that gets through. > > =

Re: false positives and negatives

On Tuesday 31 May 2005 05:16, Loren Wilton wrote: > > 1. At our site we get approx. 1000 spam a week. Most of it is rated below > > 2.0 > > > points and gets through (even if we set required hits to 3 and 2 for > > certain > > > mailboxes). > > I assume you mean here that you have 1000 spam a week

Re: false positives and negatives

From: "Chavdar Videff" <[EMAIL PROTECTED]> > Dear List, > > I know these are subject of the FAQ and the documentation, yet after I read > all of it I didn't get an answer to the following questions: > > 1. At our site we get approx. 1000 spam a week. Most of it is rated below 2.0 > points and gets

Re: false positives and negatives

Chavdar Videff wrote: Dear List, I know these are subject of the FAQ and the documentation, yet after I read all of it I didn't get an answer to the following questions: 1. At our site we get approx. 1000 spam a week. Most of it is rated below 2.0 points and gets through (even if we set requ

Re: false positives and negatives

> 1. At our site we get approx. 1000 spam a week. Most of it is rated below 2.0 > points and gets through (even if we set required hits to 3 and 2 for certain > mailboxes). I assume you mean here that you have 1000 spam a week leaking through? Or do you mean that you have 1000 spam a week TOTAL a

Re: false positives and negatives

Chavdar Videff wrote: Dear List, I know these are subject of the FAQ and the documentation, yet after I read all of it I didn't get an answer to the following questions: 1. At our site we get approx. 1000 spam a week. Most of it is rated below 2.0 points and gets through (even if we set requ

Re: false positives and negatives

Chavdar Videff wrote: Dear List, I know these are subject of the FAQ and the documentation, yet after I read all of it I didn't get an answer to the following questions: 1. At our site we get approx. 1000 spam a week. Most of it is rated below 2.0 points and gets through (even if we set requ

Re: False Positives

> How are you calling spamassassin? Are you calling it from procmail, or > are you using something like amavis? I didn't even think about how it was being called. After I read this I realized that its most likely my qmail-scanner causing it as it rewrites the header itself. I've removed the fast_

Re: False Positives

David Earp wrote: >>Try this add_header command instead. Note carefully the addition of >>quotation marks. >> >>add_header all Status "_YESNO_, score=_SCORE_ required=_REQD_ >>tests=_TESTSSCORES(,)_ autolearn=_AUTOLEARN_ version=_VERSION_" >> >> > >Added the quotes, no difference. I should not

Re: False Positives

> Try this add_header command instead. Note carefully the addition of > quotation marks. > > add_header all Status "_YESNO_, score=_SCORE_ required=_REQD_ > tests=_TESTSSCORES(,)_ autolearn=_AUTOLEARN_ version=_VERSION_" Added the quotes, no difference. I should note that my add_header is all on

Re: False Positives

Dave wrote: > Hi, I just recently upgraded to version 3.0.2 and now appear to be > receiving quite a few false positives where my previous installation > of 2.6.4 didn't have this problem. I am also having a problem getting > the rest results to display within the headers so I can determine what >

Re: False Positives: CONFIRMED_FORGED from yahoo.com

Message from user inside www.pair.com: >> Original message Apparently Yahoo has slightly changed the routing of groups messages: SA EvalTests.pm /from \[$IP_ADDRESS\] by \S+\.(?:groups|grp\.scd)\.yahoo\.com with NNFMP/ Received headers with NNFMP: from [66.218.69.1] by n22

Re: False Positives: CONFIRMED_FORGED from yahoo.com

"CONFIRMED_FORGED" FP messages just like this one. --Roger - Original Message - From: "jdow" <[EMAIL PROTECTED]> To: Sent: Saturday, November 27, 2004 1:47 PM Subject: Re: False Positives: CONFIRMED_FORGED from yahoo.com At this point you're stuck reading the &

Re: False Positives: CONFIRMED_FORGED from yahoo.com

At this point you're stuck reading the "FORGED_YAHOO_RCVD" tests in the 20_headers.cf file (at least on 2.63.) On my machine this is in /usr/share/spamassassin. On closer look it appears this is a web mail posting via yahoo to a yahoo group that fribbles is way around way more yahoo machines than m

Re: False Positives: CONFIRMED_FORGED from yahoo.com

riginal Message - From: "jdow" <[EMAIL PROTECTED]> To: Sent: Saturday, November 27, 2004 12:48 PM Subject: Re: False Positives: CONFIRMED_FORGED from yahoo.com Er, Roger, one might ask you what makes you think for a picosecond that the message is not forged. Trace the header

Re: False Positives: CONFIRMED_FORGED from yahoo.com

Er, Roger, one might ask you what makes you think for a picosecond that the message is not forged. Trace the headers backwards starting at the top. I see nothing there to inspire belief in the headers below the second "Received:" header. {^_^} - Original Message - From: "Jolly ArrRoger" <

Re: false positives from HELO_DYNAMIC_HCC and HELO_DYNAMIC_IPADDR rules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Kettler writes: > At 01:26 PM 10/29/2004, Mark Christoph wrote: > >As a result, I lowered the scores for HELO_DYNAMIC_HCC and > >HELO_DYNAMIC_IPADDR. > >I also forced bayes to relearn the email as ham, etc. The other > >problem is that the send

Re: false positives from HELO_DYNAMIC_HCC and HELO_DYNAMIC_IPADDR rules

At 01:26 PM 10/29/2004, Mark Christoph wrote: As a result, I lowered the scores for HELO_DYNAMIC_HCC and HELO_DYNAMIC_IPADDR. I also forced bayes to relearn the email as ham, etc. The other problem is that the sender of the message informed me that it is not a dynamically assigned address. It is

RE: false positives from HELO_DYNAMIC_HCC and HELO_DYNAMIC_IPADDR rules

-Original Message- From: Mark Christoph [mailto:[EMAIL PROTECTED] Sent: 29 October 2004 18:26 To: users@spamassassin.apache.org Subject: false positives from HELO_DYNAMIC_HCC and HELO_DYNAMIC_IPADDR rules We are running SA 3.0.1 site wide at my company and I had some false positives due

Re: false positives from HELO_DYNAMIC_HCC and HELO_DYNAMIC_IPADDR rules

Hi! Here are the scores: Content analysis details: (-98.8 points, 6.0 required) pts rule name description -- -- 0.5 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) 0.5 HELO_DYNAMIC_IPADDR

Re: False positives with FAKED_HOTMAIL_DAV

At 12:40 PM 10/23/2004 +0200, Frank Tore Johansen wrote: Hi, I have seen a handfull of these mails triggering FAKED_HOTMAIL_DAV, which is kind of bad since it adds 3.9 in version 2.63. The rule has been deleted from the 3.0 series due to FP problems. Suggestion: zero out the rule until you can upg