Re: KAM_SOMETLD_ARE_BAD_TLD false positive

[Kenneth Porter]

On 8/11/2021 7:39 AM, Jared Hall wrote:


*Maybe* a little more refinement could prevent it picking  up .hidden 
folders that have a BAD_TLD name.


/[A-z0-9]+\.(pw|stream|trade|press|top|date|guru|casa|online|cam|shop|club|bar)(\s|$|\/)/i 



The CVS/Kodak uri would still fail on this pattern, as the BAD_TLD is 
the extension in the final path component.


My initial idea for fixing this in the negative pattern wouldn't work 
because a spammer could use https://example.badtld/example.badtld to 
sneak through.


Perhaps something like 
"//[^/]+\.(pw|stream|trade|press|top|date|guru|casa|online|cam|shop|club|bar)($|/)"i 
?


That might also need a matcher on the end for the optional port number.

BTW, does SA permit use of Perl-style regex delimiters to avoid leaning 
toothpick syndrome?


https://en.wikipedia.org/wiki/Leaning_toothpick_syndrome

Re: KAM_SOMETLD_ARE_BAD_TLD false positive

[Jared Hall]

Kenneth Porter wrote:


uri  __KAM_SOMETLD_ARE_BAD_TLD_URI 
/\.(pw|stream|trade|press|top|date|guru|casa|online|cam|shop|club|bar)($|\/)/i




I have a client whose NVR writes its archived video spools to a .cam 
folder on their server.  Heaven forbid ".well-known" ever becomes a TLD :)


*Maybe* a little more refinement could prevent it picking  up .hidden 
folders that have a BAD_TLD name.


/[A-z0-9]+\.(pw|stream|trade|press|top|date|guru|casa|online|cam|shop|club|bar)(\s|$|\/)/i 



$0.02,

-- Jared Hall

Re: KAM_SOMETLD_ARE_BAD_TLD false positive

[Kenneth Porter]

--On Wednesday, August 11, 2021 12:29 AM -0400 "Kevin A. McGrail" 
 wrote:



Hi Kenneth, the ruleset is designed for a system scoring over 5.0.

Did the rule from the cell provider cause an fp?

Is your threshold higher than 5.0?


I use the stock threshold of 5.0. I'm using the ruleset via the channel 
distribution on a CentOS (RHEL) 7 system.



There is a way to report problems listed in the file but feel free to
contact me off list and I'll tell you how to send me a sample.


Thanks, now that I know where to look, I submitted the sample with your web 
form.


Perhaps you could echo the support information to the main KAM web page? 
That's where I looked because that's where I found the channel information.




That's what I found from following the link here:

Re: KAM_SOMETLD_ARE_BAD_TLD false positive

[Kevin A. McGrail]

Hi Kenneth, the ruleset is designed for a system scoring over 5.0.

Did the rule from the cell provider cause an fp?

Is your threshold higher than 5.0?

There is a way to report problems listed in the file but feel free to
contact me off list and I'll tell you how to send me a sample.

Regards, KAM

On Tue, Aug 10, 2021, 22:00 Kenneth Porter  wrote:

