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/
