date:20140917

[Bug 6782] [REVIEW] TLD update handling / RegistrarBoundaries need improving

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6782

--- Comment #7 from Henrik Krohns  ---
Feel free to describe what you had in mind? Since Util-stuff do not have access
by design to any configuration or state data, I have a hard time imagining how
this would effectively work..

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 6782] [REVIEW] TLD update handling / RegistrarBoundaries need improving

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6782

Kevin A. McGrail  changed:

   What|Removed |Added

 CC||kmcgr...@pccc.com

--- Comment #6 from Kevin A. McGrail  ---
I was working on this as well and my thoughts were to deliver the data to then
process using new dependencies limiting the changes to RegistrarBoundaries.pm. 
I need to look but your change seems far more intrusive.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Rule priority

2014-09-17 Thread Kevin A. McGrail


On 9/17/2014 7:05 PM, Philip Prindeville wrote:

I guess it’s not a hot topic.

Or else it’s not well understood.
I think it's the later.  The short circuit plugin is likely not that 
much used so perhaps document the issue in the plugin as a needed 
enhancement and update the bug.


Beyond that, i encourage you to implement it AND document the priority 
as best you can while you do it to help others behind us.


Best,

KAM



On Sep 10, 2014, at 12:42 PM, Kevin A. McGrail > wrote:


Can someone give him some guidance please?  I'd like to support him 
improving the plugin and I'm a bit busy with the RC for 3.4.1 and the 
SA report.



 Forwarded Message 
Subject:Rule priority
Date:   Wed, 10 Sep 2014 11:06:01 -0600
From:   Philip Prindeville 
To: SpamAssassin 



Is there a good discussion on how rule priority works, and short-circuited 
evaluation, etc?

I must be looking in the wrong places because I can’t find much.  I found 
register_method_priority() in ::Plugin but I wasn’t sure if that’s all there 
is… It only seems to be called in Plugin::Reuse::new() (well, you’d expect it 
in the constructor).

Looking in the rules themselves, also, there aren’t that many rules which have 
an explicitly configured priority.

I ask because I’m trying to address this comment:

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060#c10

but the source base doesn’t really contain a lot of useful examples.

Thanks,

-Philip

Re: Rule priority

2014-09-17 Thread Philip Prindeville

I guess it’s not a hot topic.

Or else it’s not well understood.


On Sep 10, 2014, at 12:42 PM, Kevin A. McGrail  wrote:

> Can someone give him some guidance please?  I'd like to support him improving 
> the plugin and I'm a bit busy with the RC for 3.4.1 and the SA report.
> 
> 
>  Forwarded Message 
> Subject:  Rule priority
> Date: Wed, 10 Sep 2014 11:06:01 -0600
> From: Philip Prindeville 
> To:   SpamAssassin 
> 
> Is there a good discussion on how rule priority works, and short-circuited 
> evaluation, etc?
> 
> I must be looking in the wrong places because I can’t find much.  I found 
> register_method_priority() in ::Plugin but I wasn’t sure if that’s all there 
> is… It only seems to be called in Plugin::Reuse::new() (well, you’d expect it 
> in the constructor).
> 
> Looking in the rules themselves, also, there aren’t that many rules which 
> have an explicitly configured priority.
> 
> I ask because I’m trying to address this comment:
> 
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060#c10
> 
> but the source base doesn’t really contain a lot of useful examples.
> 
> Thanks,
> 
> -Philip
> 
>

[Bug 6782] [REVIEW] TLD update handling / RegistrarBoundaries need improving

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6782

Henrik Krohns  changed:

   What|Removed |Added

Summary|TLD update handling /   |[REVIEW] TLD update
   |RegistrarBoundaries need|handling /
   |improving   |RegistrarBoundaries need
   ||improving

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 6782] TLD update handling / RegistrarBoundaries need improving

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6782

--- Comment #5 from Henrik Krohns  ---
Created attachment 5237
  --> https://issues.apache.org/SpamAssassin/attachment.cgi?id=5237&action=edit
