Alright, time for me to jump in here with my 0.02. When a high amount of connections are seen from an IP, I run that against all spam databases to see if it is listed. Often times, during that, I will see additional IP addresses in the same C class block. If after checking, I decide it is ripe for blocking, I use a minimum 3 10% rule. If 3 of IPs within a block are known to send spam, and the IPs are defined within a block and represent 10% of the block, the block is blocked.
Example, the following are seen: (Example only.) 192.168.0.11 192.168.0.12 192.168.0.22 192.168.0.25 192.168.0.26 192.168.0.41 192.168.0.45 192.168.0.46 192.168.0.95 192.168.0.98 192.168.0.105 192.168.0.106 192.168.0.111 192.168.0.185 I will block 192.168.0.0/25 because there are over 3 IPs known to spam in that block, and it is clearly definable. However, I will not block the entire C class just for the one IP in the upper half of the C class. If needed, I will just block that IP. Another Example. 192.168.0.55 192.168.0.133 192.168.0.205 Since the only block those 3 have in common is the entire class C, and since they only represent just over 1%, I will block them individually. John Tolmachoff Engineer/Consultant/Owner eServices For You > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:IMail_Forum- > [EMAIL PROTECTED] On Behalf Of David Maggard > Sent: Tuesday, December 30, 2003 2:28 PM > To: [EMAIL PROTECTED] > Subject: Re: [IMail Forum] Blocking spam > > I am sorry but this is like finding that a bomb sent by the unibomber was > sent from LA and thus deciding that you will throw away all mail sent from > LA. > It is EASY to lookup who owns(or is responsible) for a specific IP, and > thus > contact them about the spam, which you seem to indicate you DON'T bother > doing. > If after contact they do nothing THEN block their range. > You say "the operator of the Class C has not policed his clients, and now > he > pays", but if he isn't notified about the spam then how can he police it? > By not at least contacting the owner of the IP you are potentially > allowing > a spammer to continue operations, and thus becoming an unwitting > accomplice. > > Why not take your logic one step further and block ALL internet traffic > when > you receive spam? > > I admit that there are ISPs that allow this to continue either due to > lazyness or greed, but you shouldn't "throw the baby out with the > bathwater". > > > > ----- Original Message ----- > From: "Len Conrad" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, December 30, 2003 10:35 AM > Subject: Re: [IMail Forum] Blocking spam > > > > > > >But you do that only after confirming the entire class C belongs to the > > >same organization, right? > > > > nope. > > > > >We have a small subset of a class C (.240-.255) I'd be grumpy if my > > >e-mail got thrown away > > > > I don't throw away mail, I reject it. > > > > >because a mail admin once upon a time > > > > > > >got spammed by a different sub-set of the same class C > > > > ... is a very good predictor of the future behavior > > > > >, and decided that everyone there must be a bad guy.. > > > > wrong. We KNOW we got abused by some IPs in a Class C. We don't know > (or > > care) about the other IPs in that ClassC, but the operator of the Class > C > > has not policed his clients, and now he pays. We fixed our problem by > > passing it back to the Class C owner. > > > > If you moved into a bad neighborhood, that's your problem, not mine. > There > > are 16,777,216 Class Cs to be un/lucky with (yeah, I know all aren't > > available). > > > > In practice, the policy is not really the problem you imagine it to be. > > It's accurate and effective. > > > > Automatic blocking (by IMgate advanced) requires: > > > > 1) have no PTR, (aka "Welcome to My Hell"), and > > > > 2) send some volume of msgs to unknown users from one IP and/or from a > > number of IPs in the Class C. > > > > For those of you running low-volume servers, the nature of spam today, > seen > > at high-volumes MXs, is predominantly huge volumes of mail sent to > unknown > > users (and often from forged senders), "shot-gunning", a behavior that > is > a > > very accurate, reliable indication of abuse (no need to scrutinize the > msg > > contents). If 5 or 10 PTR-less IPs in a ClassC are sending volumes of > msg > > to unknown users, boom!, that's one more spewing ClassC down the tubes. > > > > Some hard numbers, rejects since midnight today, one Florida ISP: > > > > 6985 ACL mta_clients_dict <<< IPs and ClassC auto-blocked for > doing ... > > 7410 SMTP Exceeded Hard Error Limit after RCPT > > 8217 RBL bl.spamcop.net > > 8450 SMTP Exceeded Hard Error Limit after DATA > > 14208 ACL to_relay_recipients unknown recipient <<< .... this > > ============================ > > 67236 TOTAL > > > > The _dict filter (dictionary) which runs the AFTER known_recipients > filter, > > meaning these are _dict-rejected msgs to our KNOWN users, and would have > > been accepted had we not harvested the PTR-less IPs into the _dict > filter. > > > > Above is to be compared with a total of 12K msgs accepted for the same > > period (but that's in and out, while the rejects are for inbound > > only). yep, it's bad: > > > > Grand Totals > > ------------ > > messages > > > > 12235 delivered > > 7 forwarded > > 87 deferred (231 deferrals) > > 114 bounced > > 54574 rejected (81%) <<<<< > > > > If one looks at the reject reports, many of the PTR-less auto-blocked > > addresses now have PTRs, but they are still spammers: > > > > Client host rejected: ACL mta_clients_dict_classc (total: 4244) > > 165 kdlaj9023jkla.com > > 154 primaryoffers.com > > 130 erlaok.com > > 119 egoldsavings.net > > 96 moneyholdem.com > > 90 rbo01.com > > 63 mobd01.com > > 62 qualitypro.net > > 49 64.191.76.12 > > 48 64.70.17.67 > > 48 64.70.17.75 > > 48 64.70.17.77 > > 47 218.80.65.68 > > 46 gof01.com > > 44 64.70.17.71 > > 43 218.80.65.169 > > 41 64.70.17.74 > > 41 picklepatches.com > > 40 greatwebads.com > > 37 beeperjack.com > > 35 savingsnotice.com > > 34 203.208.248.223 > > 34 203.208.248.239 > > 33 64.191.76.11 > > 33 203.208.248.207 > > 33 211.144.32.175 > > > > Client host rejected: ACL mta_clients_dict_ip (total: 3117) > > 299 69.6.51.5 > > 162 211.154.103.13 > > 151 69.6.51.4 > > 91 69.6.51.2 > > 90 yourbigvote.com > > 69 69.6.51.3 > > 67 emsemail.biz > > 57 64.239.182.80 > > 45 gof01.com > > 44 206.112.88.231 > > 39 dailyripple.com > > 34 203.208.248.31 > > 33 219.238.200.68 > > 30 66.163.228.5 > > 30 218.107.189.167 > > 25 69.10.154.202 > > 25 ediets.com > > 24 64.211.50.33 > > 24 205.138.96.49 > > 24 206.112.88.235 > > 23 12.32.40.151 > > 23 200.30.166.28 > > 23 205.138.96.45 > > 20 4.23.173.56 > > 20 jupiterdiscount.com > > > > But I said these _dict filters are for PTR-less abusers?? How come some > > above have PTR hostnames? > > > > The PTR addresses spammed our unknown users BEFORE the IPs got a PTR. > But > > they remain convicted by their previous, PTR-less behavior of sending > lots > > of msgs to unknown users. > > > > At this ISP, the _dict filter has 15203 lines in it (some blocks are > A.B.C, > > some are A.B.C.D), and is updated several times/day based on today's > > PTR-less spammers. > > > > Len > > > > _____________________________________________________________________ > > http://MenAndMice.com/DNS-training : London; San Jose; Orlando; Chicago > > http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of > sites > > > > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > > List Archive: http://www.mail- > archive.com/imail_forum%40list.ipswitch.com/ > > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > > > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