> My cellular supplier has a weekly bag of goodies (coupons, schwag) and
> last
> week's included a free photo refrigerator magnet from CVS. So I signed up
> a
> CVS/Kodak account to put in my order. Like most such offers, they start
> sending me marketing mail, and the first one hit KAM_SOMETLD_ARE_BAD_TLD,
> with a 5.0 score. I'll be turning that score down (probably to 3.5) but I
> think the rule itself is the issue. It's firing on a uri that has dot shop
> as the last part of the path in a legitimate dotcom uri. Perhaps the rule
> can check for the absence of a single slash before the offending TLD.
> There's a helper rule that checks for false positives that could be
> replaced with one that ignores TLDs after an isolated slash in a uri.
>
> Do the KAM rules have an issue tracker where this kind of report can be
> made?
>
> The rule:
>
> header  __KAM_SOMETLD_ARE_BAD_TLD_FROM  From:addr =~
> /\.(pw|stream|trade|press|top|date|guru|casa|online|cam|shop|club|b
> uri  __KAM_SOMETLD_ARE_BAD_TLD_URI
>
> /\.(pw|stream|trade|press|top|date|guru|casa|online|cam|shop|club|bar)($|\/)/i
>
> #FPs
> uri  __KAM_SOMETLD_ARE_BAD_TLD_URI_NEGATIVE
> /(^|\b)td\.date|div\.top($|\/)/i
>
> meta KAM_SOMETLD_ARE_BAD_TLD(__KAM_SOMETLD_ARE_BAD_TLD_FROM) ||
> (__KAM_SOMETLD_ARE_BAD_TLD_URI && !__KAM_SOMETLD_ARE_BAD_TLD
> describeKAM_SOMETLD_ARE_BAD_TLD .stream, .trade, .pw, .top,
> .press, .guru, .casa, .online, .cam, .shop, .bar, .club & .d
> score   KAM_SOMETLD_ARE_BAD_TLD 5.0
>
>

Re: BIGNUM_EMAILS false positive

[John Hardin]

On Fri, 26 Feb 2021, Matus UHLAR - fantomas wrote:


Hello,

it seems that BIGNUM_EMAILS on signatures containing e-mail address after
telephone number like:

Mobil: +421 904 000 111
e-mail: addr...@example.com

Feb 26 14:25:49.116 [7638] dbg: rules: ran body rule __BIGNUM_EMAILS ==> 
got hit: "000 111 e-mail"


OK, I will see about tuning it. Thanks for the report.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.org pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  If you trust the government, you obviously failed history class.
   -- Don Freeman
---
 272 days since the first private commercial manned orbital mission (SpaceX)

Re: __DOS_DIRECT_TO_MX false positive

[premax]

John Hardin wrote
> The problem is that there are no Received headers internal to his domain, 
> and that makes it look like a MUA is directly contacting your MTA to send 
> an email - hence, "DIRECT_TO_MX".
> 
> If you can, advise the sender to not remove all the Received headers from 
> their email before sending it to others. There should be at least one: the 
> Received header for his MTA accepting the message from his MUA.

Thank you for your reply, now I can see the issue.
I have contacted sender's ISP and asked for not removing 1st Received
header.

regards
PP




--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html

Re: __DOS_DIRECT_TO_MX false positive

[RW]

On Sat, 1 Feb 2020 17:38:52 +0100
Matus UHLAR - fantomas wrote:

> >On Thu, 30 Jan 2020 15:37:47 -0800 (PST)
> >John Hardin wrote:  
> >> That a given rule hits on some ham does not make the rule a FP.
> >> This rule is working as designed.  
> 
> On 31.01.20 15:09, RW wrote:
> >DOS_OUTLOOK_TO_MX is defined in 72_active.cf, but its score is in
> >50_scores.cf, set 10 years ago. Is that supposed to happen?  
> 
> if by "that" you mean DOS_OUTLOOK_TO_MX hitting, 

No, I meant a rule that's defined in 72_active.cf not having a
modern generated score in 72_scores.cf. 

Re: __DOS_DIRECT_TO_MX false positive

[Matus UHLAR - fantomas]

On Thu, 30 Jan 2020 15:37:47 -0800 (PST)
John Hardin wrote:

That a given rule hits on some ham does not make the rule a FP. This
rule is working as designed.


On 31.01.20 15:09, RW wrote:

DOS_OUTLOOK_TO_MX is defined in 72_active.cf, but its score is in
50_scores.cf, set 10 years ago. Is that supposed to happen?


if by "that" you mean DOS_OUTLOOK_TO_MX hitting, it's common in companies
without authentication and with single mailserver. 


...and, of course, where someone removes or does not add Received: headers.

problem could be lowered by adding that server to trusted_networks although
I'm not sure whether that kind of servers should be added there...
--
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.
99 percent of lawyers give the rest a bad name.

Re: __DOS_DIRECT_TO_MX false positive

[RW]

On Thu, 30 Jan 2020 15:37:47 -0800 (PST)
John Hardin wrote:

> That a given rule hits on some ham does not make the rule a FP. This
> rule is working as designed.

DOS_OUTLOOK_TO_MX is defined in 72_active.cf, but its score is in
50_scores.cf, set 10 years ago. Is that supposed to happen?

Re: __DOS_DIRECT_TO_MX false positive

[Kevin A. McGrail]

On 1/30/2020 6:37 PM, John Hardin wrote:
> The problem is that there are no Received headers internal to his
> domain, and that makes it look like a MUA is directly contacting your
> MTA to send an email - hence, "DIRECT_TO_MX".
>
> If you can, advise the sender to not remove all the Received headers
> from their email before sending it to others. There should be at least
> one: the Received header for his MTA accepting the message from his MUA.
>
> Absent that, you could whitelist his domain.
>
> That message is not being scored as spam, even if you weren't
> increasing the threshold from the default:
>
>> X-Spam-Flag: NO
>> X-Spam-Score: 4.351
>> X-Spam-Level: 
>> X-Spam-Status: No, score=4.351 tagged_above=-9 required=6.31
>
> That a given rule hits on some ham does not make the rule a FP. This
> rule is working as designed.


I just wanted to +1 John's analysis on this issue and he is dead-on.  I
also want to reiterate that a FP is only when a email is flagged as
spam.  Some rules are designed to fire in cases that do not indicate
spam or ham status except when analyzed in totality with all the other
scores.

Regards,

KAM

-- 
Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Re: __DOS_DIRECT_TO_MX false positive

[John Hardin]

On Thu, 30 Jan 2020, premax wrote:


Hello there,

The sender is using Outlook and his own mail server. Mail comes to my 
server and scores against DOS_OUTLOOK_TO_MX, because of 
__DOS_DIRECT_TO_MX false positive. I've been looking into message 
headers for hours and see nothing strange over there. 'Received' header 
are present. Why is that happening?


Here go message headers:


...pruned a bit to focus...


Received: from localhost (localhost [127.0.0.1])
   by mail.MYSERVER.COM (Postfix) with ESMTP id 8FF5CF801E2
   for ; Wed, 29 Jan 2020 15:08:48 +0100 (CET)
   SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
   ZABOJCASPAMU_BULK_SIGNATURE=0.01, ZABOJCASPAMU_FSL_HTML_COMMENT=0.7,
   ZABOJCASPAMU_SMTPNUMBER=0.01] autolearn=no autolearn_force=no
Received: from mail.MYSERVER.COM ([172.20.11.96])
   by localhost (ln2.MYSERVER.COM [127.0.0.1]) (amavisd-new, port 10024)
   with ESMTP id hH6H7WQcFFvZ
   for ;
   Wed, 29 Jan 2020 15:08:44 +0100 (CET)
Received: from cache35.HISSERVER.COM (cache35.HISSERVER.COM [xx.xx.241.219])
   by mail.MYSERVER.COM (Postfix) with ESMTPS id 5797DF801DE
   for ; Wed, 29 Jan 2020 15:08:44 +0100 (CET)


...and that's it.

The problem is that there are no Received headers internal to his domain, 
and that makes it look like a MUA is directly contacting your MTA to send 
an email - hence, "DIRECT_TO_MX".


If you can, advise the sender to not remove all the Received headers from 
their email before sending it to others. There should be at least one: the 
Received header for his MTA accepting the message from his MUA.


Absent that, you could whitelist his domain.

That message is not being scored as spam, even if you weren't increasing 
the threshold from the default:



X-Spam-Flag: NO
X-Spam-Score: 4.351
X-Spam-Level: 
X-Spam-Status: No, score=4.351 tagged_above=-9 required=6.31


That a given rule hits on some ham does not make the rule a FP. This rule 
is working as designed.



--
 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
---
  The problem is when people look at Yahoo, slashdot, or groklaw and
  jump from obvious and correct observations like "Oh my God, this
  place is teeming with utter morons" to incorrect conclusions like
  "there's nothing of value here".-- Al Petrofsky, in Y! SCOX
---
 2 days until the 17th anniversary of the loss of STS-107 Columbia

Re: FORGED_HOTMAIL_RCVD2 false positive

[Pedro David Marco]

 Thanks/ Grazie mile Giovanni...
PedroD
On Monday, January 29, 2018, 8:27:01 AM GMT+1, Giovanni Bechis 
 wrote:  
 
 On 01/29/18 06:00, Alex wrote:
> Hi,
> 
>> FORGED_HOTMAIL_RCVD2 (hotmail.com 'From' address, but no 'Received:')
>> triggers for valid hotmail messages...  (SA 3.4.1)
>>
>> This small change solves the problem but i do not know whether it is the
>> correct way...    maybe "hotmail" string should be changed widelly to
>> "outlook|hotmail"...
>>
>> /usr/local/share/perl/5.14.2/Mail/SpamAssassin/Plugin/HeaderEval.pm.orig
>> 357c357
>> <  if ($rcvd =~ /from \S*\.hotmail.com \(\[$IP_ADDRESS\][ \):]/ && $ip)
>> ---
>>>  if ($rcvd =~ /from \S*\.(?:outlook|hotmail)\.com \(\[$IP_ADDRESS\][
>>> \):]/ && $ip)
> 
> Any status on this? I believe you were going to open a bug report? It
> doesn't appear this fix (or any fix) has been included to address the
> hotmail fp's.
> 
Committed yesterday by davej@
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7534
 Cheers
  Giovanni
  

Re: FORGED_HOTMAIL_RCVD2 false positive

[Giovanni Bechis]

On 01/29/18 06:00, Alex wrote:
> Hi,
> 
>> FORGED_HOTMAIL_RCVD2 (hotmail.com 'From' address, but no 'Received:')
>> triggers for valid hotmail messages...  (SA 3.4.1)
>>
>> This small change solves the problem but i do not know whether it is the
>> correct way...maybe "hotmail" string should be changed widelly to
>> "outlook|hotmail"...
>>
>> /usr/local/share/perl/5.14.2/Mail/SpamAssassin/Plugin/HeaderEval.pm.orig
>> 357c357
>> <   if ($rcvd =~ /from \S*\.hotmail.com \(\[$IP_ADDRESS\][ \):]/ && $ip)
>> ---
>>>   if ($rcvd =~ /from \S*\.(?:outlook|hotmail)\.com \(\[$IP_ADDRESS\][
>>> \):]/ && $ip)
> 
> Any status on this? I believe you were going to open a bug report? It
> doesn't appear this fix (or any fix) has been included to address the
> hotmail fp's.
> 
Committed yesterday by davej@
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7534
 Cheers
  Giovanni

Re: FORGED_HOTMAIL_RCVD2 false positive

[Alex]

Hi,

> FORGED_HOTMAIL_RCVD2 (hotmail.com 'From' address, but no 'Received:')
> triggers for valid hotmail messages...  (SA 3.4.1)
>
> This small change solves the problem but i do not know whether it is the
> correct way...maybe "hotmail" string should be changed widelly to
> "outlook|hotmail"...
>
> /usr/local/share/perl/5.14.2/Mail/SpamAssassin/Plugin/HeaderEval.pm.orig
> 357c357
> <   if ($rcvd =~ /from \S*\.hotmail.com \(\[$IP_ADDRESS\][ \):]/ && $ip)
> ---
>>   if ($rcvd =~ /from \S*\.(?:outlook|hotmail)\.com \(\[$IP_ADDRESS\][
>> \):]/ && $ip)

Any status on this? I believe you were going to open a bug report? It
doesn't appear this fix (or any fix) has been included to address the
hotmail fp's.

Re: FORGED_HOTMAIL_RCVD2 false positive

[Giovanni Bechis]

On 01/17/18 19:29, David Jones wrote:
> On 01/17/2018 11:59 AM, Giovanni Bechis wrote:
>> On 01/17/18 07:14, Pedro David Marco wrote:
>>> Hi,
>>>
>>> FORGED_HOTMAIL_RCVD2 (hotmail.com 'From' address, but no 'Received:') 
>>> triggers for valid hotmail messages...  (SA 3.4.1)
>>>
>>> This small change solves the problem but i do not know whether it is the 
>>> correct way...    maybe "hotmail" string should be changed widelly to 
>>> "outlook|hotmail"...
>>>
>>> /usr/local/share/perl/5.14.2/Mail/SpamAssassin/Plugin/HeaderEval.pm.orig
>>> 357c357
>>> <   if ($rcvd =~ /from \S*\.hotmail.com \(\[$IP_ADDRESS\][ \):]/ && $ip)
>>> ---
     if ($rcvd =~ /from \S*\.(?:outlook|hotmail)\.com \(\[$IP_ADDRESS\][ 
 \):]/ && $ip)
>>>
>>>
>>> -
>>> PedroD
>> Can you provide an email sample for a valid email message that triggers this 
>> rule ?
>>   Thanks
>>    Giovanni
>>
> 
> I am seeing about a hundred false positives a day in my mail flow:
> 
> https://pastebin.com/wQwACuhB
> 
> Definitely need to get a bug entered and patch HeaderEval.pm soon for version 
> 3.4.2.
> 
I'll take care of it.
 Giovanni

Re: FORGED_HOTMAIL_RCVD2 false positive

[David Jones]

On 01/17/2018 11:59 AM, Giovanni Bechis wrote:

On 01/17/18 07:14, Pedro David Marco wrote:

Hi,

FORGED_HOTMAIL_RCVD2 (hotmail.com 'From' address, but no 'Received:') triggers 
for valid hotmail messages...  (SA 3.4.1)

This small change solves the problem but i do not know whether it is the correct way...    maybe 
"hotmail" string should be changed widelly to "outlook|hotmail"...

/usr/local/share/perl/5.14.2/Mail/SpamAssassin/Plugin/HeaderEval.pm.orig
357c357
<   if ($rcvd =~ /from \S*\.hotmail.com \(\[$IP_ADDRESS\][ \):]/ && $ip)
---

    if ($rcvd =~ /from \S*\.(?:outlook|hotmail)\.com \(\[$IP_ADDRESS\][ \):]/ 
&& $ip)



-
PedroD

Can you provide an email sample for a valid email message that triggers this 
rule ?
  Thanks
   Giovanni



I am seeing about a hundred false positives a day in my mail flow:

https://pastebin.com/wQwACuhB

Definitely need to get a bug entered and patch HeaderEval.pm soon for 
version 3.4.2.


--
David Jones

Re: FORGED_HOTMAIL_RCVD2 false positive

[Giovanni Bechis]

On 01/17/18 07:14, Pedro David Marco wrote:
> Hi,
> 
> FORGED_HOTMAIL_RCVD2 (hotmail.com 'From' address, but no 'Received:') 
> triggers for valid hotmail messages...  (SA 3.4.1)
> 
> This small change solves the problem but i do not know whether it is the 
> correct way...    maybe "hotmail" string should be changed widelly to 
> "outlook|hotmail"...
> 
> /usr/local/share/perl/5.14.2/Mail/SpamAssassin/Plugin/HeaderEval.pm.orig
> 357c357
> <   if ($rcvd =~ /from \S*\.hotmail.com \(\[$IP_ADDRESS\][ \):]/ && $ip)
> ---
>>   if ($rcvd =~ /from \S*\.(?:outlook|hotmail)\.com \(\[$IP_ADDRESS\][ \):]/ 
>>&& $ip)
> 
> 
> -
> PedroD
Can you provide an email sample for a valid email message that triggers this 
rule ?
 Thanks
  Giovanni

Re: URI_OBFU_WWW false-positive

[John Hardin]

On Fri, 4 Mar 2016, Alex wrote:


Hi,

Is there something that can be done to improve this rule?

ran body rule URI_OBFU_WWW ==> got hit: "www..facebook.com"

2.45 points, putting it over the edge in a number of messages where
the sender accidentally typed it wrong in their signature, is just too
much.


I'll take a look.

--
 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
---
  We should endeavour to teach our children to be gun-proof
  rather than trying to design our guns to be child-proof
---
 9 days until Albert Einstein's 137th Birthday

Re: BODY_URI_ONLY: False-Positive

[Reindl Harald]

Am 12.07.2015 um 16:38 schrieb RW:

On Sun, 12 Jul 2015 16:22:09 +0200
Reindl Harald wrote:




What I don't get is where the URI is.


i guess the mailaddress Reply to: @***


That'll be it


on the other hand that one did not hit it while save the message as eml 
and pass it through spmac hits BODY_URI_ONLY - strange


X-Spam-Flag: Yes
X-Spam-Status: Yes, score=7.8, tag-level=5.5, block-level=8.0,
envelope=unibo.it, from=unibo.it
X-Spam-Report: Flag: Yes,   *  7.5 BAYES_99 BODY: Bayes spam probability is 
99
 to 100%*  [score: 1.]  * -0.1 SPF_PASS SPF: sender matches SPF
 record	* -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover 
relay
 domain	*  0.4 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%	* 


 [score: 1.]
X-Virus-Scanned: Yes
Return-Path: prvs=06413078d0=valentina.po...@unibo.it
Content-Language: it-IT
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I have a confidential deal My email is raddailttod...@hotmail.com



signature.asc
Description: OpenPGP digital signature

Re: BODY_URI_ONLY: False-Positive

[RW]

On Sun, 12 Jul 2015 13:35:53 +0200
Reindl Harald wrote:

 BODY_URI_ONLY
 Message body is only a URI in one line of text or for an image
 
 i guess one problem is the text/html instead text/plain but anyways
 that mailbody hardly qualifies for BODY_URI_ONLY

I just spotted a bug in that rule

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7219

but I don't think that's happening here. 

BODY_URI_ONLY can't tell the difference between just a URI and a URI in
a single paragraph. It seems that all that text is counted as one
paragraph - probably because of the misuse of text/html.

What I don't get is where the URI is.





 _
 
 Content-Type: text/html; charset=iso-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Hello,=20
 
 Do you have availability of 2(double rooms) for 4 quests for 7 nights
 in = your hotel?=20
 
 Check in date: November 6th, 2015.
 
 Check out date: November 13th, 2015.
 
 Reply to: @***
 
 Your prompt response would be kind,=20
 
 Robin.
 

Re: BODY_URI_ONLY: False-Positive

[RW]

On Sun, 12 Jul 2015 16:22:09 +0200
Reindl Harald wrote:

 
  What I don't get is where the URI is.
 
 i guess the mailaddress Reply to: @***

That'll be it.

Re: BODY_URI_ONLY: False-Positive

[Reindl Harald]

Am 12.07.2015 um 16:19 schrieb RW:

On Sun, 12 Jul 2015 13:35:53 +0200
Reindl Harald wrote:


BODY_URI_ONLY
Message body is only a URI in one line of text or for an image

i guess one problem is the text/html instead text/plain but anyways
that mailbody hardly qualifies for BODY_URI_ONLY


I just spotted a bug in that rule

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7219

but I don't think that's happening here.

BODY_URI_ONLY can't tell the difference between just a URI and a URI in
a single paragraph. It seems that all that text is counted as one
paragraph - probably because of the misuse of text/html.

What I don't get is where the URI is.


i guess the mailaddress Reply to: @***


_

Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=20

Do you have availability of 2(double rooms) for 4 quests for 7 nights
in = your hotel?=20

Check in date: November 6th, 2015.

Check out date: November 13th, 2015.

Reply to: @***

Your prompt response would be kind,=20

Robin.



--

Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / CISO / Software-Development
m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33
icq: 154546673, http://www.thelounge.net/

http://www.thelounge.net/signature.asc.what.htm



signature.asc
Description: OpenPGP digital signature

Re: possible false positive with FORGED_YAHOO_RCVD?

[listsb-spamassassin]

 On Nov 30, 2014, at 15.42, Benny Pedersen m...@junc.eu wrote:
 
 On 30. nov. 2014 21.12.06 listsb-spamassas...@bitrate.net wrote:
 
 http://dpaste.com/3XTYV0V.txt
 
 Is trusted_networks and internal_networks correct both for ipv4 and ipv6 ?
 
 Does it match settings in amavisd ?
 
 Both sa and amavisd need to know ALL your own ips including all non routeble 
 :)