The cf that we might put into sa-update, for easy viewing here..

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 6782] TLD update handling / RegistrarBoundaries need improving

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6782

--- Comment #4 from Henrik Krohns  ---
Created attachment 5236
  --> https://issues.apache.org/SpamAssassin/attachment.cgi?id=5236&action=edit
All changed files for easy extraction/testing

lib/Mail/SpamAssassin/Conf.pm
lib/Mail/SpamAssassin/PerMsgStatus.pm
lib/Mail/SpamAssassin/Plugin/FreeMail.pm
lib/Mail/SpamAssassin/Plugin/HTTPSMismatch.pm
lib/Mail/SpamAssassin/Plugin/HeaderEval.pm
lib/Mail/SpamAssassin/Plugin/URIDNSBL.pm
lib/Mail/SpamAssassin/Plugin/URIEval.pm
lib/Mail/SpamAssassin/Plugin/WLBLEval.pm
lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm
lib/Mail/SpamAssassin/Util.pm
lib/Mail/SpamAssassin.pm
rules/20_aux_tlds.cf
t/ip_addrs.t
t/uri.t

(extract these over svn and make test; make install)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 6782] TLD update handling / RegistrarBoundaries need improving

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6782

--- Comment #3 from Henrik Krohns  ---
Created attachment 5235
  --> https://issues.apache.org/SpamAssassin/attachment.cgi?id=5235&action=edit
Complete diff vs current trunk

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 6782] TLD update handling / RegistrarBoundaries need improving

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6782

--- Comment #2 from Henrik Krohns  ---
Ok I steamed all evening to come up with something. I'll upload the
changes/diffs here before committing a large blob like this.. reviews,
suggestions, votes welcomed..

- Let's deprecate Util/RegistrarBoundaries.pm completely, but keep it bundled
for now because of third party plugins etc. Maybe delete all the leftovers on
3.5 release.

- Implement Mail::SpamAssassin::RegistryBoundaries (now is a good time to "fix"
the name :-D), basically the same code just copied

- Only way I managed to make the tld lists work dynamically everywhere is load
RegistryBoundaries in the root SpamAssassin.pm (even before plugins are
initialized, so plugins can se all the tlds there)

- Basically replaced
Mail::SpamAssassin::Util::RegistrarBoundaries::_domain() calls everywhere
with $self->{main}->{registryboundaries}->_domain()

- Conf.pm (temporarily) includes hardcoded list of domains, so things still
work before sa-update is done to get the updated 20_aux_tlds.cf, which now
includes all TLDs (new function clear_util_rb makes sure hardcoded values are
ignored)

- Mail::SpamAssassin::Util::uri_to_domain is deprecated and moved to
RegistryBoundaries since it needs the dynamic $self variables

Everything should work without breaking anything on any version.. maybe I
missed some scenario so check it out. :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

John Hardin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from John Hardin  ---
Committed 1625832

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

--- Comment #8 from John Hardin  ---
uncommented the ifplugin as well, and changed the subrule name in the meta so
that it's consistent.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

