Re: URIBL Notice
On Fri, 2010-03-12 at 07:48 -0800, Ray Dzek wrote: I just received the dreaded URIBL “You send us to many DNS queries” notice. This is fine. We have been growing and I am sure our queries have gone up. But when looking at their data feed service options the first thing I noticed was that there is no fee structure. I don’t know about you, but that is always a red flag in my world. Before I even get past the first paragraph it already smells like a “shakedown”. But… My real question is how badly is my SA environment going to be impacted by turning URIBL off? What increase in spam should I expect? Ray You'll see some difference but from experience it lets through more than it blocks and is a bit of a 'shutting the stable door after the horse has bolted' kind of list. There is nothing to stop you setting up a simple BIND server and creating your own local uri based block list customised to your own needs and based on the links you most frequently see. I've done it and I'm sure plenty of others have too.
Re: URIBL Notice
On 12/03/10 15:48, Ray Dzek wrote: I just received the dreaded URIBL “You send us to many DNS queries” notice. This is fine. We have been growing and I am sure our queries have gone up. But when looking at their data feed service options the first thing I noticed was that there is no fee structure. I don’t know about you, but that is always a red flag in my world. Before I even get past the first paragraph it already smells like a “shakedown”. Did you actually go through the effort to create a URIBL account and go to the process of requesting a feed? There is a price structure; it's based on how often you want to do the rsync and how many users you have and it's all shown on that page IIRC. But… My real question is how badly is my SA environment going to be impacted by turning URIBL off? What increase in spam should I expect? I actually subscribe to URIBL and reject based on hits to the URIBL black list at the SMTP level. 214-2.0.0 169 spamd-connect=3985 33.17% 214-2.0.0 170 spamd-connect-error=0 0.00% 214-2.0.0 171 spamd-reject=559 4.65% 214-2.0.0 172 spamd-sender-marked-spam=9 0.07% 214-2.0.0 173 spamd-tag=100 0.83% So 559 reject by SA as score 10 and just 100 tagged with score =5 10 214-2.0.0 178 uri-bl=731 6.09% Whereas I've rejected 731 with URIBL. Draw your own conclusions from that. I find it URIBL works very well and if you subscribe you get access to a number of extra lists (e.g. URIBL Gold etc.) which also adds extra value and catch rate. Hope that helps. Kind regards, Steve.
Re: URIBL Notice
On 2010-03-12 16:48, Ray Dzek wrote: I just received the dreaded URIBL You send us to many DNS queries notice. This is fine. We have been growing and I am sure our queries have gone up. But when looking at their data feed service options the first thing I noticed was that there is no fee structure. I don't know about you, but that is always a red flag in my world. Before I even get past the first paragraph it already smells like a shakedown. But... My real question is how badly is my SA environment going to be impacted by turning URIBL off? What increase in spam should I expect? These stats are for small trap box which only accepts mail from bots and rejects stuff listed by DNSWL and other public WLs. Since midnight CET- These are only URI BL tats - so you woun't see other dnsbls like Spamcop, etc. Some zones may sound familiar - others are private. RANKRULE NAME COUNT %OFMAIL %OFSPAM %OFHAM 1URI_IN_MSG 4794393.48 95.22 53.92 2ANY_URIBL_COM 4646088.38 92.270.09 3URIBL_BLACK 4518685.95 89.740.00 4ANY_SPAMHAUS4229980.46 84.010.05 5URIBL_DBL 3955575.24 78.560.00 6HTML_MESSAGE3940576.83 78.26 44.46 7URIBL_SBL 3868073.58 76.820.00 8CM_URI_DNSBL3863673.49 76.730.00 9AXB_BLACK_NSIP 3843973.12 76.340.00 10URIBL_SPAMEATINGMONKEY_RED 3825072.76 75.970.00 11ANY_SURBL 3374264.24 67.011.31 12URIBL_SC_SWINOG 3326563.28 66.070.00 13URIBL_IVMURI3298762.75 65.520.00 14RDNS_NONE 3173362.82 63.02 58.11 15URIBL_JP_SURBL 3040857.84 60.390.00 16URIBL_SPAMEATINGMONKEY_BLACK3033857.71 60.250.00 17URIBL_DRS_BLACK 3027257.58 60.120.00 18MIME_HTML_ONLY 2948556.13 58.561.08 19URIBL_WS_SURBL 2895955.14 57.521.31 20URIBL_AB_SURBL 2720051.74 54.020.00 21AXB_BLACK_NS2507647.70 49.800.00 22HK_NAME_DRUGS 1602730.49 31.830.00 23RDNS_DYNAMIC1333426.09 26.48 17.25 24URIBL_OB_SURBL 1270124.16 25.230.00 25FSL_HELO_NON_FQDN_1 1268125.47 25.19 31.89
Re: URIBL Notice
Yet Another Ninja wrote: These stats are for small trap box which only accepts mail from bots and rejects stuff listed by DNSWL and other public WLs. Since midnight CET- These are only URI BL tats - so you woun't see other dnsbls like Spamcop, etc. Alex, about those stats... (1) Do those include spams sent to non-existent users (i.e. dictionary attack spams)? (2) Was pre-filtering done, such as collecting stats only on messages which made it past zen.spamhaus.org (etc.)? Or was there no pre-filtering? -- Rob McEwen http://dnsbl.invaluement.com/ r...@invaluement.com +1 (478) 475-9032
Re: URIBL Notice
On 2010-03-12 20:23, Rob McEwen wrote: Yet Another Ninja wrote: These stats are for small trap box which only accepts mail from bots and rejects stuff listed by DNSWL and other public WLs. Since midnight CET- These are only URI BL tats - so you woun't see other dnsbls like Spamcop, etc. Alex, about those stats... (1) Do those include spams sent to non-existent users (i.e. dictionary attack spams)? there are no users - its trap domains which have never had any real users - ever. (2) Was pre-filtering done, such as collecting stats only on messages which made it past zen.spamhaus.org (etc.)? Or was there no pre-filtering? no prefiltering except rejecting potential bounces and stuff leaking from whatever may be on DNSWL and a coupleof other WLs.
Re: URIBL Notice
Yet Another Ninja wrote: there are no users - its trap domains which have never had any real users - ever. no prefiltering except rejecting potential bounces and stuff leaking from whatever may be on DNSWL and a coupleof other WLs. Alex, Your stats are certainly valuable and illustrative... but not reflective of the stats one would see in a MOST real world mail streams where: (A) the spams were sent to actual users (which would be a distinctively different mix of spams compared to a pure honeypot stream of spams--for example, there'd be more can-spam spam/snowshoe spam in the real user mix, as well as less spam easily block by other techniques) --AND-- (B) where most of the messages have been prefiltered by FP-safe sender IP blacklists like Zen (which would then also alter the makeup of the spam stream--this would cause a lowered percentage of the easy stuff left over for the URI lists to process... and a higher percentage of the hard stuff left for the URI lists to process). Those two things would alter those stats dramatically and would paint a very different picture for some of those uri blacklists you compared. BTW - don't get me wrong... URIBL would still fare VERY well either way--so don't think I'm saying or implying ANYTHING bad about URIBL! (or anything bad about ANY other list) (fwiw) -- Rob McEwen http://dnsbl.invaluement.com/ r...@invaluement.com +1 (478) 475-9032
Re: URIBL Notice
On 2010-03-13 0:50, Rob McEwen wrote: Yet Another Ninja wrote: there are no users - its trap domains which have never had any real users - ever. no prefiltering except rejecting potential bounces and stuff leaking from whatever may be on DNSWL and a coupleof other WLs. Alex, Your stats are certainly valuable and illustrative... but not reflective of the stats one would see in a MOST real world mail streams where: was not the point, as your real world is yours, and not somebody elses. I specified what those stats showed.. only bot spam. There is no ham, no users, no ESP traffic, no bounces, just trash /dev/null
Re: URIBL Notice
On Fri, 2010-03-12 at 18:50 -0500, Rob McEwen wrote:
Your stats are certainly valuable and illustrative... but not reflective
of the stats one would see in a MOST real world mail streams where:
(A) the spams were sent to actual users (which would be a distinctively
different mix of spams compared to a pure honeypot stream of spams [...]
Just for comparison, below are some stats gathered quickly from 2
different and entirely unrelated systems. Real mail stream, real users
only, no traps.
RANKRULE NAME COUNT %OFMAIL %OFSPAM %OFHAM
--
11URIBL_BLACK 120262.73 63.940.00
8URIBL_BLACK 57241.12 78.360.00
Unfortunately, both of these systems are still 3.2.5, so there is no
util_rb_3tld love either, which would drive up the %spam numbers quite a
bit.
Oh, and there are some custom rules in place, which take the highest
ranks in these lists, pushing URIBL and all other stock rules down. So
don't base on the rank...
--
char *t=\10pse\0r\0dtu...@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: URIBL Notice
On Mar 12, 2010, at 6:17 PM, Karsten Bräckelmann wrote: Just for comparison, below are some stats gathered quickly from 2 different and entirely unrelated systems. Real mail stream, real users only, no traps. Here are mine from yesterday while we are at it: -- RANKRULE NAME COUNT %OFMAIL %OFSPAM %OFHAM -- 1 URIBL_INVALUEMENT 1803736.19 78.780.81 2 RCVD_IN_INVALUEMENT 1728834.44 75.510.31 3 HTML_MESSAGE1620876.97 70.80 82.09 4 BAYES_991542130.57 67.360.01 5 RCVD_IN_JMF_BL 1464529.65 63.971.14 6 URIBL_BLACK 1393428.17 60.861.00 7 RCVD_IN_INVALUEMENT24 1338226.57 58.450.07 8 MIME_HTML_ONLY 1050429.07 45.88 15.11 9 URIBL_JP_SURBL 836416.59 36.530.02 10 RCVD_IN_SORBS_HTTP 813621.39 35.549.63 Real users.Lots and lots of RBL greylisting in front of it. Chris - Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 -A stupidity tax Hubris Communications Inc www.hubris.net -
Re: URIBL Notice
On Sat, 2010-03-13 at 01:17 +0100, Karsten Bräckelmann wrote:
RANKRULE NAME COUNT %OFMAIL %OFSPAM %OFHAM
--
8 URIBL_BLACK 57241.12 78.360.00
Unfortunately, both of these systems are still 3.2.5, so there is no
util_rb_3tld love either, which would drive up the %spam numbers quite a
bit.
Oh, and there are some custom rules in place, which take the highest
ranks in these lists, pushing URIBL and all other stock rules down. So
don't base on the rank...
To substantiate this: Bayes_99, Razor (3 small rules, optional in stock
SA). Plus 3 other custom rules. URIBL.
--
char *t=\10pse\0r\0dtu...@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; }}}