after getting sidetracked briefly, i'm back to this.  what settings in amavis 
need to match 
trusted_networks/internal_networks? [hopefully not too off topic a question]

-ben

Re: possible false positive with FORGED_YAHOO_RCVD?

[Benny Pedersen]

On 30. nov. 2014 21.12.06 listsb-spamassas...@bitrate.net wrote:


http://dpaste.com/3XTYV0V.txt


Is trusted_networks and internal_networks correct both for ipv4 and ipv6 ?

Does it match settings in amavisd ?

Both sa and amavisd need to know ALL your own ips including all non routeble :)

Re: SpamAssassin false positive bayes with attachments

[Benny Pedersen]

On October 6, 2014 3:03:30 PM jdime abuse jdimeab...@gmail.com wrote:


I have been seeing some issues with bayes detection from base64 strings
within attachments causing false positives.


Train more data then, bayes needs more data to prevent it


Example:
Oct  6 09:02:14.374 [15869] dbg: bayes: token 'H4f' = 0.71186828264
Oct  6 09:02:14.374 [15869] dbg: bayes: token 'wx2' = 0.68644662127
Oct  6 09:02:14.374 [15869] dbg: bayes: token 'z4f' = 0.68502147581
Oct  6 09:02:14.378 [15869] dbg: bayes: token '0vf' = 0.66604823748


Above is pretty normal for how bayes works


Is there a solution to prevent triggering bayes from the base64 data in an
attachment? It was my impression that attachments should not trigger bayes
data, but it seems that it is parsing it as text rather than an attachment.


Dokumentation is in

perldoc Mail::SpamAssassin::Conf
perldoc Mail::SpamAssassin::Plugin::Bayes

If not dokumented its not supported


This is with SpamAssassin v3.3.


While 3.4 is now stable

Re: SpamAssassin false positive bayes with attachments

[Karsten Bräckelmann]

On Mon, 2014-10-06 at 09:03 -0400, jdime abuse wrote:
 I have been seeing some issues with bayes detection from base64
 strings within attachments causing false positives.
 
 Example:
 Oct  6 09:02:14.374 [15869] dbg: bayes: token 'H4f' = 0.71186828264
 Oct  6 09:02:14.374 [15869] dbg: bayes: token 'wx2' = 0.68644662127
 Oct  6 09:02:14.374 [15869] dbg: bayes: token 'z4f' = 0.68502147581
 Oct  6 09:02:14.378 [15869] dbg: bayes: token '0vf' = 0.66604823748
 
 Is there a solution to prevent triggering bayes from the base64 data
 in an attachment? It was my impression that attachments should not
 trigger bayes data, but it seems that it is parsing it as text rather
 than an attachment.

Bayes tokens are basically taken from rendered, textual body parts (and
mail headers). Attachments are not tokenized.

Unless the message's MIME-structure is severely broken, these tokens
appear somewhere other than a base64 encoded attachment. Can you provide
a sample uploaded to a pastebin?


-- 
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128  (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: SpamAssassin false positive bayes with attachments

[David F. Skoll]

On Mon, 06 Oct 2014 21:28:02 +0200
Karsten Bräckelmann guent...@rudersport.de wrote:

 Unless the message's MIME-structure is severely broken, these tokens
 appear somewhere other than a base64 encoded attachment.

Agreed, and a Qmail bounce message is a prime example of a message
whose MIME structure is severely broken.  I wonder if that's what
the OP is seeing?

Qmail's bounce message starts with:

Hi. This is the

and then (sometimes) includes the entire raw MIME message as a giant
glob of text.

http://cr.yp.to/proto/qsbmf.txt

We have custom code specifically to detect such messages and avoid
tokenizing them. :(

Regards,

David.

Re: SpamAssassin false positive bayes with attachments

[Joe Albertson]

After reading your reply, I re-examined the message and found the case was
an incorrect Content-Type:
~~~
Content-Type: text/plain; charset=windows-1250;
 name=pdfname.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename=pdfname.pdf
~~~

So it was scanning the base64 as text and tokenizing it.

On Mon, Oct 6, 2014 at 3:28 PM, Karsten Bräckelmann guent...@rudersport.de
wrote:

 On Mon, 2014-10-06 at 09:03 -0400, jdime abuse wrote:
  I have been seeing some issues with bayes detection from base64
  strings within attachments causing false positives.
 
  Example:
  Oct  6 09:02:14.374 [15869] dbg: bayes: token 'H4f' = 0.71186828264
  Oct  6 09:02:14.374 [15869] dbg: bayes: token 'wx2' = 0.68644662127
  Oct  6 09:02:14.374 [15869] dbg: bayes: token 'z4f' = 0.68502147581
  Oct  6 09:02:14.378 [15869] dbg: bayes: token '0vf' = 0.66604823748
 
  Is there a solution to prevent triggering bayes from the base64 data
  in an attachment? It was my impression that attachments should not
  trigger bayes data, but it seems that it is parsing it as text rather
  than an attachment.

 Bayes tokens are basically taken from rendered, textual body parts (and
 mail headers). Attachments are not tokenized.

 Unless the message's MIME-structure is severely broken, these tokens
 appear somewhere other than a base64 encoded attachment. Can you provide
 a sample uploaded to a pastebin?


 --
 char *t=\10pse\0r\0dtu\0.@ghno
 \x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
 main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8?
 c=1:
 (c=*++x); c128  (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0;
 }}}

Re: CTYPE_NULL false-positive for Content-Type: multipart/related ?

[John Hardin]

On Thu, 8 Sep 2011, Edward Prendergast wrote:


I'm seeing CTYPE_NULL triggering for certain messages from gmail.

If I compare a message that doesn't trigger CTYPE_NULL:

Content-Type: multipart/related;

With one that does:

Content-Type: multipart/related;


CTYPE_NULL certainly shouldn't fire on either of those. Are they really 
identical, or is that a cut-and-paste error? Are those complete copies of 
ALL of the Content-Type headers in the message?


Would it be possible to post the full FP message to a pastebin? Given what 
we're looking at, anonymization of email addresses, host names and body 
content shouldn't affect the analysis, just make sure you don't alter any 
of the MIME-related headers.


--
 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
---
  When I say I don't want the government to do X, do not
  automatically assume that means I don't want X to happen.
---
 9 days until the 224th anniversary of the signing of the U.S. Constitution

Re: CTYPE_NULL false-positive for Content-Type: multipart/related ?

[Edward Prendergast]

On 08/09/11 16:23, John Hardin wrote:

On Thu, 8 Sep 2011, Edward Prendergast wrote:


I'm seeing CTYPE_NULL triggering for certain messages from gmail.

If I compare a message that doesn't trigger CTYPE_NULL:

Content-Type: multipart/related;

With one that does:

Content-Type: multipart/related;


CTYPE_NULL certainly shouldn't fire on either of those. Are they 
really identical, or is that a cut-and-paste error? Are those complete 
copies of ALL of the Content-Type headers in the message?


Would it be possible to post the full FP message to a pastebin? Given 
what we're looking at, anonymization of email addresses, host names 
and body content shouldn't affect the analysis, just make sure you 
don't alter any of the MIME-related headers.




Sorry, that WAS a typo, I meant to show a more standard content-type 
from a message not triggering CTYPE_NULL:


Content-Type: multipart/mixed;