--- Comment #7 from AXB  ---
(In reply to John Hardin from comment #6)
> (In reply to AXB from comment #5)
> > disabled  SMF_FM_FORGED_REPLYTO - ruleqa reports same hit rate as
> > FREEMAIL_FORGED_REPLYTO
> 
> Given what I noted that's not too surprising.
> 
> The subrule in SMF should be renamed. It's entirely possible that adding
> :addr _does_ make a difference, but the code as it is now won't tell us that.

took a while to grasp that :)

rencommited using
__smf_freemail_hdr_replyto

and 
tflags SMF_FM_FORGED_REPLYTO  nopublish

so we can watch it

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

--- Comment #6 from John Hardin  ---
(In reply to AXB from comment #5)
> disabled  SMF_FM_FORGED_REPLYTO - ruleqa reports same hit rate as
> FREEMAIL_FORGED_REPLYTO

Given what I noted that's not too surprising.

The subrule in SMF should be renamed. It's entirely possible that adding :addr
_does_ make a difference, but the code as it is now won't tell us that.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread Axb


On 09/17/2014 06:12 PM, bugzilla-dae...@bugzilla.spamassassin.org wrote:

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

John Hardin  changed:

What|Removed |Added

  CC||jhar...@impsec.org

--- Comment #4 from John Hardin  ---
(In reply to AXB from comment #1)
SMF sandbox:

header   __freemail_hdr_replyto  eval:check_freemail_header('Reply-To:addr')


20_freemail.cf

header   __freemail_hdr_replyto  eval:check_freemail_header('Reply-To')


Using the same name for those two different evals is definitely an issue... the
one in SMF should be using a different subrule name if it's indeed intended to
be compared to the results of the base rule.



question is why are T_* rules showing up in 72_active.cf

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

--- Comment #5 from AXB  ---
disabled  SMF_FM_FORGED_REPLYTO - ruleqa reports same hit rate as
FREEMAIL_FORGED_REPLYTO

Commit Modified /trunk/rulesrc/sandbox/smf/20_smf.cf
Committed revision 1625641.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

John Hardin  changed:

   What|Removed |Added

 CC||jhar...@impsec.org

--- Comment #4 from John Hardin  ---
(In reply to AXB from comment #1)
SMF sandbox:
> header   __freemail_hdr_replyto  eval:check_freemail_header('Reply-To:addr')

20_freemail.cf
> header   __freemail_hdr_replyto  eval:check_freemail_header('Reply-To')

Using the same name for those two different evals is definitely an issue... the
one in SMF should be using a different subrule name if it's indeed intended to
be compared to the results of the base rule.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

Mark London  changed:

   What|Removed |Added

 CC||m...@psfc.mit.edu

--- Comment #3 from Mark London  ---
While there is a slight difference in the rules, they always trigger at the
same time:

[root@mail log]# grep T_SMF_FM_FORGED_REPLYT maillog* | grep -v
FREEMAIL_FORGED_REPLYTO
[root@mail log]# grep FREEMAIL_FORGED_REPLYTO maillog* | grep -v
T_SMF_FM_FORGED_REPLYT
[root@mail log]# grep T_SMF_FM_FORGED_REPLYT maillog* | wc -l
937

I've got the latest updates, and T_SMF_FM_FORGED_REPLYT still appears (redhat
linux):

[root@mail updates_spamassassin_org]# ls -l 72*
-rw-r--r-- 1 root root 213861 Sep 17 04:10 72_active.cf
-rw-r--r-- 1 root root  10282 Sep 17 04:10 72_scores.cf

[root@mail updates_spamassassin_org]# grep T_SMF_FM_FORGED_REPLYT 72_active.cf
72_active.cf:##{ T_SMF_FM_FORGED_REPLYTO ifplugin
Mail::SpamAssassin::Plugin::FreeMail
72_active.cf:meta T_SMF_FM_FORGED_REPLYTO  __freemail_hdr_replyto &&
!FREEMAIL_FROM && !__freemail_safe
72_active.cf:describe T_SMF_FM_FORGED_REPLYTO  Freemail in Reply-To, but not
From
72_active.cf:#scoreT_SMF_FM_FORGED_REPLYTO  0.1
72_active.cf:##} T_SMF_FM_FORGED_REPLYTO ifplugin
Mail::SpamAssassin::Plugin::FreeMail

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

--- Comment #2 from AXB  ---
FTR: unless we have a bug in autopromoting T_* rules shouldn't be published

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

--- Comment #1 from AXB  ---
seem but they're not

# Test potential error in base rules
header   __freemail_hdr_replyto  eval:check_freemail_header('Reply-To:addr')
meta SMF_FM_FORGED_REPLYTO  __freemail_hdr_replyto && !FREEMAIL_FROM &&
!__freemail_safe
describe SMF_FM_FORGED_REPLYTO  Freemail in Reply-To, but not From
scoreSMF_FM_FORGED_REPLYTO  0.1


# Idea from John Hardin
header   __freemail_hdr_replyto  eval:check_freemail_header('Reply-To')
meta FREEMAIL_FORGED_REPLYTO  __freemail_hdr_replyto && !FREEMAIL_FROM &&
!__freemail_safe
describe FREEMAIL_FORGED_REPLYTO  Freemail in Reply-To, but not From
scoreFREEMAIL_FORGED_REPLYTO  0.1


Reply-To versus Reply-To:addr

both scored 0.1 so not major issue

I don't see SMF_FM_FORGED_REPLYTO being published in the latest update

wonder how you got the  T_SMF_FM_FORGED_REPLYTO  rule
Have you run sa-update recently?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7084] New: T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7084

Bug ID: 7084
   Summary: T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO
seem identical.
   Product: Spamassassin
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Rules
  Assignee: dev@spamassassin.apache.org
  Reporter: m...@psfc.mit.edu

The T_SMF_FM_FORGED_REPLYTO rule was recently added,and it looks identical to
FREEMAIL_FORGED_REPLYTO.   A mistake, or is there a reason for both?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7083] Match anonymized/masked hosts

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7083

bugzill...@free.fr changed:

   What|Removed |Added

 CC||bugzill...@free.fr

--- Comment #2 from bugzill...@free.fr ---
Masked domains are proxied domains, ie points to a different ip than the
original server.

Some companies providing this service will never reveal original IP on abuse
(ex: cloudflare) whatever the criminal activity is. crimeflare.com has a
description of this.

This is why this is now the preferred spammers way to spamvertise websites as
the target website will always be running and proxyer will never shut down
redirection (spam not coming from them...). They just need to snowhoe and post
a link to that content or include asset from those hosts.

Although proxying could be legitimate for some reasons, that could also be used
as a signal, especially with no real body content.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7083] Match anonymized/masked hosts

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7083

