Re: Junk mixed in with ham on whitelists

On 02/22/18 15:56, David Jones wrote: > On 02/22/2018 08:52 AM, Benny Pedersen wrote: >> Giovanni Bechis skrev den 2018-02-22 15:39: >> sub check_dkim_valid {   my ($self, $pms, $full_ref, @acceptable_domains) = @_;   $self->_check_dkim_signature($pms)  if !$pms->{dkim_checked_signat

Re: Junk mixed in with ham on whitelists

On 02/22/2018 08:52 AM, Benny Pedersen wrote: Giovanni Bechis skrev den 2018-02-22 15:39: sub check_dkim_valid {   my ($self, $pms, $full_ref, @acceptable_domains) = @_;   $self->_check_dkim_signature($pms)  if !$pms->{dkim_checked_signature};   my $result = 0;   if (!$pms->{dkim_valid}) {   

Re: Junk mixed in with ham on whitelists

Giovanni Bechis skrev den 2018-02-22 15:39: sub check_dkim_valid { my ($self, $pms, $full_ref, @acceptable_domains) = @_; $self->_check_dkim_signature($pms) if !$pms->{dkim_checked_signature}; my $result = 0; if (!$pms->{dkim_valid}) { # don't bother } elsif (!@acceptable_domain

Re: Junk mixed in with ham on whitelists

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/22/18 15:34, Benny Pedersen wrote: > Benny Pedersen skrev den 2018-02-21 17:55: >> David Jones skrev den 2018-02-21 17:41: >> >>> I have that same code in my DKIM.pm and I am running 3.4.1. Maybe the >>> size acceptable for whitelisting is dif

Re: Junk mixed in with ham on whitelists

Benny Pedersen skrev den 2018-02-21 17:55: David Jones skrev den 2018-02-21 17:41: I have that same code in my DKIM.pm and I am running 3.4.1. Maybe the size acceptable for whitelisting is different from the DKIM_VALID check? minimal key bits could be a plugin test yes, but imho it never mad

Re: Junk mixed in with ham on whitelists

David Jones skrev den 2018-02-21 17:41: I have that same code in my DKIM.pm and I am running 3.4.1. Maybe the size acceptable for whitelisting is different from the DKIM_VALID check? minimal key bits could be a plugin test yes, but imho it never made to do this Does the check_dkim_valid f

Re: Junk mixed in with ham on whitelists

On 02/21/2018 10:22 AM, Benny Pedersen wrote: David Jones skrev den 2018-02-21 15:46: Bug 7559 opened.  I don't want to delay 3.4.2 either.  I don't think this is major enough to have to go into 3.4.2 unless someone can provide a quick patch for Kevin. in dkim.pm plugin i find   # minimal s

Re: Junk mixed in with ham on whitelists

David Jones skrev den 2018-02-21 15:46: Bug 7559 opened. I don't want to delay 3.4.2 either. I don't think this is major enough to have to go into 3.4.2 unless someone can provide a quick patch for Kevin. in dkim.pm plugin i find # minimal signing key size in bits that is acceptable for w

Re: Junk mixed in with ham on whitelists

On 02/21/18 00:24, Benny Pedersen wrote: > David Jones skrev den 2018-02-21 00:14: > >> https://pastebin.com/mjvB0MKg  (scored 10.96) >> -0.10    DKIM_VALID    Message has at least one valid DKIM or DK signature > > Authentication-Results: smtp3i.ena.net; > dkim=policy reason="signing key too

Re: Junk mixed in with ham on whitelists

On 02/21/2018 08:30 AM, Benny Pedersen wrote: Kevin A. McGrail skrev den 2018-02-21 14:44: On 2/21/2018 8:42 AM, David Jones wrote: Do we need to open a bug to get SA's DKIM code to check for a minimum key size? When in doubt, open a bug. more bugs will delay 3.4.2 :=) Bug 7559 opened. I

Re: Junk mixed in with ham on whitelists

Kevin A. McGrail skrev den 2018-02-21 14:44: On 2/21/2018 8:42 AM, David Jones wrote: Do we need to open a bug to get SA's DKIM code to check for a minimum key size? When in doubt, open a bug. more bugs will delay 3.4.2 :=)

Re: Junk mixed in with ham on whitelists

David Jones skrev den 2018-02-21 14:42: My guess is SA's DKIM check doesn't care about the size of the key. OpenDKIM has a setting of "MinimumKeyBits 1024" since anything smaller can be trivially cracked. Do we need to open a bug to get SA's DKIM code to check for a minimum key size? yes pl

Re: Junk mixed in with ham on whitelists

On 21-02-18 14:54, David Jones wrote: > On 02/21/2018 07:44 AM, Kevin A. McGrail wrote: >> On 2/21/2018 8:42 AM, David Jones wrote: >>> Do we need to open a bug to get SA's DKIM code to check for a minimum >>> key size? >> >> When in doubt, open a bug. >> > > Well. Ummm.  I found this when star

Re: Junk mixed in with ham on whitelists

On 02/21/2018 07:44 AM, Kevin A. McGrail wrote: On 2/21/2018 8:42 AM, David Jones wrote: Do we need to open a bug to get SA's DKIM code to check for a minimum key size? When in doubt, open a bug. Well. Ummm. I found this when starting to create the bug: https://bz.apache.org/SpamAssassin

Re: Junk mixed in with ham on whitelists

On 2/21/2018 8:42 AM, David Jones wrote: Do we need to open a bug to get SA's DKIM code to check for a minimum key size? When in doubt, open a bug.

Re: Junk mixed in with ham on whitelists

On 02/20/2018 05:24 PM, Benny Pedersen wrote: David Jones skrev den 2018-02-21 00:14: https://pastebin.com/mjvB0MKg  (scored 10.96) -0.10    DKIM_VALID    Message has at least one valid DKIM or DK signature Authentication-Results: smtp3i.ena.net; dkim=policy reason="signing key too smal

Re: Junk mixed in with ham on whitelists

On 20 Feb 2018, at 16:48, David Jones wrote: It doesn't seem like a good idea for whitelists to list these senders just because most of the email is ham. I can see no evidence for that in a quick check of my personal mail. In 10 years: 68 messages 50 spam (all reported) 6 replies to

Re: Junk mixed in with ham on whitelists

David Jones skrev den 2018-02-21 00:14: https://pastebin.com/mjvB0MKg (scored 10.96) -0.10 DKIM_VALID Message has at least one valid DKIM or DK signature Authentication-Results: smtp3i.ena.net; dkim=policy reason="signing key too small" (768-bit key) header.d=mails-express.com header

Re: Junk mixed in with ham on whitelists

eld from a whitelist perspective for those servers by offsetting the whitelist negative scores to get them back to around zero and let Bayes plus other content-based rules determine the allow or block. It doesn't seem like a good idea for whitelists to list these senders just because most of t

Re: Junk mixed in with ham on whitelists

David Jones skrev den 2018-02-20 23:08: That is ridiculous!!! It requires 8 DNS queries and shouldn't include Google's servers. +1 v=spf1 ip4:23.83.208.1/20 ip4:23.91.112.0/20 ip4:46.232.183.0/24 ip4:50.87.152.0/21 ip4:50.116.64.0/18 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20

Re: Junk mixed in with ham on whitelists

servers by offsetting the whitelist negative scores to get them back to around zero and let Bayes plus other content-based rules determine the allow or block. It doesn't seem like a good idea for whitelists to list these senders just because most of the email is ham.  If a small percentage is spa

Re: Junk mixed in with ham on whitelists

res to get them back to around zero and let Bayes plus other content-based rules determine the allow or block. It doesn't seem like a good idea for whitelists to list these senders just because most of the email is ham. If a small percentage is spam, then how do we report that back t

Junk mixed in with ham on whitelists

|internetbilisim\.net|privateemail\.com|registrar-servers\.com|emailsrvr\.com|registeredsite\.com) \[/ Many of these servers are listed on whitelists. My solution is to meta those whitelists to add back the points they subtract and then selectively whitelist_auth safe/good sending domains coming from

Re: Return Path (TM) whitelists

ly strongly. > I'd suggest that SPF:PASS means you can rely on domain based logic > (trusts/whitelists/reputation) rather than only IP based logic, > allowing you to safely whitelist "example.com" without guessing what > IPs example.com uses (and might use tomorrow.) In our com

Re: Return Path (TM) whitelists

meaningless on it's own. I'd suggest that SPF:PASS means you can rely on domain based logic (trusts/whitelists/reputation) rather than only IP based logic, allowing you to safely whitelist "example.com" without guessing what IPs example.com uses (and might use tomorrow.)

Re: Return Path (TM) whitelists

On Fri, 10 Jul 2015 12:09:27 -0400 Rob McEwen wrote: > And some on this thread are not realizing that DNSWL has various > LEVELS in its ratings of senders I don't see anything in this thread to suggest that. > most of the time that > a virus-sent spam is sent from an IP in DNSWL, it is from a

Re: Return Path (TM) whitelists

Also, often, the Return Path certified sender is an ESP who sends for a variety of customers. There is not always an absolute guarantee that every one of that ESP's customer is ethical and truthful. A good ESP will quickly fire such any such "bad apple" customer... but some do a much better job

Re: Return Path (TM) whitelists

On Fri, 10 Jul 2015 17:34:06 +0200 Reindl Harald wrote: > it's enough *once time* overlook the small letters besides soem > checkbox saying "we give your data to our partners" and so agree > without intention while it's hard to impossible to realize the > connection when wekks or months later a m

Re: Return Path (TM) whitelists

Am 10.07.2015 um 17:15 schrieb Ian Zimmerman: On 2015-07-10 16:36 +0200, Reindl Harald wrote: most users enable checkboxes which are needed to get random forms submitted, even if they say "i agree to get mails from here and there" and are missing the context when that mails are coming later

Re: Return Path (TM) whitelists

On 2015-07-10 16:36 +0200, Reindl Harald wrote: > most users enable checkboxes which are needed to get random forms > submitted, even if they say "i agree to get mails from here and > there" and are missing the context when that mails are coming later You don't know me, so you can hardly claim a

Re: Return Path (TM) whitelists

On Fri, 10 Jul 2015 09:06:58 +0200 Matthias Leisi wrote: > For the record, this is the reason why dnswl.org > does not charge for listings (and we don’t call it certification): it > always leads to conflicts of interest. Yes, I trust dnswl.org. What we need is a meta-reputat

Re: Return Path (TM) whitelists

Am 10.07.2015 um 16:34 schrieb Ian Zimmerman: On 2015-07-10 13:54 +0100, RW wrote: I don't get any spam at all in the return-path lists. ... I don't doubt that there's some abuse, but I also find it hard to believe that the accuracy of the return-path rules isn't dominated by user behav

Re: Return Path (TM) whitelists

On 2015-07-10 13:54 +0100, RW wrote: > I don't get any spam at all in the return-path lists. > ... > I don't doubt that there's some abuse, but I also find it hard to > believe that the accuracy of the return-path rules isn't dominated by > user behaviour. Can you specify "user behaviour" in mo

Re: Return Path (TM) whitelists

On Thu, 9 Jul 2015 18:07:07 -0400 Dianne Skoll wrote: > On Fri, 10 Jul 2015 07:58:39 +1000 > Noel Butler wrote: > > > +1 > > I'll throw my +1 in on this also. Almost by definition, the kinds of > organizations who buy into these certifications to get their mail > delivered are unlikely to be t

Re: Return Path (TM) whitelists

On 7/9/2015 6:07 PM, Dianne Skoll wrote: On Fri, 10 Jul 2015 07:58:39 +1000 Noel Butler wrote: +1 I'll throw my +1 in on this also. Almost by definition, the kinds of organizations who buy into these certifications to get their mail delivered are unlikely to be the kinds of organizations I w

Re: Return Path (TM) whitelists

> Am 10.07.2015 um 00:07 schrieb Dianne Skoll : > > On Fri, 10 Jul 2015 07:58:39 +1000 > Noel Butler wrote: > >> +1 > > I'll throw my +1 in on this also. Almost by definition, the kinds of > organizations who buy into these certifications to get their mail > delivered are unlikely to be the

Re: Return Path (TM) whitelists

On Fri, 10 Jul 2015 07:58:39 +1000 Noel Butler wrote: > +1 I'll throw my +1 in on this also. Almost by definition, the kinds of organizations who buy into these certifications to get their mail delivered are unlikely to be the kinds of organizations I want to hear from. Just as SPF "pass" is a

Re: Return Path (TM) whitelists

d filtering, by using right keywords and blah blah blah to get that successful inbox placement... (hint: we nuke all whitelists in SA anyway)

Re: Return Path (TM) whitelists

. I have repeatedly had problems with returnpath, getting spam from places that they have "certified". The notion of giving those rules a small positive score is quite reasonable. Generally, SA assigns scores based on a ham/spam corpus. For rules that aren't pay-to-play whiteli

Re: Return Path (TM) whitelists

rupulous senders. You shouldn't penalize legit senders that follow the rules (i.e. constantcontact.com, mailchimp.com, etc.) and provide legitimate unsubscribe methods. Just unsubscribe from the trustworthy senders usually in whitelists like Return Path and others. If they start abusing thing

Re: Return Path (TM) whitelists

On 2015-07-09 16:58 +, David Jones wrote: > Did the email have a valid unsubscribe link/process? It is in Dutch, and I can't read Dutch. (Yes, I do use the language plugin.) > I shortcircuit as ham for these two rule hits and never have had a > report of spam that couldn't be reliably/safely

Re: Return Path (TM) whitelists

I just got in my inbox what I consider spam from the Belgian domain selling Japanese copiers & printers (you probably know which one). What made it pass through SA were RCVD_IN_RP_CERTIFIED and RCVD_IN_RP_SAFE. Together they account for a whopping -5 points - a poison antidote pill! Isn't that a

Re: Return Path (TM) whitelists

>From: Ian Zimmerman >Sent: Thursday, July 9, 2015 11:02 AM >To: users@spamassassin.apache.org >Subject: Return Path (TM) whitelists >I just got in my inbox what I consider spam from the Belgian domain >selling Japanese copiers & printers (you probably know which one

Return Path (TM) whitelists

I just got in my inbox what I consider spam from the Belgian domain selling Japanese copiers & printers (you probably know which one). What made it pass through SA were RCVD_IN_RP_CERTIFIED and RCVD_IN_RP_SAFE. Together they account for a whopping -5 points - a poison antidote pill! Isn't that a b

Re: Spam via whitelists

AndreaS Schamanek skrev den 2013-07-03 21:52: Only if I also add 172.31.38.210 (private address from a reserved block) it works as I expected it. Looks like I will use trusted_networks to save some CPU cycles but I'll also keep my meta rules. yep, rfc1700 is default listed in spamassassin,

Re: Spam via whitelists

On Wed, 3 Jul 2013 12:52:43 -0700 (PDT) AndreaS Schamanek wrote: > Anyway, using trusted_networks I found that it doesn't work fully > unless I manage to list their complete mail infrastructure. I didn't > know that IPs from trusted_networks can actually be subject to evals. >... > Only if I also

Re: Spam via whitelists

filtering. ... They are whitelisted (in this case by JMF-WHITE and >> DNSWL_MED) >> which (would) lead to false negatives. Moreover, it renders our >> statistical analyses useless for their IPs. > > Put such sources in SA's trusted_networks. This also ensures that

Re: Spam via whitelists

server and let spamassassin query it, ip-repution is part of can-it other front end for spamassassin, google it Should I file complaints? whitelists is basicly just for mta stage, not spamassassin testing, only reason dnseval exists is for mta setup that does not test rbls, for dnswl you can

Re: Spam via whitelists

ted_networks. This also ensures that blacklists (and whitelists) are applied to the IPs delivering to these forwarding systems. -- Matthias

Spam via whitelists

Hi SA fellows, I sometimes disagree with whitelists such as DNSWL_MED, chaosreigns.com/iprep/ or JMF-WHITE. There are 2 main issues: 1) Less often recently, but I did see freemail MTA IPs from Google, Yahoo! and other big players showing up on whitelists. Considering the amount of spam

Re: Return Path Whitelists, RP_SAFE, RP_CERTIFIED, RP_MATCHES‏

On Mon, 21 Nov 2011 13:50:05 + RW wrote: > On Mon, 21 Nov 2011 03:11:48 -0800 (PST) > pipjg wrote: > > RuleTotal Ham % Spam% > > RP_MATCHES_RCVD 161,165 142,559 88.5 > > 18,606 11.5 RCVD_IN_RP_SAFE22,405 22,399 > describe RP_MATCHES_RCV

Re: Return Path Whitelists, RP_SAFE, RP_CERTIFIED, RP_MATCHES‏

On 11/21/2011 10:53 AM, dar...@chaosreigns.com wrote: > On 11/21, pipjg wrote: >> dumn here? Does the T_ mean something I don't know? > Yes, it means there is a bug in the way spamassassin rules are being > published. It stands for "testing". > > "rules with a T_ prefix to their names are never pu

Re: Return Path Whitelists, RP_SAFE, RP_CERTIFIED, RP_MATCHES‏

On 11/21, pipjg wrote: > dumn here? Does the T_ mean something I don't know? Yes, it means there is a bug in the way spamassassin rules are being published. It stands for "testing". "rules with a T_ prefix to their names are never published" - http://wiki.apache.org/spamassassin/SaUpdateBackend

Re: Return Path Whitelists, RP_SAFE, RP_CERTIFIED, RP_MATCHES‏

A score > reduced by what looks like paid for whitelists. A view of the SA > scores I'm seeing is: > > Rule Total Ham % Spam% > RP_MATCHES_RCVD 161,165 142,559 88.5 > 18,60611.5 RCVD_IN_RP_SAFE22,405 22,399 >

Re: Return Path Whitelists, RP_SAFE, RP_CERTIFIED, RP_MATCHES‏

On Mon, 21 Nov 2011 03:11:48 -0800 (PST), pipjg wrote: Has anyone else seen this or got any advice on this matter? Should we be trusting a paid for whitelist? where do you pay ? why not report spam to returnpath ? but feel free to set scores to zero, if you like to pay :-)

Return Path Whitelists, RP_SAFE, RP_CERTIFIED, RP_MATCHES‏

Hi, Was wondering if could have some advice, and I probably know what I'm going to do anyway, just wanted a few others opinions.. I've been analysing a load of mail which is having it's SA score reduced by what looks like paid for whitelists. A view of the SA scores I

Re: injected headers are triggering dns whitelists

On fre 17 sep 2010 16:55:11 CEST, Lawren Quigley-Jones wrote I'm running SpamAssassin on ubuntu hardy: spamassassin 3.2.4-1ubuntu1.2 is this a joke ? :) -- xpoint http://www.unicom.com/pw/reply-to-harmful.html

Re: injected headers are triggering dns whitelists

being injected at the beginning of emails which are tripping dns whitelists (see below). As a result I've been slowly disabling dns whitelist rules: score HABEAS_ACCREDITED_COI 0 score HABEAS_ACCREDITED_SOI 0 score RCVD_IN_DNSWL_MED 0 score RCVD_IN_BSP_TRUSTED 0 score RCVD_IN_DNSWL_HI 0 I

Re: injected headers are triggering dns whitelists

στις 17/09/2010 05:55 μμ, O/H Lawren Quigley-Jones έγραψε: I've been repeatedly running into problems where dns white-lists have been causing false negatives in spam. Valid looking headers are being injected at the beginning of emails which are tripping dns whitelists (see below).

Re: injected headers are triggering dns whitelists

On 9/17/2010 10:55 AM, Lawren Quigley-Jones wrote: > I've been repeatedly running into problems where dns white-lists have > been causing false negatives in spam. Valid looking headers are being > injected at the beginning of emails which are tripping dns whitelists > (see bel

injected headers are triggering dns whitelists

I've been repeatedly running into problems where dns white-lists have been causing false negatives in spam. Valid looking headers are being injected at the beginning of emails which are tripping dns whitelists (see below). As a result I've been slowly disabling dns whitelist rul

Re: Whitelists in 3.3.0

> McDonald, Dan wrote: >> grep -E score\ RCVD.+- >> /var/lib/spamassassin/updates_spamassassin_org/50_scores.cf | cut -d\ >> -f1-3 > /etc/mail/spamassassin/no-whitelists.cf Nice. Now I just need to decide if I wait for ports to update or just manually install 3.3 -- You try to shape the world

Re: Whitelists in 3.3.0

Daniel J McDonald wrote: > On Fri, 2010-01-29 at 09:18 -0500, Bowie Bailey wrote: > >> McDonald, Dan wrote: >> >>> Please excuse the top-post. This truly brain-damaged mua does not >>> allow me to edit the body. >>> >>> Easiest way

Re: Whitelists in 3.3.0

On Fri, 2010-01-29 at 09:18 -0500, Bowie Bailey wrote: > McDonald, Dan wrote: > > > > Please excuse the top-post. This truly brain-damaged mua does not > > allow me to edit the body. > > > > Easiest way to disable whitelists is: > > > > gre

Re: Whitelists in 3.3.0

McDonald, Dan wrote: > > Please excuse the top-post. This truly brain-damaged mua does not > allow me to edit the body. > > Easiest way to disable whitelists is: > > grep -E score\ RCVD.+- > /var/lib/spamassassin/updates_spamassassin_org/50_scores.cf | cut -d\ > -f1-3

RE: Whitelists in 3.3.0

Please excuse the top-post. This truly brain-damaged mua does not allow me to edit the body. Easiest way to disable whitelists is: grep -E score\ RCVD.+- /var/lib/spamassassin/updates_spamassassin_org/50_scores.cf | cut -d\ -f1-3 > /etc/mail/spamassassin/no-whitelists.cf Sent with G

Whitelists in 3.3.0

What whitelists are enabled in SA 3.3.0 and what's the easiest way to disable them all? -- YOU [humans] NEED TO BELIEVE IN THINGS THAT AREN'T TRUE. HOW ELSE CAN THEY BECOME? --Hogfather

Re: The other side of whitelists - arbitrary blacklists

jdow a écrit : > At least one well respected ninja sort from this list is also a > volunteer SANS Internet Storm Cellar operator. These folks do not seem > to be in the least "inexperienced" in the ways of malware and malware > delivery. That is why I take that diary entry at face value. > maybe

Re: The other side of whitelists - arbitrary blacklists

On 12/22/09 2:49 PM, jdow wrote: I agree he could have included more information than he did without giving away names involved. One piece of wording suggests he is an admin at a box or rack rental place such as rackspace rather than a wire rental place; and, it's customers are meeting with t

Re: The other side of whitelists - arbitrary blacklists

From: "mouss" Sent: Monday, 2009/December/21 15:47 jdow a écrit : http://isc.sans.org/diary.html?storyid=7780 It can be quite frustrating to run an ISP and comply with the often arbitrary, strange, and I suspect contradictory demands of the likes of SORBS and Trend Micro. An ISP Abuse handle

Re: The other side of whitelists - arbitrary blacklists

jdow a écrit : > http://isc.sans.org/diary.html?storyid=7780 > > It can be quite frustrating to run an ISP and comply with the often > arbitrary, strange, and I suspect contradictory demands of the likes > of SORBS and Trend Micro. An ISP Abuse handler vents in this article. > from the text, the

Re: The other side of whitelists - arbitrary blacklists

> On Sun, 20 Dec 2009, jdow wrote: >> http://isc.sans.org/diary.html?storyid=7780 >> >> It can be quite frustrating to run an ISP and comply with the often >> arbitrary, strange, and I suspect contradictory demands of the likes >> of SORBS and Trend Micro. An ISP Abuse handler vents in this article

Re: Whitelists, not directly useful to spamassassin...

> Warren Togami wrote: >> While whitelists are not directly effective (statistically, when >> averaged across a large corpus), whitelists are powerful tools in >> indirect ways including: >> >> * Pushing the score beyond the auto-learn threshold for things li

Re: [sa] Re: Whitelists in SA

On Sun, 20 Dec 2009, jdow wrote: The downside is that this is not "confirmed ham" and "confirmed spam". (nod) Exactly. And that is what is needed to do a masscheck... I wonder how much companies would pay for a part time SpamAssassin honcho who can be trusted (bonded?) and can write SARE-ish

Re: Whitelists in SA

On Sun, 20 Dec 2009, jdow wrote: I'm just a touch naive here; but, it seems to me it should be possible, somehow, to build running spamd daemons, one with the regular rules and one with the mass check rules. There's nothing special about "masscheck rules". Masscheck is just running the curren

Re: Whitelists in SA

From: "Charles Gregory" Sent: Sunday, 2009/December/20 06:20 On Sat, 19 Dec 2009, Daryl C. W. O'Shea wrote: More unfortunately, privacy concerns prevent me from building a useful corpus of ham. Sigh But otherwise such a good idea Can you not trust yourself to use your own ham? You d

Re: The other side of whitelists - arbitrary blacklists

On Sun, 20 Dec 2009, Per Jessen wrote: SORBS would only put you in their DUL listing for anything resembling hosts that are dynamic, AFAIK, also ranges that were "declared" to by dynamic, e.g. in whois info. I once had a range allocated which had previously been declared to be dynamic, and it

Re: Whitelists in SA

On 12/20/2009 09:20 AM, Charles Gregory wrote: On Sat, 19 Dec 2009, Daryl C. W. O'Shea wrote: More unfortunately, privacy concerns prevent me from building a useful corpus of ham. Sigh But otherwise such a good idea Can you not trust yourself to use your own ham? You don't need to provi

Re: Whitelists in SA

On Sat, 19 Dec 2009, Daryl C. W. O'Shea wrote: More unfortunately, privacy concerns prevent me from building a useful corpus of ham. Sigh But otherwise such a good idea Can you not trust yourself to use your own ham? You don't need to provide us with your mail. You can scan your own ma

Re: The other side of whitelists - arbitrary blacklists

Res wrote: > On Sun, 20 Dec 2009, jdow wrote: > >> http://isc.sans.org/diary.html?storyid=7780 >> >> It can be quite frustrating to run an ISP and comply with the often >> arbitrary, strange, and I suspect contradictory demands of the likes >> of SORBS and Trend Micro. An ISP Abuse handler vents

Re: The other side of whitelists - arbitrary blacklists

On Sun, 20 Dec 2009, jdow wrote: http://isc.sans.org/diary.html?storyid=7780 It can be quite frustrating to run an ISP and comply with the often arbitrary, strange, and I suspect contradictory demands of the likes of SORBS and Trend Micro. An ISP Abuse handler vents in this article. SORBS wo

The other side of whitelists - arbitrary blacklists

http://isc.sans.org/diary.html?storyid=7780 It can be quite frustrating to run an ISP and comply with the often arbitrary, strange, and I suspect contradictory demands of the likes of SORBS and Trend Micro. An ISP Abuse handler vents in this article. {^_^}

Re: [sa] Re: Whitelists in SA

On 19/12/2009 5:51 PM, Charles Gregory wrote: > On Fri, 18 Dec 2009, Warren Togami wrote: >> Why wait, when you do relatively simple things to help make it happen? >> http://wiki.apache.org/spamassassin/NightlyMassCheck >> We can more frequently update rules if more people participate in the >> nig

Re: [sa] Re: Whitelists in SA

On Fri, 18 Dec 2009, Warren Togami wrote: Why wait, when you do relatively simple things to help make it happen? http://wiki.apache.org/spamassassin/NightlyMassCheck We can more frequently update rules if more people participate in the nightly masschecks. The current documentation is a bit of a

Re: [sa] Re: Whitelists in SA

On 18/12/2009 5:13 PM, Warren Togami wrote: > On 12/18/2009 04:56 PM, Charles Gregory wrote: >> On Fri, 18 Dec 2009, John Hardin wrote: >>> We hope to get rule scoring and publication much more automated - >>> i.e., if a rule in the sandbox works well based on the automated >>> masschecks, it would

Re: [sa] Re: Whitelists in SA

On 12/18/2009 04:56 PM, Charles Gregory wrote: On Fri, 18 Dec 2009, John Hardin wrote: We hope to get rule scoring and publication much more automated - i.e., if a rule in the sandbox works well based on the automated masschecks, it would be automatically scored and published via sa-update. Mu

Re: [sa] Re: Whitelists in SA

On Fri, 18 Dec 2009, jdow wrote: Perhaps you meant CHAIR and keyboard? ;) I should have guessed you've managed to short circuit the path through your brain. {O,o} <-- Grinning, ducking, and running REAL fast that way> (Thanks for the straight line. {^_-}) (Thinks twice about it) Ou

Re: [sa] Re: Whitelists in SA

From: "Charles Gregory" Sent: Friday, 2009/December/18 13:49 On Fri, 18 Dec 2009, jdow wrote: On Thu, 17 Dec 2009, jdow wrote: Still no changes through the sa-update channel. Is there a time delay in the masscheck results being applied? Yes, there is, Mr. Gregory. It exists between your m

Re: [sa] Re: Whitelists in SA

On Fri, 18 Dec 2009, John Hardin wrote: We hope to get rule scoring and publication much more automated - i.e., if a rule in the sandbox works well based on the automated masschecks, it would be automatically scored and published via sa-update. Music to my ears. I will wait (semi-)patiently. T

Re: [sa] Re: Whitelists in SA

On Fri, 18 Dec 2009, jdow wrote: On Thu, 17 Dec 2009, jdow wrote: Still no changes through the sa-update channel. Is there a time delay in the masscheck results being applied? Yes, there is, Mr. Gregory. It exists between your monitor and your keyboard. There is a one inch gap between those

Re: [sa] Re: Whitelists in SA

On Fri, 18 Dec 2009, Charles Gregory wrote: I recognize, from the existence of such sites as 'rules du jour' that it has long been a practice for SA to release 'core' rule updates very infrequently. But with respect, I question whether that is still a good practice, particularly when an 'issue

Re: [sa] Re: Whitelists in SA

On Fri, 18 Dec 2009, LuKreme wrote: It's already been stayed no changes to 3.2.5 will be made until 3.3 is done, hasn't it? Well, at this point, I respectfully bow, and take a step back, so as not to sound too demanding of our great volunteers (smile), but I believe in another of my posts I p

Re: Whitelists in SA

From: "Charles Gregory" Sent: Friday, 2009/December/18 06:56 On Thu, 17 Dec 2009, jdow wrote: It is a good thing this issue was raised. It led to appropriate mass check runs. I expect that will lead to saner scoring within the SA framework. If not and it bites me, THEN I'll raise the issue ag

Re: Whitelists in SA

On Dec 18, 2009, at 7:56, Charles Gregory wrote: Still no changes through the sa-update channel. Is there a time delay in the masscheck results being applied? It's already been stayed no changes to 3.2.5 will be made until 3.3 is done, hasn't it?

Re: Whitelists in SA

On Fri, 18 Dec 2009, Charles Gregory wrote: On Thu, 17 Dec 2009, jdow wrote: It is a good thing this issue was raised. It led to appropriate mass check runs. I expect that will lead to saner scoring within the SA framework. If not and it bites me, THEN I'll raise the issue again. Does that

Re: Whitelists in SA

On Thu, 17 Dec 2009, jdow wrote: It is a good thing this issue was raised. It led to appropriate mass check runs. I expect that will lead to saner scoring within the SA framework. If not and it bites me, THEN I'll raise the issue again. Does that seem fair? 50_scores.cf:score HABEAS_ACCREDITED_

Re: Whitelists in SA

From: "J.D. Falk" Sent: Thursday, 2009/December/17 11:21 On Dec 16, 2009, at 8:35 AM, LuKreme wrote: The fact is I *AM* their customer. The people writing them checks are not, they're just their funders. Whitelist companies ha to convince admins to use their list. The only way to do that is

Re: Whitelists in SA

On Dec 16, 2009, at 8:35 AM, LuKreme wrote: > The fact is I *AM* their customer. The people writing them checks are not, > they're just their funders. Whitelist companies ha to convince admins to use > their list. The only way to do that is to have really really really high > quality lists that

Re: Whitelists, not directly useful to spamassassin...

Very interesting data indeed -- and a testament to the accuracy of the SpamAssassin rules weighting process. On Dec 16, 2009, at 4:10 PM, Warren Togami wrote: > While whitelists are not directly effective (statistically, when averaged > across a large corpus), whitelists are powerful to

Re: Whitelists, not directly useful to spamassassin...

On 12/17/2009 11:27 AM, Jason Bertoch wrote: If whitelists are to be enabled by default, I believe their score should be moved considerably more toward zero. /Jason I don't necessarily disagree with this desire, as now we know the whitelists actually are making almost zero differen

  1   2   >