It's quite heavily redacted, but haven't made any changes to the MIME 
header stuff.


https://gist.github.com/1203746

Thanks


The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any action taken or
omitted to be taken in reliance on it, any form of reproduction,
dissemination, copying, disclosure, modification, distribution and/or
publication of this E-mail message is strictly prohibited and may be
unlawful. If you have received this E-mail message in error, please notify
us immediately. Please also destroy and delete the message from your
computer.

Re: hostkarma false positive

[Jari Fredriksson]

On 11.1.2010 10:35, Michael Monnerie wrote:
 Another FP on hostkarma:
 
 bsmtp5.bon.at[195.3.86.187]
 
 Please investigate and fix. And put them on YELLOW, they are an ISP here 
 in Austria. Please check bsmtp[1-9] also.
 

Hello. Your PGP key has expired, my software says. Just FYI.

-- 
http://www.iki.fi/jarif/

You will step on the night soil of many countries.



signature.asc
Description: OpenPGP digital signature

Re: hostkarma false positive

[Christian Brel]

On Mon, 11 Jan 2010 09:35:37 +0100
Michael Monnerie michael.monne...@is.it-management.at wrote:

 Another FP on hostkarma:
 
 bsmtp5.bon.at[195.3.86.187]
 
 Please investigate and fix. And put them on YELLOW, they are an ISP
 here in Austria. Please check bsmtp[1-9] also.
 
It's also listed in:
195.3.86.187BLACKLISTED:ips.backscatterer.org

-- 
Multi-platform Freeware IP Blacklist checker
http://www.spampig.org.uk/dnsblcheck.php

Re: hostkarma false positive

[Kai Schaetzl]

Folks, can you please report this to these lists. This mailing list is 
*not* for reporting FPs on RBLs! Thanks.

Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com

Re: hostkarma false positive

[Marc Perkel]

Fixed

Michael Monnerie wrote:

Another FP on hostkarma:

bsmtp5.bon.at[195.3.86.187]

Please investigate and fix. And put them on YELLOW, they are an ISP here 
in Austria. Please check bsmtp[1-9] also.


  

Re: hostkarma false positive

[Marc Perkel]

Christian Brel wrote:

On Mon, 11 Jan 2010 09:35:37 +0100
Michael Monnerie michael.monne...@is.it-management.at wrote:

  

Another FP on hostkarma:

bsmtp5.bon.at[195.3.86.187]

Please investigate and fix. And put them on YELLOW, they are an ISP
here in Austria. Please check bsmtp[1-9] also.



It's also listed in:
195.3.86.187BLACKLISTED:ips.backscatterer.org

  
Backscatterer.org isn't a real blacklist. They have us blacklisted as 
well. Anyone using them is making a serious mistake.

Re: hostkarma false positive

[Daniel J McDonald]

On Mon, 2010-01-11 at 06:46 -0800, Marc Perkel wrote:

 Christian Brel wrote: 
  It's also listed in:
  195.3.86.187BLACKLISTED:ips.backscatterer.org  
 Backscatterer.org isn't a real blacklist. They have us blacklisted as
 well. Anyone using them is making a serious mistake.

It's probably worth a point or so for blocking useless bounces:

meta RCVD_IN_BACKSCATTER_RELAY  (__BOUNCE_FROM_DAEMON  __RCVD_IN_BACKSCATTER) 
 ! __RCVD_IN_UCEWHITE
tflags RCVD_IN_BACKSCATTER_RELAYnet
describe RCVD_IN_BACKSCATTER_RELAY  received from a host that does a lot of 
backscatter
score   RCVD_IN_BACKSCATTER_RELAY   1.30


-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX
www.austinenergy.com

Re: hostkarma false positive

[Christian Brel]

On Mon, 11 Jan 2010 06:46:55 -0800
Marc Perkel m...@perkel.com wrote:

 
 
 Christian Brel wrote:
  On Mon, 11 Jan 2010 09:35:37 +0100
  Michael Monnerie michael.monne...@is.it-management.at wrote:
 

  Another FP on hostkarma:
 
  bsmtp5.bon.at[195.3.86.187]
 
  Please investigate and fix. And put them on YELLOW, they are an ISP
  here in Austria. Please check bsmtp[1-9] also.
 
  
  It's also listed in:
  195.3.86.187BLACKLISTED:ips.backscatterer.org
 

 Backscatterer.org isn't a real blacklist. They have us blacklisted as 
 well. Anyone using them is making a serious mistake.
 

mus...t try and resist tem..tation..

Neither is the rest of UCEProtect...

Damn it came out, I tried to stop it..

Re: HELO_DYNAMIC_IPADDR false positive

[mouss]

Matus UHLAR - fantomas a écrit :
 On 19.08.09 00:48, mouss wrote:
 The name of the rule is worng, but the result is ok. Instead of
 dynamic, I suggest: UMO for Unidentifiable Mailing Object. whether
 static-ip- is static or not doesn't matter. a lot of junk comes from
 such hosts, and we can't report/complain to a domain, since the domain
 is that of the SP (and getting SPs to block abuse sources have proven
 vain).
 
 Matus UHLAR - fantomas a écrit :
 I'd be glad to see if there's any difference in percentage of spam from
 dynamic and static (generic) IP addresses.
 
 http://enemieslist.com/news/archives/2009/07/why_we_suspect.html
 
 it says something very close to nothing. from SA point of view, the ham/spam
 ratio is important and that is what I am curious about...
 
 There's also __RDNS_STATIC rule which excludes those static from being
 considered as dynamic. There should be one for HELO rules too - 
 It would make me angry if I got scored more just because my server is
 properly configured and uses proper helo which is the same as RDNS
 (some helo checks have higher score than RCVD_HELO_IP_MISMATCH)
 
 On 19.08.09 09:55, mouss wrote:
 if your PTR is generic, then it is better to set the HELO to a
 non-generic value. just make it resolve to the same IP. while it is
 not always possible to set a custom rdns, there is no excuse for not
 setting a meaningful HELO.
 
 I wouldn't say so. Automatic helo string is much easier to configure and
 requires less work than manual...
 

Then helo is useless. but that's not what we are about: if you are
smtp.google.com, then I don't care about your helo.  but if your PTR is
 joe-192-1-2-3.example.com, then I am not very open to accept your
transaction. if you do an effrot and helo with flower.example.net,
then I'll give you a better treatment.

said otherwise: if I reject your mail because you helo with a generic
name, don't ever try to complain. first, if you can't get a custom
rdns, it is _your_ problem. I might listen to you blaming your provider.
but if you can't set a custom helo, then I won't listen to you at all.

for the same reasons, I reject mail hosts helo-ing as localhost,
*.localdomain, *.arpa, *.firewall, *.myfirwall, ... etc. It's
more effective to get them fix their helo than ask the whole world to
accept the junk.

and this is no different than any rule in SA. I find it easier to ask an
admin to fix his helo than to tell someone that the message was tagged
because the subject is all caps and foo is bar and bar is foo.

 Yes, with current SA setting it may be true. But since we are complaining
 about this, this ain't an answer...

I block such stuff at smtp transaction. if I get junk from
joe-1-2-3-4.domain.tld, I add a rule to block this in helo check. if
helo check is not enough, the rule is applied to the PTR.

Re: HELO_DYNAMIC_IPADDR false positive

[Matus UHLAR - fantomas]

 Bob Proulx a écrit :
  The following header line:
  
   Received: from static-96-254-126-11.tampfl.fios.verizon.net 
  [96.254.126.11] by
   windows12.uvault.com with SMTP;   Wed, 12 Aug 2009 08:26:40 -0400
  
  Hits the HELO_DYNAMIC_IPADDR rule.  I tested it this way:
  
$ perl -le 'if (static-96-254-126-11.tampfl.fios.verizon.net =~ 
  /[a-z]\S*\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]\d+[^\d\s][^\.]*\.\S+\.\S+[^\]]+/) { 
  print Yes } else { print No };'
Yes
  
  But the address doesn't appear to be in a dynamic block.  And it
  doesn't look like a dynamic address pattern to me.

On 19.08.09 00:48, mouss wrote:
 The name of the rule is worng, but the result is ok. Instead of
 dynamic, I suggest: UMO for Unidentifiable Mailing Object. whether
 static-ip- is static or not doesn't matter. a lot of junk comes from
 such hosts, and we can't report/complain to a domain, since the domain
 is that of the SP (and getting SPs to block abuse sources have proven
 vain).

I'd be glad to see if there's any difference in percentage of spam from
dynamic and static (generic) IP addresses.

There's also __RDNS_STATIC rule which excludes those static from being
considered as dynamic. There should be one for HELO rules too - 
It would make me angry if I got scored more just because my server is
properly configured and uses proper helo which is the same as RDNS
(some helo checks have higher score than RCVD_HELO_IP_MISMATCH)

-- 
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.
Enter any 12-digit prime number to continue.

Re: HELO_DYNAMIC_IPADDR false positive

[mouss]

Matus UHLAR - fantomas a écrit :
 Bob Proulx a écrit :
 The following header line:

  Received: from static-96-254-126-11.tampfl.fios.verizon.net 
 [96.254.126.11] by
  windows12.uvault.com with SMTP;   Wed, 12 Aug 2009 08:26:40 -0400

 Hits the HELO_DYNAMIC_IPADDR rule.  I tested it this way:

   $ perl -le 'if (static-96-254-126-11.tampfl.fios.verizon.net =~ 
 /[a-z]\S*\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]\d+[^\d\s][^\.]*\.\S+\.\S+[^\]]+/) { 
 print Yes } else { print No };'
   Yes

 But the address doesn't appear to be in a dynamic block.  And it
 doesn't look like a dynamic address pattern to me.
 
 On 19.08.09 00:48, mouss wrote:
 The name of the rule is worng, but the result is ok. Instead of
 dynamic, I suggest: UMO for Unidentifiable Mailing Object. whether
 static-ip- is static or not doesn't matter. a lot of junk comes from
 such hosts, and we can't report/complain to a domain, since the domain
 is that of the SP (and getting SPs to block abuse sources have proven
 vain).
 
 I'd be glad to see if there's any difference in percentage of spam from
 dynamic and static (generic) IP addresses.
 


http://enemieslist.com/news/archives/2009/07/why_we_suspect.html

 There's also __RDNS_STATIC rule which excludes those static from being
 considered as dynamic. There should be one for HELO rules too - 
 It would make me angry if I got scored more just because my server is
 properly configured and uses proper helo which is the same as RDNS
 (some helo checks have higher score than RCVD_HELO_IP_MISMATCH)
 