AXB  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from AXB  ---
what are "masked domains" ? and how are they any different  than any other?

what is non compliant about cloudflare?
what do you propose?

As it is not clear what you request, please move the discussion to the user or
dev list.
This is not a bug or well specified feature request

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 7083] New: Match anonymized/masked hosts

2014-09-17 Thread bugzilla-daemon

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7083

Bug ID: 7083
   Summary: Match anonymized/masked hosts
   Product: Spamassassin
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Rules
  Assignee: dev@spamassassin.apache.org
  Reporter: bugzill...@free.fr

90% of the SPAM that gets through rules are links to masked domains sent
through snowhoe hosts.

A rule to match masked domains using non compliant companies (ex: resolving to
cloudflare) in body would be a good signal.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Rule updates are too old - 2014-09-17

2014-09-17 Thread darxus

20140916:  Spam or ham is below threshold of 150,000:  
http://ruleqa.spamassassin.org/?daterev=20140916
20140916:  Spam: 455648, Ham: 149141


The spam and ham counts on which this script alerts are from
http://ruleqa.spamassassin.org/?daterev=20140916
Click "(source details)" (it's tiny and low contrast).
It's from the second and third columns of the line that ends with
"(all messages)"

The source to this script is
http://www.chaosreigns.com/sa/update-version-mon.pl

[Bug 6782] [REVIEW] TLD update handling / RegistrarBoundaries need improving

[Bug 6782] [REVIEW] TLD update handling / RegistrarBoundaries need improving

Re: Rule priority

Re: Rule priority

[Bug 6782] [REVIEW] TLD update handling / RegistrarBoundaries need improving

[Bug 6782] TLD update handling / RegistrarBoundaries need improving

[Bug 6782] TLD update handling / RegistrarBoundaries need improving

[Bug 6782] TLD update handling / RegistrarBoundaries need improving

[Bug 6782] TLD update handling / RegistrarBoundaries need improving

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

Re: [Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7084] T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7084] New: T_SMF_FM_FORGED_REPLYTO and FREEMAIL_FORGED_REPLYTO seem identical.

[Bug 7083] Match anonymized/masked hosts

[Bug 7083] Match anonymized/masked hosts

[Bug 7083] New: Match anonymized/masked hosts

Rule updates are too old - 2014-09-17

24 matches

Site Navigation

Mail list logo

Footer information