You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by fe...@apache.org on 2005/04/26 23:18:16 UTC
svn commit: r164885 - in /spamassassin/branches/3.0:
lib/Mail/SpamAssassin/EvalTests.pm rules/20_dnsbl_tests.cf rules/50_scores.cf
Author: felicity
Date: Tue Apr 26 14:18:16 2005
New Revision: 164885
URL: http://svn.apache.org/viewcvs?rev=164885&view=rev
Log:
bug 3998: add support for Habeas Accreditor (v2)
Modified:
spamassassin/branches/3.0/lib/Mail/SpamAssassin/EvalTests.pm
spamassassin/branches/3.0/rules/20_dnsbl_tests.cf
spamassassin/branches/3.0/rules/50_scores.cf
Modified: spamassassin/branches/3.0/lib/Mail/SpamAssassin/EvalTests.pm
URL: http://svn.apache.org/viewcvs/spamassassin/branches/3.0/lib/Mail/SpamAssassin/EvalTests.pm?rev=164885&r1=164884&r2=164885&view=diff
==============================================================================
--- spamassassin/branches/3.0/lib/Mail/SpamAssassin/EvalTests.pm (original)
+++ spamassassin/branches/3.0/lib/Mail/SpamAssassin/EvalTests.pm Tue Apr 26 14:18:16 2005
@@ -1351,10 +1351,20 @@
check_rbl_sub(@_);
}
-# check a RBL if a message is Habeas SWE
+# Check a RBL if a message is Habeas SWE.
+# Test is skipped if the SWE 2.0 "Reputation Tag" is matched in the
+# Envelope From address. Otherwise transitional senders would get a
+# double bonus. <cs...@habeas.com>
+#
sub check_rbl_swe {
my ($self, $rule, $set, $rbl_server, $subtest) = @_;
+ if (!defined $self->{envelope_accreditor_tag}) {
+ $self->message_envelope_accreditor_tag();
+ }
+ if ($self->{envelope_accreditor_tag}) {
+ return 0;
+ }
if (!defined $self->{habeas_swe}) {
$self->message_is_habeas_swe();
}
@@ -1364,6 +1374,22 @@
return 0;
}
+# check an RBL if "--accreditor" tag is in Envelope From.
+# <cs...@habeas.com>
+#
+sub check_rbl_accreditor {
+ my ($self, $rule, $set, $rbl_server, $subtest, $accreditor) = @_;
+
+ if (!defined $self->{envelope_accreditor_tag}) {
+ $self->message_envelope_accreditor_tag();
+ }
+ if ($self->{envelope_accreditor_tag} eq $accreditor) {
+ $self->check_rbl_backend($rule, $set, $rbl_server, 'A', $subtest);
+ }
+ return 0;
+}
+
+
# this only checks the address host name and not the domain name because
# using the domain name had much worse results for dsn.rfc-ignorant.org
sub check_rbl_from_host {
@@ -2116,6 +2142,16 @@
}
return $self->{habeas_swe};
+}
+
+sub message_envelope_accreditor_tag {
+ my ($self) = @_;
+
+ if ($self->get('EnvelopeFrom:addr') =~ /[@.]a--([a-z0-9]{3,})\./i) {
+ ($self->{envelope_accreditor_tag} = $1) =~ tr/A-Z/a-z/;
+ return;
+ }
+ $self->{envelope_accreditor_tag} = "";
}
###########################################################################
Modified: spamassassin/branches/3.0/rules/20_dnsbl_tests.cf
URL: http://svn.apache.org/viewcvs/spamassassin/branches/3.0/rules/20_dnsbl_tests.cf?rev=164885&r1=164884&r2=164885&view=diff
==============================================================================
--- spamassassin/branches/3.0/rules/20_dnsbl_tests.cf (original)
+++ spamassassin/branches/3.0/rules/20_dnsbl_tests.cf Tue Apr 26 14:18:16 2005
@@ -171,6 +171,26 @@
tflags DNS_FROM_RFC_BOGUSMX net
# ---------------------------------------------------------------------------
+# Habeas Accredited Senders
+# Last octet of the returned A record indicates the Habeas-assigned
+# "Accreditation Level" of the Sender.
+# 10 to 39 Personal, transactional, and Confirmed Opt In
+# 40 to 59 Secure referrals and Single Opt In
+# 60 to 99 Checked but not accredited by Habeas.
+#
+# sa-accredit.habeas.com is for SpamAssassin use.
+#
+header HABEAS_ACCREDITED_COI eval:check_rbl_accreditor('accredit-firsttrusted', 'sa-accredit.habeas.com.', '127\.\d+\.\d+\.[123]\d', 'habeas')
+describe HABEAS_ACCREDITED_COI Habeas Accredited Confirmed Opt-In or Better
+tflags HABEAS_ACCREDITED_COI net nice
+header HABEAS_ACCREDITED_SOI eval:check_rbl_accreditor('accredit-firsttrusted', 'sa-accredit.habeas.com.', '127\.\d+\.\d+\.[45]\d', 'habeas')
+describe HABEAS_ACCREDITED_SOI Habeas Accredited Opt-In or Better
+tflags HABEAS_ACCREDITED_SOI net nice
+header HABEAS_CHECKED eval:check_rbl_accreditor('accredit-firsttrusted', 'sa-accredit.habeas.com.', '127\.\d+\.\d+\.[6789]\d', 'habeas')
+describe HABEAS_CHECKED Habeas Checked
+tflags HABEAS_CHECKED net nice
+
+# ---------------------------------------------------------------------------
# Now, single zone BLs follow:
# DSBL catches open relays, badly-installed CGI scripts and open SOCKS and
@@ -192,15 +212,18 @@
describe DNS_FROM_AHBL_RHSBL From: sender listed in dnsbl.ahbl.org
tflags DNS_FROM_AHBL_RHSBL net
+# Habeas Legacy support: the Habeas Infringers blocklist.
# sa-hil.habeas.com for SpamAssassin queries
# hil.habeas.com for other queries
header HABEAS_INFRINGER eval:check_rbl_swe('hil', 'sa-hil.habeas.com.')
describe HABEAS_INFRINGER Has Habeas warrant mark and on Infringer List
tflags HABEAS_INFRINGER net
+# Habeas Legacy support: the Habeas Users whitelist. This list contains users
+# from accredit.habeas.com at "accreditation level" 10 to 39.
# sa-hul.habeas.com for SpamAssassin queries
# hul.habeas.com for other queries
-header HABEAS_USER eval:check_rbl_swe('hul', 'sa-hul.habeas.com.')
+header HABEAS_USER eval:check_rbl_swe('hul-firsttrusted', 'sa-hul.habeas.com.')
describe HABEAS_USER Has Habeas warrant mark and on User List
tflags HABEAS_USER net nice
Modified: spamassassin/branches/3.0/rules/50_scores.cf
URL: http://svn.apache.org/viewcvs/spamassassin/branches/3.0/rules/50_scores.cf?rev=164885&r1=164884&r2=164885&view=diff
==============================================================================
--- spamassassin/branches/3.0/rules/50_scores.cf (original)
+++ spamassassin/branches/3.0/rules/50_scores.cf Tue Apr 26 14:18:16 2005
@@ -657,6 +657,9 @@
score RCVD_IN_BSP_TRUSTED 0 -4.3 0 -4.3
# Habeas: http://www.habeas.com/
+score HABEAS_ACCREDITED_COI 0 -8.0 0 -8.0
+score HABEAS_ACCREDITED_SOI 0 -4.0 0 -4.0
+score HABEAS_CHECKED 0 -0.2 0 -0.2
score HABEAS_INFRINGER 0 16.0 0 16.0
score HABEAS_USER 0 -8.0 0 -8.0
Re: Habeas check-ins
Posted by Warren Togami <wt...@redhat.com>.
Michael Parker wrote:
>
> I also have some free time for the next week or so, so I decided to
> take on the task, make a few people happy. I certainly don't want to
> be troubleshooting AWL memory problems 2 years from now from someone
> using SA in a "stable" version of an OS. Witness 2.20 in Debian
> stable, 2.55 in RHEL3 or 2.64 in SUSE Enterprise. Hopefully by
> getting 3.0.3 out there and available it will make life easier down
> the road.
>
> I really don't want to put in all this effort to find out a few weeks
> from now that an enhancement is causing problems and we'll have to
> live with those problems for a couple of years to come.
>
>
>>Also in general, discussions/votes ought to go in the ticket, otherwise
>>it's too hard to track where the conversations are taking place.
>>
>
>
> Yeah, I apologize, I should have made my veto more public. I'll be
> sure to do so much earlier in the process next time.
According to quinlan it isn't tested well and wouldn't change scores
much, so I vote to not take the risk. Pure bug fixes only please.
Warren Togami
wtogami@redhat.com
Re: Habeas check-ins
Posted by Michael Parker <pa...@pobox.com>.
On Tue, Apr 26, 2005 at 06:24:01PM -0400, Theo Van Dinter wrote:
> On Tue, Apr 26, 2005 at 04:41:39PM -0500, Michael Parker wrote:
> > > I am -0.9 on these two changes going into 3.0.3 at this late date. They
> > > are not bug fixes and I do NOT want to release a 3.0.4 for any reason
> > > other than a security update. Do we have to do this here?
> >
> > Agreed, the primary motivation for this release is a rock solid final
> > release for 3.0. Several distributions have been asking for this so
> > they can roll the latest into their releases. Adding features is not
> > something that should be happening at this point in time.
>
> The patches were supposed to be in 3.0.2, but got skipped for several
> reasons, all of them procedural. I'm also not sure what "late date"
> means here -- 3998 has been in the 3.0.3 queue for as long as there's
> been a 3.0.3 queue. It's not as if it's a last minute set of code or
> something that just got put in the queue last night. There were no
> current vetos in the tickets as of this morning for either patch, FWIW.
Perhaps a reluctance to put new functionality into a maintenance
release. Age of the code isn't the issue, it's the fact that it's an
enhancement to a stable code release.
Admittedly I should have made my veto more public and added it to the
bug. It's there now. I'm quite adamant about making the 3.0.3
release very solid. It fixes several annoyances in 3.0.2 and I
believe it should provide some longevity for the 3.0 code line.
> Frankly, the whole 3.0.3 release is strange imo. We all were saying,
> for several months now, that there was not going to be a 3.0.3 release
> and were focusing on 3.1 w/ an upgrade being the official "bug fix/etc"
> path. That's why most things in the 3.0.3 queue have just sat there
> and haven't been commented on. Now suddenly (for a week or two anyway)
> there's a strong desire to get 3.0.3 out? Alright, enough venting.
Yes, I believe the intention was to focus our efforts on 3.1. It just
so happens that recently several folks have been asking about a 3.0.3
and getting a stable release for some long lived distributions.
I also have some free time for the next week or so, so I decided to
take on the task, make a few people happy. I certainly don't want to
be troubleshooting AWL memory problems 2 years from now from someone
using SA in a "stable" version of an OS. Witness 2.20 in Debian
stable, 2.55 in RHEL3 or 2.64 in SUSE Enterprise. Hopefully by
getting 3.0.3 out there and available it will make life easier down
the road.
I really don't want to put in all this effort to find out a few weeks
from now that an enhancement is causing problems and we'll have to
live with those problems for a couple of years to come.
>
> Also in general, discussions/votes ought to go in the ticket, otherwise
> it's too hard to track where the conversations are taking place.
>
Yeah, I apologize, I should have made my veto more public. I'll be
sure to do so much earlier in the process next time.
Michael
Re: Habeas check-ins
Posted by Theo Van Dinter <fe...@kluge.net>.
On Tue, Apr 26, 2005 at 04:41:39PM -0500, Michael Parker wrote:
> > I am -0.9 on these two changes going into 3.0.3 at this late date. They
> > are not bug fixes and I do NOT want to release a 3.0.4 for any reason
> > other than a security update. Do we have to do this here?
>
> Agreed, the primary motivation for this release is a rock solid final
> release for 3.0. Several distributions have been asking for this so
> they can roll the latest into their releases. Adding features is not
> something that should be happening at this point in time.
The patches were supposed to be in 3.0.2, but got skipped for several
reasons, all of them procedural. I'm also not sure what "late date"
means here -- 3998 has been in the 3.0.3 queue for as long as there's
been a 3.0.3 queue. It's not as if it's a last minute set of code or
something that just got put in the queue last night. There were no
current vetos in the tickets as of this morning for either patch, FWIW.
Frankly, the whole 3.0.3 release is strange imo. We all were saying,
for several months now, that there was not going to be a 3.0.3 release
and were focusing on 3.1 w/ an upgrade being the official "bug fix/etc"
path. That's why most things in the 3.0.3 queue have just sat there
and haven't been commented on. Now suddenly (for a week or two anyway)
there's a strong desire to get 3.0.3 out? Alright, enough venting.
As for the 3998 commit, I miscounted the vote that did occur, so that's
reverted now. Sorry.
Also in general, discussions/votes ought to go in the ticket, otherwise
it's too hard to track where the conversations are taking place.
--
Randomly Generated Tagline:
"I don't even have to get dressed up for Halloween. I go as me." - Judge Judy
Re: Habeas check-ins
Posted by Michael Parker <pa...@pobox.com>.
On Tue, Apr 26, 2005 at 02:36:09PM -0700, Daniel Quinlan wrote:
> I am -0.9 on these two changes going into 3.0.3 at this late date. They
> are not bug fixes and I do NOT want to release a 3.0.4 for any reason
> other than a security update. Do we have to do this here?
Agreed, the primary motivation for this release is a rock solid final
release for 3.0. Several distributions have been asking for this so
they can roll the latest into their releases. Adding features is not
something that should be happening at this point in time.
Michael
Habeas check-ins
Posted by Daniel Quinlan <qu...@pathname.com>.
I am -0.9 on these two changes going into 3.0.3 at this late date. They
are not bug fixes and I do NOT want to release a 3.0.4 for any reason
other than a security update. Do we have to do this here?
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Habeas check-ins
Posted by Daniel Quinlan <qu...@pathname.com>.
I am -0.9 on these two changes going into 3.0.3 at this late date. They
are not bug fixes and I do NOT want to release a 3.0.4 for any reason
other than a security update. Do we have to do this here?
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/