if your PTR is generic, then it is better to set the HELO to a
non-generic value. just make it resolve to the same IP. while it is
not always possible to set a custom rdns, there is no excuse for not
setting a meaningful HELO.

Re: HELO_DYNAMIC_IPADDR false positive

[Matus UHLAR - fantomas]

  On 19.08.09 00:48, mouss wrote:
  The name of the rule is worng, but the result is ok. Instead of
  dynamic, I suggest: UMO for Unidentifiable Mailing Object. whether
  static-ip- is static or not doesn't matter. a lot of junk comes from
  such hosts, and we can't report/complain to a domain, since the domain
  is that of the SP (and getting SPs to block abuse sources have proven
  vain).

 Matus UHLAR - fantomas a écrit :
  I'd be glad to see if there's any difference in percentage of spam from
  dynamic and static (generic) IP addresses.

 http://enemieslist.com/news/archives/2009/07/why_we_suspect.html

it says something very close to nothing. from SA point of view, the ham/spam
ratio is important and that is what I am curious about...

  There's also __RDNS_STATIC rule which excludes those static from being
  considered as dynamic. There should be one for HELO rules too - 
  It would make me angry if I got scored more just because my server is
  properly configured and uses proper helo which is the same as RDNS
  (some helo checks have higher score than RCVD_HELO_IP_MISMATCH)

On 19.08.09 09:55, mouss wrote:
 if your PTR is generic, then it is better to set the HELO to a
 non-generic value. just make it resolve to the same IP. while it is
 not always possible to set a custom rdns, there is no excuse for not
 setting a meaningful HELO.

I wouldn't say so. Automatic helo string is much easier to configure and
requires less work than manual...

Yes, with current SA setting it may be true. But since we are complaining
about this, this ain't an answer...
-- 
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.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901

Re: HELO_DYNAMIC_IPADDR false positive

[Michael Scheidell]

Bob Proulx wrote:

The following header line:

 Received: from static-96-254-126-11.tampfl.fios.verizon.net
 [96.254.126.11] by
 windows12.uvault.com with SMTP;   Wed, 12 Aug 2009 08:26:40 -0400

Hits the HELO_DYNAMIC_IPADDR rule.  I tested it this way:

  $ perl -le 'if (static-96-254-126-11.tampfl.fios.verizon.net =~ 
/[a-z]\S*\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]\d+[^\d\s][^\.]*\.\S+\.\S+[^\]]+/) { print Yes } else { 
print No };'
  Yes

But the address doesn't appear to be in a dynamic block.  And it
doesn't look like a dynamic address pattern to me.

  
says 'static', but, a serious question:  is the mail server at that ip 
REALLY setup with a FQDN of


static-96-254-126-11.tampfl.fios.verizon.net


the helo_dynamic_ipaddr rule also catches 'static' ip addresses used by 
spambots that are operating on static workstation ip addresses.


if this is a client of yours, you might help them get a VALID RDNS and 
setup the FQDN for their mail server.

(more likely, its a zombie spambot anyway, )

Bob
  


_
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/

_
  

Re: HELO_DYNAMIC_IPADDR false positive

[Matus UHLAR - fantomas]

 Bob Proulx wrote:
 The following header line:

  Received: from static-96-254-126-11.tampfl.fios.verizon.net
  [96.254.126.11] by
  windows12.uvault.com with SMTP;   Wed, 12 Aug 2009 08:26:40 -0400

 Hits the HELO_DYNAMIC_IPADDR rule.  I tested it this way:

   $ perl -le 'if (static-96-254-126-11.tampfl.fios.verizon.net =~ 
 /[a-z]\S*\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]\d+[^\d\s][^\.]*\.\S+\.\S+[^\]]+/) { 
 print Yes } else { print No };'
   Yes

 But the address doesn't appear to be in a dynamic block.  And it
 doesn't look like a dynamic address pattern to me.

On 18.08.09 05:37, Michael Scheidell wrote:
 says 'static', but, a serious question:  is the mail server at that ip  
 REALLY setup with a FQDN of

 static-96-254-126-11.tampfl.fios.verizon.net

another serious question: should IPs with statically assigned IP addresses
get the same processing as if they were dynamically assigned?

I don't think so. Dynamic IP addresses are often in dynamic blacklists and
other blacklists don't have value there, since spamming clients may reconnect
and get other IP.

 the helo_dynamic_ipaddr rule also catches 'static' ip addresses used by  
 spambots that are operating on static workstation ip addresses.

 if this is a client of yours, you might help them get a VALID RDNS and  
 setup the FQDN for their mail server.
 (more likely, its a zombie spambot anyway, )

Of course it's much better to have personalised DNS name than generic one,
but *DYNAMIC* should still not match, becausse the ip is just not dynamic.

-- 
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.
10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!

Re: HELO_DYNAMIC_IPADDR false positive

[Per Jessen]

Matus UHLAR - fantomas wrote:

 another serious question: should IPs with statically assigned IP
 addresses get the same processing as if they were dynamically
 assigned?

Probably not, but there's no guaranteed way of telling them apart. 

 Of course it's much better to have personalised DNS name than generic
 one, but *DYNAMIC* should still not match, becausse the ip is just not
 dynamic.

How do you know that?


/Per Jessen, Zürich

Re: HELO_DYNAMIC_IPADDR false positive

[Matus UHLAR - fantomas]

 Matus UHLAR - fantomas wrote:
  another serious question: should IPs with statically assigned IP
  addresses get the same processing as if they were dynamically
  assigned?

On 18.08.09 16:51, Per Jessen wrote:
 Probably not, but there's no guaranteed way of telling them apart. 

there is - if they contain word 'static' or at least 'sta', they are,
surprise, static...

  Of course it's much better to have personalised DNS name than generic
  one, but *DYNAMIC* should still not match, becausse the ip is just not
  dynamic.

 How do you know that?

know what? that a static IP is static? That's from definition. I know ISPs
who use this static naming scheme. And if an ISP lies (I can't imagine other
reason than being completely idiot), well, all their IPs will get blocked,
thgey will get flooded by reports etc.


-- 
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.
The box said 'Requires Windows 95 or better', so I bought a Macintosh.

Re: HELO_DYNAMIC_IPADDR false positive

[RW]

On Tue, 18 Aug 2009 16:51:46 +0200
Per Jessen p...@computer.org wrote:

 Matus UHLAR - fantomas wrote:
 
  another serious question: should IPs with statically assigned IP
  addresses get the same processing as if they were dynamically
  assigned?
 
 Probably not, but there's no guaranteed way of telling them apart. 
 
  Of course it's much better to have personalised DNS name than
  generic one, but *DYNAMIC* should still not match, becausse the ip
  is just not dynamic.
 
 How do you know that?

Presumably because the reverse DNS contains STATIC

The SORBS DUL listing criteria contains this line:

Generic reverse DNS naming is the most important criterion for
determining if an address range should be considered dynamically
assigned.

I think that makes sense, there are plenty of ordinary domestic
Windows boxes running on static addresses - it means practically
nothing. 

Re: HELO_DYNAMIC_IPADDR false positive

[mouss]

Bob Proulx a écrit :
 The following header line:
 
  Received: from static-96-254-126-11.tampfl.fios.verizon.net [96.254.126.11] 
 by
  windows12.uvault.com with SMTP;   Wed, 12 Aug 2009 08:26:40 -0400
 
 Hits the HELO_DYNAMIC_IPADDR rule.  I tested it this way:
 
   $ perl -le 'if (static-96-254-126-11.tampfl.fios.verizon.net =~ 
 /[a-z]\S*\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]\d+[^\d\s][^\.]*\.\S+\.\S+[^\]]+/) { 
 print Yes } else { print No };'
   Yes
 
 But the address doesn't appear to be in a dynamic block.  And it
 doesn't look like a dynamic address pattern to me.
 
 Bob

The name of the rule is worng, but the result is ok. Instead of
dynamic, I suggest: UMO for Unidentifiable Mailing Object. whether
static-ip- is static or not doesn't matter. a lot of junk comes from
such hosts, and we can't report/complain to a domain, since the domain
is that of the SP (and getting SPs to block abuse sources have proven
vain).

Re: HELO_DYNAMIC_IPADDR false positive

[Bob Proulx]

Michael Scheidell wrote:
 if this is a client of yours, you might help them get a VALID RDNS and  
 setup the FQDN for their mail server.
 (more likely, its a zombie spambot anyway, )

Not related to me in any way.  The mail message generated from there
was legitimate.  It came *to* a client of mine but one I have little
control over either.  It came from a human to another human and was
caught as a false positive and that is all that I know about it.

Bob

Re: [SA] False positive?

[Adam Katz]

Karsten Bräckelmann wrote:
 According to the W3C validator [1], the head/ in itself is invalid,
 and not finished. And the root element is missing a mandatory xmlns
 attribute. Also, according to the compatibility guidelines [2], empty
 elements should have a space before the closing slash. To name but a few
 I found by some brief digging.

More specifically, head/ is disallowed because the [X]HTML spec
requires head sections to include title, so the briefest you can
get is headtitle//head

The space is optional but recommended as a best-practice, especially
for non-XML HTML4 compatibility (the top of Guenther's link #2 reads:
This appendix summarizes design guidelines for authors who wish their
XHTML documents to render on existing HTML user agents).

-khopesh

-- 
Adam Katz
http://khopesh.com/Anti-spam

Re: vbounce false positive on CommuniGate group message

[JP Kelly]

Pardon my ignorance, but can someone explain how to implement the fix  
for this?

JP Kelly

On May 2, 2008, at 9:37 AM, Jesse Stroik wrote:


Stefan,

Fantastic.  This works.  Thanks for pointing me in the right  
direction.


Best,
Jesse

Stefan Jakobs wrote:

On Friday 02 May 2008 17:24, Jesse Stroik wrote:

SA-Users,

I'm running spamassassin rules 648641 for 3.2.4 fetched by sa- 
update.
I've run into two issues with my current setup.  First, group  
messages

sent through my MTA (CommuniGate) are getting classified with
BOUNCE_MESSAGE by vbounce.  Below is one such message.

Secondly, even if the message is sent using our MTA, it is not
whitelisted properly by whitelist_bounce_relays.  My
whitelist_bounce_relays include both my domain as well as the A and
CNAME records.  A second message is also included below.

Can anyone shed some light on why the messages destined for groups  
are
being flagged as bounces and how I can fix the  
whitelist_bounce_relays

issue?  Email addresses have been stripped from the headers of each
message.

I'm not sure, but it looks like a already reported bug.
See: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5884

Best,
Jesse Stroik

Greetings
Stefan
snip

Re: vbounce false positive on CommuniGate group message

[JP Kelly]

nevermind.
i replaced the subroutine in VBounce.pm with the modified one on
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5884
hopefully this will work.
thanks.
jp

On May 5, 2008, at 12:52 PM, JP Kelly wrote:

Pardon my ignorance, but can someone explain how to implement the  
fix for this?

JP Kelly

On May 2, 2008, at 9:37 AM, Jesse Stroik wrote:


Stefan,

Fantastic.  This works.  Thanks for pointing me in the right  
direction.


Best,
Jesse

Stefan Jakobs wrote:

On Friday 02 May 2008 17:24, Jesse Stroik wrote:

SA-Users,

I'm running spamassassin rules 648641 for 3.2.4 fetched by sa- 
update.
I've run into two issues with my current setup.  First, group  
messages

sent through my MTA (CommuniGate) are getting classified with
BOUNCE_MESSAGE by vbounce.  Below is one such message.

Secondly, even if the message is sent using our MTA, it is not
whitelisted properly by whitelist_bounce_relays.  My
whitelist_bounce_relays include both my domain as well as the A and
CNAME records.  A second message is also included below.

Can anyone shed some light on why the messages destined for  
groups are
being flagged as bounces and how I can fix the  
whitelist_bounce_relays

issue?  Email addresses have been stripped from the headers of each
message.

I'm not sure, but it looks like a already reported bug.
See: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5884

Best,
Jesse Stroik

Greetings
Stefan
snip

Re: vbounce false positive on CommuniGate group message

[Stefan Jakobs]

On Friday 02 May 2008 17:24, Jesse Stroik wrote:
 SA-Users,

 I'm running spamassassin rules 648641 for 3.2.4 fetched by sa-update.
 I've run into two issues with my current setup.  First, group messages
 sent through my MTA (CommuniGate) are getting classified with
 BOUNCE_MESSAGE by vbounce.  Below is one such message.

 Secondly, even if the message is sent using our MTA, it is not
 whitelisted properly by whitelist_bounce_relays.  My
 whitelist_bounce_relays include both my domain as well as the A and
 CNAME records.  A second message is also included below.

 Can anyone shed some light on why the messages destined for groups are
 being flagged as bounces and how I can fix the whitelist_bounce_relays
 issue?  Email addresses have been stripped from the headers of each
 message.

I'm not sure, but it looks like a already reported bug.
See: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5884

 Best,
 Jesse Stroik

Greetings
Stefan

snip


pgp03MLvc6oIv.pgp
Description: PGP signature

Re: vbounce false positive on CommuniGate group message

[Jesse Stroik]

Stefan,

Fantastic.  This works.  Thanks for pointing me in the right direction.

Best,
Jesse

Stefan Jakobs wrote:

On Friday 02 May 2008 17:24, Jesse Stroik wrote:

SA-Users,

I'm running spamassassin rules 648641 for 3.2.4 fetched by sa-update.
I've run into two issues with my current setup.  First, group messages
sent through my MTA (CommuniGate) are getting classified with
BOUNCE_MESSAGE by vbounce.  Below is one such message.

Secondly, even if the message is sent using our MTA, it is not
whitelisted properly by whitelist_bounce_relays.  My
whitelist_bounce_relays include both my domain as well as the A and
CNAME records.  A second message is also included below.

Can anyone shed some light on why the messages destined for groups are
being flagged as bounces and how I can fix the whitelist_bounce_relays
issue?  Email addresses have been stripped from the headers of each
message.


I'm not sure, but it looks like a already reported bug.
See: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5884


Best,
Jesse Stroik


Greetings
Stefan

snip

RE: Possible false positive?

[Aydin SASMAZ]

I mean that there is no such a rule like Fw_mail in those files and I also
not using local_pref

If this Fw_mail Rule is not an native rule and I am sure that I didn't add
this, where it is possible to come from?


Thanks





Hasan Aydın ŞAŞMAZ

Genel Müdür Yardımcısı

BTEĞİTİM

Tel : 0212 274 6998

Fax: 0212 267 4725

-Original Message-
From: Rich Shepard [mailto:[EMAIL PROTECTED] 
Sent: 26 Ocak 2007 Cuma 16:05
To: Aydin SASMAZ
Subject: RE: Possible false positive?

On Fri, 26 Jan 2007, Aydin SASMAZ wrote:

 Actually I didn't defined that rule, it poped up, there was not any
 problem days ago..I've looked up at
 /etc/MailScanner/spam.assassin.prefs.conf or there is no
 .spamassassin/local_pref file also. Can't find

   'locate spam.assassin.prefs.conf'
   'locate local_pref'

-- 
Richard B. Shepard, Ph.D.   |The Environmental Permitting
Applied Ecosystem Services, Inc.|  Accelerator(TM)
http://www.appl-ecosys.com Voice: 503-667-4517  Fax: 503-667-8863

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Possible false positive?

[Theo Van Dinter]

On Fri, Jan 26, 2007 at 02:32:11AM +0200, Aydin SASMAZ wrote:
 adds a test score Fw_mail 100.00 but I got the email because my email
[...]
 What is the real cause of this and how prevent spamassassin adding this
 Fw_mail 100 score any forwarded email

Fw_mail is not a standard rule included with SpamAssassin.  You'll want to
find where you define this rule in your configs and disable it.

-- 
Randomly Selected Tagline:
If a can of Alpo costs 38 cents, would it cost $2.50 in Dog Dollars?


pgpU4FOU80TTZ.pgp
Description: PGP signature

RE: Possible false positive?

[Aydin SASMAZ]

Actually I didn't defined that rule, it poped up, there was not any problem
days ago..I've looked up at /etc/MailScanner/spam.assassin.prefs.conf or
there is no .spamassassin/local_pref file also. Can't find

How can I find where it is...

thanks






Hasan Aydın ŞAŞMAZ

Genel Müdür Yardımcısı

BTEĞİTİM

Tel : 0212 274 6998

Fax: 0212 267 4725


-Original Message-
From: Theo Van Dinter [mailto:[EMAIL PROTECTED] 
Sent: 26 Ocak 2007 Cuma 03:02
To: users@spamassassin.apache.org
Subject: Re: Possible false positive?

On Fri, Jan 26, 2007 at 02:32:11AM +0200, Aydin SASMAZ wrote:
 adds a test score Fw_mail 100.00 but I got the email because my email
[...]
 What is the real cause of this and how prevent spamassassin adding this
 Fw_mail 100 score any forwarded email

Fw_mail is not a standard rule included with SpamAssassin.  You'll want to
find where you define this rule in your configs and disable it.

-- 
Randomly Selected Tagline:
If a can of Alpo costs 38 cents, would it cost $2.50 in Dog Dollars?



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: A false positive...

[Craig Morrison]

Justin Mason wrote:

Steve [Spamassasin] writes:

An ebay watched item email has been wrongly tagged as spam... with the
following rules:

--
 2.2 INVALID_DATE   Invalid Date: header (not RFC 2822)
 0.8 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date
 0.1 TW_SJ  BODY: Odd Letter Triples with SJ
 0.0 HTML_MESSAGE   BODY: HTML included in message
 3.0 BAYES_95   BODY: Bayesian spam probability is 95 to 99%
[score: 0.9887]
 0.2 HTML_TITLE_EMPTY   BODY: HTML title contains no text
-0.0 SARE_LEGIT_EBAYHas signs it's from ebay, from, headers, uri
-1.1 AWLAWL: From: address is in the auto white-list
--


The (sanitised) headers read:


--
Subject:...
From:eBay [EMAIL PROTECTED]
Date:Wed, 22 Nov 2006 09:03:16 GMT-07:00

While I understand why this email may have triggered the Bayesian rule (where 
spammers have copied ebay's email style...) I am bemused by INVALID_DATE and 
DATE_IN_PAST_06_12.

The dates I see in the header look valid to me - and (if we allow for time 
international time differences) the message was sent two seconds before it was 
received.

Am I overlooking something here?  Why doesn't SpamAssassin like these dates?


they're malformed, missing spaces.  this is what an RFC-compliant
date looks like:

  Date: Wed, 22 Nov 2006 16:20:29 +

this is what the ebay.co.uk date looks like, according to yr mail:

  Date:Wed, 22 Nov 2006 09:03:16 GMT-07:00

note: missing spaces; extra : in the TZ offset; and the TZ name.  all
are non-rfc-compliant.

--j.



Technically the only thing wrong with the date is the TZ. Section 2.2 of 
RFC2822 states:


   Header fields are lines composed of a field name, followed by a colon
   (:), followed by a field body, and terminated by CRLF.

No reference to a mandatory SP character starting the field body.

To the OP, since I highly doubt that you will get eBay to change their 
TZ format you should consider sa-learn'ing the messages as ham. On your 
SA setup these messages are hitting BAYES_95 which is adding 3 points to 
their score.


--
Craig

RE: A false positive...

[Michael Scheidell]

 -Original Message-
 From: Craig Morrison [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, November 23, 2006 12:53 PM
 To: users@spamassassin.apache.org
 Subject: Re: A false positive...
 TZ format you should consider sa-learn'ing the messages as 
 ham. On your 
 SA setup these messages are hitting BAYES_95 which is adding 
 3 points to 
 their score.

I odn't think learning one message as spam will drop the _95 rating.

Hoever, maybe this will help (put in local.cf)

score SARE_LEGIT_EBAY  -3.5


 
 -- 
 Craig
 
 

Re: A false positive...

[Craig Morrison]

Michael Scheidell wrote:

-Original Message-
From: Craig Morrison [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 23, 2006 12:53 PM

To: users@spamassassin.apache.org
Subject: Re: A false positive...
TZ format you should consider sa-learn'ing the messages as 
ham. On your 
SA setup these messages are hitting BAYES_95 which is adding 
3 points to 
their score.


I odn't think learning one message as spam will drop the _95 rating.

Hoever, maybe this will help (put in local.cf)

score SARE_LEGIT_EBAY  -3.5




If learning them as ham doesn't affect the score then what is the point 
of the learning system at all?


What am I missing?

--
Craig

RE: A false positive...

[Michael Scheidell]

 -Original Message-
 From: Craig Morrison [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, November 23, 2006 2:45 PM
 To: users@spamassassin.apache.org
 Subject: Re: A false positive...
 
 If learning them as ham doesn't affect the score then what is 
 the point 
 of the learning system at all?
 
 What am I missing?

The fact that ONE email won't affect it one way or the other.

Its based on statistics and probability factors.

That's why you need at least 200 hams and 200 spams for the system to
even kick in.

That's why the spammers trying to poison the system doesn't work as
quickly as they would like.

Want math?
http://www.ddj.com/dept/architect/184406064

Re: A false positive...

[Theo Van Dinter]

On Wed, Nov 22, 2006 at 04:20:29PM +, Steve [Spamassasin] wrote:
 Date:Wed, 22 Nov 2006 09:03:16 GMT-07:00
 
 Am I overlooking something here?  Why doesn't SpamAssassin like these dates?

That's not a valid date header, the TZ is invalid.

-- 
Randomly Selected Tagline:
... and we still have yet to create a neural computer with the
 sophistication of a garden slug ... - Prof. Michaelson


pgpfyJ0bRcp9D.pgp
Description: PGP signature

RE: A false positive...

[Giampaolo Tomassoni]

From: Steve [Spamassasin] [mailto:[EMAIL PROTECTED]
 Date:Wed, 22 Nov 2006 09:03:16 GMT-07:00

Should be -0700 not GMT-07:00.

This may also trigger the DATE_IN_PAST_06_12, since probably the SA's date 
parsing module simply discards the zone offset data.

giampaolo

 To:...
 Return-Path:[EMAIL PROTECTED]
 X-Original-To:...
 Delivered-To:...
 Received:from mx9.smf.ebay.com (mxsmfpool05.ebay.com 
 [66.135.209.202]) by ... (Postfix) with ESMTP id 06C81D8C24 for 
 ...; Wed, 22 Nov 2006 16:04:00 + (GMT)
 Received:from sjc2bat08.sjc.ebay.com (sjc2bat08.sjc.ebay.com 
 [10.11.37.18]) by mx9.smf.ebay.com (8.13.5/8.13.5) with ESMTP id 
 kAMG3oaM009188 for ...; Wed, 22 Nov 2006 09:03:58 -0700
 X-eBay-MailTracker:10089.487.3.0
 MIME-Version:1.0
 Content-Type:multipart/alternative; 
 boundary=7101714.1164211396002.JavaMail.ebba.sjc2bat08
 Message-ID:[EMAIL PROTECTED]
 --
 
 While I understand why this email may have triggered the Bayesian 
 rule (where spammers have copied ebay's email style...) I am 
 bemused by INVALID_DATE and DATE_IN_PAST_06_12.
 
 The dates I see in the header look valid to me - and (if we allow 
 for time international time differences) the message was sent two 
 seconds before it was received.
 
 Am I overlooking something here?  Why doesn't SpamAssassin like 
 these dates?
 
 Steve
 
 

Re: A false positive...

[Tony Finch]

On Wed, 22 Nov 2006, Steve [Spamassasin] wrote:

  2.2 INVALID_DATE   Invalid Date: header (not RFC 2822)
  0.8 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date

 Date:Wed, 22 Nov 2006 09:03:16 GMT-07:00
 Received:from sjc2bat08.sjc.ebay.com (sjc2bat08.sjc.ebay.com [10.11.37.18]) 
 by mx9.smf.ebay.com (8.13.5/8.13.5) with ESMTP id kAMG3oaM009188 for ...; 
 Wed, 22 Nov 2006 09:03:58 -0700

 The dates I see in the header look valid to me - and (if we allow for
 time international time differences) the message was sent two seconds
 before it was received.

The Date: header above is malformed, so SpamAssassin can't extract the
timezone offset.

Tony.
-- 
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
BAILEY: CYCLONIC BECOMING NORTHWESTERLY SEVERE GALE 9 TO VIOLENT STORM 11,
OCCASIONALLY HURRICANE FORCE 12 IN SOUTH, DECREASING 7 TO SEVERE GALE 9 LATER.
HIGH OR VERY HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR.

Re: A false positive...

[Justin Mason]

Steve [Spamassasin] writes:
 An ebay watched item email has been wrongly tagged as spam... with the
 following rules:
 
 --
  2.2 INVALID_DATE   Invalid Date: header (not RFC 2822)
  0.8 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date
  0.1 TW_SJ  BODY: Odd Letter Triples with SJ
  0.0 HTML_MESSAGE   BODY: HTML included in message
  3.0 BAYES_95   BODY: Bayesian spam probability is 95 to 99%
 [score: 0.9887]
  0.2 HTML_TITLE_EMPTY   BODY: HTML title contains no text
 -0.0 SARE_LEGIT_EBAYHas signs it's from ebay, from, headers, uri
 -1.1 AWLAWL: From: address is in the auto white-list
 --
 
 
 The (sanitised) headers read:
 
 
 --
 Subject:...
 From:eBay [EMAIL PROTECTED]
 Date:Wed, 22 Nov 2006 09:03:16 GMT-07:00
 
 While I understand why this email may have triggered the Bayesian rule (where 
 spammers have copied ebay's email style...) I am bemused by INVALID_DATE and 
 DATE_IN_PAST_06_12.
 
 The dates I see in the header look valid to me - and (if we allow for time 
 international time differences) the message was sent two seconds before it 
 was received.
 
 Am I overlooking something here?  Why doesn't SpamAssassin like these dates?

they're malformed, missing spaces.  this is what an RFC-compliant
date looks like:

  Date: Wed, 22 Nov 2006 16:20:29 +

this is what the ebay.co.uk date looks like, according to yr mail:

  Date:Wed, 22 Nov 2006 09:03:16 GMT-07:00

note: missing spaces; extra : in the TZ offset; and the TZ name.  all
are non-rfc-compliant.

--j.

Re: hotmail false positive on new 'live mail' service

[Alex Bramley]

Igor Ybema wrote:

Dear users,

I recently discovered soms false positives from hotmail users. This
seems to originate from users which already are converted to there new
'live' website (instead of the old hotmail look).

What I see in the headers is that they changed there HELO:

Received: from BAY115-W3 ([65.54.250.103]) by
bay0-omc3-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830);
 Tue, 17 Oct 2006 06:13:03 -0700

There is no 'hotmail.com' anymore in the HELO message. This way it gets
the tag 'FORGED_HOTMAIL_RCVD'. Did more people already discover this?
And is there already a solution?


I've noticed this problem a couple of times too. It looks like the tests 
in the _check_for_forged_hotmail_received_headers subroutine in 
Mail::SpamAssassin::EvalTests need to be updated to recognise this as valid.


Here are a couple more examples:

Received: from BAY101-W6 ([64.4.56.106]) by 
bay0-omc3-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830);

 Tue, 24 Oct 2006 07:39:10 -0700

Received: from BAY101-W9 ([64.4.56.109]) by 
bay0-omc3-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830);

 Wed, 25 Oct 2006 06:11:34 -0700

Cheers,
Alex

Re: URIBL False positive

[Jeff Chan]

On Tuesday, December 6, 2005, 1:26:32 PM, Brian Leyton wrote:
 I'm relatively new to SpamAssassin, but I've managed to get it working well
 in conjunction with MimeDefang.  I'm having a strange problem though, which
 I hope someone can help me figure out.

 I'm on a hobby mailing list, and occasionally emails to this list are being
 tagged as spam by SpamAssassin, based on the website mentioned in the emails
 being on multiple URIBL lists.  Strangely though, when I go to the SURBL
 checker at rulesemporium.com, the site is NOT shown as being listed on any
 of these lists.

 Bayes correctly considers these emails to NOT be spam, but the 4 URIBL
 positives are enough to put the score over the top.

What version of SpamAssassin are you using?  There is a bug in
3.0.x that can cause intermittent errors like this.

Jeff C.
-- 
Jeff Chan
mailto:[EMAIL PROTECTED]
http://www.surbl.org/

RE: URIBL False positive

[Brian Leyton]

Jeff Chan wrote:

 What version of SpamAssassin are you using?  There is a bug 
 in 3.0.x that can cause intermittent errors like this.

Spamassassin -V reports:

SpamAssassin version 3.0.4
  running on Perl version 5.8.6

Brian Leyton
IT Manager
Commercial Petroleum Equipment

Re: URIBL False positive

[Jeff Chan]

On Wednesday, December 7, 2005, 8:14:43 AM, Brian Leyton wrote:
 Jeff Chan wrote:

 What version of SpamAssassin are you using?  There is a bug 
 in 3.0.x that can cause intermittent errors like this.

 Spamassassin -V reports:

 SpamAssassin version 3.0.4
   running on Perl version 5.8.6

 Brian Leyton
 IT Manager
 Commercial Petroleum Equipment

OK I can't remember if that one has the bug fix or not.  3.1
definitely does.

What was the specific FP domain?

Jeff C.
-- 
Jeff Chan
mailto:[EMAIL PROTECTED]
http://www.surbl.org/

RE: URIBL False positive

[Brian Leyton]

Jeff Chan wrote:
 
 OK I can't remember if that one has the bug fix or not.  3.1 
 definitely does.
 
 What was the specific FP domain?

Here's the scoring section of the SA report:

Content analysis details:   (5.5 points, 5.0 required)

 pts rule name  description
 --
--
-2.6 BAYES_00   BODY: Bayesian spam probability is 0 to 1%
[score: 0.]
 2.0 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist
[URIs: americanbroadcastdx.com]
 0.4 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
[URIs: americanbroadcastdx.com]
 1.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
[URIs: americanbroadcastdx.com]
 4.3 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
[URIs: americanbroadcastdx.com]

Brian Leyton
IT Manager
Commercial Petroleum Equipment

Re: URIBL False positive

[Jeff Chan]

On Wednesday, December 7, 2005, 8:31:06 AM, Brian Leyton wrote:
 Jeff Chan wrote:
 
 OK I can't remember if that one has the bug fix or not.  3.1 
 definitely does.
 
 What was the specific FP domain?

 Here's the scoring section of the SA report:

 Content analysis details:   (5.5 points, 5.0 required)

  pts rule name  description
  --
 --
 -2.6 BAYES_00   BODY: Bayesian spam probability is 0 to 1%
 [score: 0.]
  2.0 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist
 [URIs: americanbroadcastdx.com]
  0.4 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
 [URIs: americanbroadcastdx.com]
  1.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
 [URIs: americanbroadcastdx.com]
  4.3 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
 [URIs: americanbroadcastdx.com]

 Brian Leyton
 IT Manager
 Commercial Petroleum Equipment

Thanks.  americanbroadcastdx.com was never on any SURBLs, so it's
probably the bug.  Please consider upgrading to 3.1 or possibly
even 3.0.5 as this may fix the bug:

  http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3997

The developers will know for sure about which versions the patch
is in.  Or you could perhaps apply the patch manually to 3.0.4.
They would know that too.

It may be worth asking if you have any unusual DNS arrangement
such as proxying firewalls, etc.

Jeff C.
-- 
Jeff Chan
mailto:[EMAIL PROTECTED]
http://www.surbl.org/

RE: URIBL False positive

[Brian Leyton]

Jeff Chan wrote:  
 Thanks.  americanbroadcastdx.com was never on any SURBLs, so 
 it's probably the bug.  Please consider upgrading to 3.1 or 
 possibly even 3.0.5 as this may fix the bug:
 
   http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3997
 
 The developers will know for sure about which versions the 
 patch is in.  Or you could perhaps apply the patch manually to 3.0.4.
 They would know that too.
 
 It may be worth asking if you have any unusual DNS 
 arrangement such as proxying firewalls, etc.

Nothing unusual there.  It uses the firewall (IPCop) as a caching DNS
server, and the ISP's DNS as a fallback (not that that would help if the
firewall were down).

I'll see what I need to do to update.  I think I used yum to install it in
the first place, but something's hosed in the package dependencies.  I'll
get to work on that  see if I can get a newer spamassassin installed.

Thanks for your help!

Brian Leyton
IT Manager
Commercial Petroleum Equipment

Re: URIBL False positive

[Matt Kettler]

Brian Leyton wrote:
 I'm relatively new to SpamAssassin, but I've managed to get it working well
 in conjunction with MimeDefang.  I'm having a strange problem though, which
 I hope someone can help me figure out.
 
 I'm on a hobby mailing list, and occasionally emails to this list are being
 tagged as spam by SpamAssassin, based on the website mentioned in the emails
 being on multiple URIBL lists.  Strangely though, when I go to the SURBL
 checker at rulesemporium.com, the site is NOT shown as being listed on any
 of these lists.

Are you sure you are checking the right domain at the surbl website? There could
be many domains checked, did you check them all?

Have you tried pumping the message through the command-line SA?


 
 Bayes correctly considers these emails to NOT be spam, but the 4 URIBL
 positives are enough to put the score over the top.
 
 I have included this domain in the whitelist in sa-mimedefang.cf, but that
 doesn't help.

How, exactly, did you do this? whitelist_from? whitelist_from_rcvd? Either of
those, if set properly, should cause a -100 point bias to the message, clearly
way beyond the reach of URIBL FPs.

That suggests to me you used something else, or it's not working due using the
wrong second parameter on a whitelist_from_rcvd.


 
 What might cause these lookups to return false positives?

It could be a short-term listing that got pulled from SURBL shortly after being
added. However, if it's persistent, that's unlikely.

Re: DATE_IN_FUTURE false positive

[Kai Schaetzl]

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

Re: FORGED_YAHOO_RCVD false positive

[Matt Kettler]

At 04:09 AM 6/15/2005, Monty Ree wrote:

Hello, all.

I have an account at yahoo.com and sent a mail to SA 3.0.x server at 
mail.yahoo.com site.
But I have found that this legel mail was spam tagging and my header says 
that it was FORGED_YAHOO_RCVD violation.


Anyone who uses mail.yahoo.com? please test this..



Yes, there are FP cases for this rule in SA 3.0.x. It's apparently been 
fixed in the development versions of 3.1.0, but that's not yet released.


http://bugzilla.spamassassin.org/show_bug.cgi?id=4264

Re: FORGED_YAHOO_RCVD false positive

[Stuart Johnston]

Monty Ree wrote:
 Hello, all.
 
 I have an account at yahoo.com and sent a mail to SA 3.0.x server at 
 mail.yahoo.com site.
 But I have found that this legel mail was spam tagging and my header 
 says that it was FORGED_YAHOO_RCVD violation.
 
 Anyone who uses mail.yahoo.com? please test this..

This seems to have been fixed in 3.0.4.

Re: FORGED_YAHOO_RCVD false positive

[jdow]

My - that diff for the fix is useful - no context at all for it.
{+_+}
- Original Message - 
From: Matt Kettler [EMAIL PROTECTED]


 At 04:09 AM 6/15/2005, Monty Ree wrote:
 Hello, all.
 
 I have an account at yahoo.com and sent a mail to SA 3.0.x server at
 mail.yahoo.com site.
 But I have found that this legel mail was spam tagging and my header says
 that it was FORGED_YAHOO_RCVD violation.
 
 Anyone who uses mail.yahoo.com? please test this..


 Yes, there are FP cases for this rule in SA 3.0.x. It's apparently been
 fixed in the development versions of 3.1.0, but that's not yet released.

 http://bugzilla.spamassassin.org/show_bug.cgi?id=4264

Re: FORGED_YAHOO_RCVD false positive

[jdow]

It also seems the diff listed is the wrong direction:
502d501  if ($rcvd =~ /by web\S+\.mail\.mud\.yahoo\.com via HTTP/) { return
0; }

That line does not exist to be removed.
{^_^}
- Original Message - 
From: Matt Kettler [EMAIL PROTECTED]
To: Monty Ree [EMAIL PROTECTED]; users@spamassassin.apache.org
Sent: 2005 June, 15, Wednesday 07:50
Subject: Re: FORGED_YAHOO_RCVD false positive


 At 04:09 AM 6/15/2005, Monty Ree wrote:
 Hello, all.
 
 I have an account at yahoo.com and sent a mail to SA 3.0.x server at
 mail.yahoo.com site.
 But I have found that this legel mail was spam tagging and my header says
 that it was FORGED_YAHOO_RCVD violation.
 
 Anyone who uses mail.yahoo.com? please test this..


 Yes, there are FP cases for this rule in SA 3.0.x. It's apparently been
 fixed in the development versions of 3.1.0, but that's not yet released.

 http://bugzilla.spamassassin.org/show_bug.cgi?id=4264

Re: FORGED_YAHOO_RCVD false positive

[Matt Kettler]

jdow wrote:
 It also seems the diff listed is the wrong direction:
 502d501  if ($rcvd =~ /by web\S+\.mail\.mud\.yahoo\.com via HTTP/) { return
 0; }
 
 That line does not exist to be removed.

Looking at the code it is already implemented in 3.0.4, so if you're diffing
against that, well, you're already fixed.


Here's a more proper comparison:

$ diff Mail-SpamAssassin-3.0.3/lib/Mail/SpamAssassin/EvalTests.pm
Mail-SpamAssassin-3.0.4/lib/Mail/SpamAssassin/EvalTests.pm
501c501
   if ($rcvd =~ /by web\S+\.mail\.yahoo\.com via HTTP/) { return 0; }
---
   if ($rcvd =~ /by web\S+\.mail\S*\.yahoo\.com via HTTP/) { return 0; }

And that's the only diff in the file.

Re: Spamassasin false positive review

[Bob McClure Jr]

On Mon, Apr 04, 2005 at 03:45:59PM -0400, Edward Diener wrote:
 I am a client who was able to configure my .procmailrc on a server to place
 spam messages in a file in my $HOME area. Going through this file I noticed
 a message that was not spam. I know I can whitelist this address, but what I
 really need to do immediately is recover the entire message. In the file I
 see part of the message with the actual message supposedly as an attachment.
 How do I find this actual message so that I can read it ?
 
 Eddie

Just click on the attachment and read it.  SA creates a new email with
description, score listing, and then attaches the original message.

Cheers,
-- 
Bob McClure, Jr. Bobcat Open Systems, Inc.
[EMAIL PROTECTED]  http://www.bobcatos.com
Everyone wants to harvest, but few want to plow.

Re: Spamassasin false positive review

[jdow]

From: Edward Diener [EMAIL PROTECTED]

 I am a client who was able to configure my .procmailrc on a server to
place
 spam messages in a file in my $HOME area. Going through this file I
noticed
 a message that was not spam. I know I can whitelist this address, but what
I
 really need to do immediately is recover the entire message. In the file I
 see part of the message with the actual message supposedly as an
attachment.
 How do I find this actual message so that I can read it ?

 Eddie

What you have to do is highly dependant on the email program you are using.
It is utterly unclear how to handle this with your apparent setup. It is
basically up to you to figure out how.

With Outlook Express, as an example, all you need to do is grab the
included original message and drag it into your in box somewhere. Then
you can read it normally. If you are using a web mail host then you'll
probably have to download the attachment and read it in an editor.

{^_^}

Re[2]: False positive in 70_sare_header0

[Robert Menschel]

Hello Christoph,

Saturday, January 15, 2005, 7:08:44 AM, you wrote:

 Can you forward me a few complete emails with headers, non-spam, that
 demonstrate this?

CMT (My contribution to The Corpus was sent off-list).

Received and applied to the corpus.  Thanks.


 SARE rules are built from our experience, and scored according to the
 emails in our corpora, and none of us had any non-spam with that
 characteristic. If you can send us some for inclusion in my corpus,
 that will give us the evidence we need to handle this correctly.

CMT Scrolling through header0, I noticed some other domains which could
CMT belong to ISPs. Of course they just might have a lot of spam bots
CMT on ther customers' computers, as almost every ISP has now.
CMT Would some investigations on the true origin of these domains 
CMT help improving the rules or is there just too much spam and nearly
CMT no other mail coming from these ISPs (most of them located in south
CMT america)?

At the very least, that investigation can be documented in #note
lines, which will help us know what to do if/when we eventually have a
non-spam from such domains. So that would be good.

I've been concerned about the domains that are ISPs but that generate
nothing but spam as far as we can tell.  An example would be
virtua.com.br, as applied in the SARE_RECV_VIRTUACOMBR rule.

I'm thinking that perhaps these should be converted to meta rules,
something along the lines of
header __SARE_RECV_VIRTUACOMBR Received...
meta   SARE_RECV_VIRTUACOMBR  __SARE_RECV_VIRTUACOMBR  ! ISP_SPAM_OK_BR
where ISP_SPAM_OK_BR is normally not defined, and therefore (under SA
3.0) the meta will test strictly on __SARE_RECV_VIRTUACOMBR.

Someone who wants to turn off all *.br spam rules would then simply
define
meta   ISP_SPAM_OK_BR  1
or something like that.

Comments?

Bob Menschel