I became aware that just about all of 64.115.0.0/16, a network that I (among others) run, has been listed as "dynamic ip space" in sorbs as of April 2nd. On April 6th I sent my first email (via web-form) to sorbs telling them they were mistaken. Finding no documentation on how they deem networks "dynamic" or "static" I changed my rDNS scheme from ppp-64-115-x-x to 64-115-x-x Note to all: "ppp" in no way signifies dial-up; we run ppp over almost every circuit we have -- from dialup to OC12, to Ethernet and ATM. I also stated how all of our network was scanned twice a day for open-relay mail servers. Being a bigish ISP, we are _huge_ on our abuse policies, and our abuse bucket [usually] has only memories of tumbleweed blowing by. On april 10th I again wrote, only to be ignored further. Yesterday, April 13th, One of my customers opened a trouble ticket stating that he had successfully received a response from SORBS, and had forwarded me the conversation. I sent an email to duhl@sorbs.net (the author of the email) quoting what they had written one of my customers. They said to my customer that I had to either provide custom reverse DNS for each customer who was not dynamic, or I had to provide sorbs with POCs for all my non-dynamic customers. I stated how this was absurd, and that there was already a functioning medium for this task -- rwhois. In this same email, I also stated: 1. exactly which 64.115 networks were dynamic 2. that to prevent further hysteria, I had changed the reverse dns from ppp-64-115-x-x to static-64-115-x-x and dynamic-64-115-x-x, respectively. 3. their blindness was very unprofessional, deeming SORBS a Worthless Project ran by Ignorant Half-Wits As of this date I have not received a response from anyone at sorbs, and do not expect one. Our support crew is overwhelmed with upset customers who cant send email to their associates. Our only response to them is that we have tried to resolve the issue, but could not, and that the remote ISP should stop using sorbs. I am upset that they blindly blacklisted most of 64.115.0.0/16 because some of the reverse dns was generic. 64.115.47.0/25, for example, hasnt very much generic rDNS at all, but was blacklisted just the same. I hope all stop using SORBS. I especially hope Mr. Vixie reconsiders his helpfulness to such a harmful organization. For google: <a href="http://www.sorbs.net">A Worthless Project</a> Jeremy Kister www.jeremykister.com/jeremy/ Argus: The World's Most Advanced Monitoring Software: http://argus.tcp4me.com
On Wed, 14 Apr 2004, Jeremy Kister wrote:
telling them they were mistaken. Finding no documentation on how they deem networks "dynamic" or "static" I changed my rDNS scheme from ppp-64-115-x-x to 64-115-x-x Note to all: "ppp" in no way signifies dial-up; we run ppp over almost every circuit we have -- from dialup to OC12, to Ethernet and ATM.
I think you'll find it's pretty commonly assumed (not just by certain DNSBLs) that "script generated" DNS is dynamic. Prepending it with ppp- makes the assumption seem to be even more of a slam dunk. Just to pick an example, dummy-smtpd assumes that any host that matches /\d{1,3}.\d{1,3}.\d{1,3}/ is "dynamic host with with script-generated rDNS name". I think the feeling is, "if you care enough about the system that it should be a legitimate mail server, it ought to have 'unique' rDNS." rDNS matching what it HELO's as is nice too.
I also stated how all of our network was scanned twice a day for open-relay mail servers. Being a bigish ISP, we are _huge_ on our abuse policies, and our abuse bucket [usually] has only memories of tumbleweed blowing by.
Irrelevant. Unless you're doing full port scans, you're not going to find the open proxies. Open relays are old school for spamming. Open and stealth proxies are the current methods. Are you looking for HTTP Connect proxies on 65506, 6588, 48669, etc.? How about the socks5 proxy on 64.115.63.248:35762, which BTW is static-64-115-63-248.isp.broadviewnet.net.
2. that to prevent further hysteria, I had changed the reverse dns from ppp-64-115-x-x to static-64-115-x-x and dynamic-64-115-x-x, respectively.
That's better than the original. Would you really expect people in today's spam overrun climate to accept email from a system identified as ppp-64-115-x-x.isp.broadviewnet.net? I don't know about you, but that just screams dialup to me. 64-115-x-x.isp.broadviewnet.net isn't much better.
3. their blindness was very unprofessional, deeming SORBS a Worthless Project ran by Ignorant Half-Wits
Your thinking that won't change the minds of thousands of systems blocking millions of spams with their list.
As of this date I have not received a response from anyone at sorbs, and do not expect one. Our support crew is overwhelmed with upset customers who cant send email to their associates. Our only response to them is that we have tried to resolve the issue, but could not, and that the remote ISP should stop using sorbs.
Did it occur to you to setup reverse DNS to match forward DNS? Are these customers running DNS that says "our MX records are 64-115-x-x.isp.broadviewnet.net and 64-115-x-y.isp.broadviewnet.net"? I really doubt it. Having them smarthost their mail through your server (it's not 64-115-x-x.isp.broadviewnet.net too, is it?) would also be a no-brainer immediate solution until you can work things out with SORBS. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Jeremy Kister wrote: [... giant snip ...] We are a former user of SORBS. Our issue was not that of dynamic IPs, but rather their spamtrap listings. A few weeks ago, at least two of Comcast's legitimate mail servers was blacklisted. As Comcast has a majority of the cable service in our area, we have a lot of users that use Comcast as their ISP. Needless to say, listing several of Comcast's prominent mail servers caused our mailers to reject the mail with the SORBS bounce reply. We have since ceased using SORBS and cured the Comcast problem, as well as a couple of other unrelated (and previously unreported) problems. But I have/had a considerable degree of respect for SORBS, and as part of our abuse department, I dutifully report all of our reported spam deliveries to SpamCop. When SpamCop does it's analysis and notes that the spam in question was listed in SORBS, I now cringe. It would have been blocked. So currently I'm considering asking for partial zone transfers of some of their blocks (our mailer doesn't discriminate against the DNS return address being 127.0.0.x or 127.0.0.y, a hit is a hit) and omitting at least the 'spamtrap' portion (for the same reason we don't use SpamCop directly -- the knee-jerk false positives outweigh the real hits to upset a considerable portion of our user base). From the opposite standpoint in acting on spam that originates in our domain, everything to date has been a compromised machine and/or virus. If SpamCop lists our registered mailers, I can at least respond from the abuse address that the problem has been corrected and there are no further interruptions in our mail service. I can only imagine the problems if you end up blacklisted by SORBS if their response time and effort is really this low for cleaning up their lists. While the big ISPs may not act immediately (or at all) on compromised hosts with trojan proxies, we do keep a tight lid on it (and block SMTP from end-users at egress, but that is another discussion). Jeff
Jeff Kell wrote:
Jeremy Kister wrote: [... giant snip ...]
We are a former user of SORBS. Our issue was not that of dynamic IPs, but rather their spamtrap listings. A few weeks ago, at least two of Comcast's legitimate mail servers was blacklisted. As Comcast has a majority of the cable service in our area, we have a lot of users that use Comcast as their ISP. Needless to say, listing several of Comcast's prominent mail servers caused our mailers to reject the mail with the SORBS bounce reply. We have since ceased using SORBS and cured the Comcast problem, as well as a couple of other unrelated (and previously unreported) problems.
I do recommend anyone using the complete DB to whitelist any major mailservers 'near' them. If you can't do this I recomend you use tagging and/or use 'safe.dnsbl.sorbs.net' which doesn't contain the spam DB, but does contain all other DBs.
But I have/had a considerable degree of respect for SORBS, and as part of our abuse department, I dutifully report all of our reported spam deliveries to SpamCop. When SpamCop does it's analysis and notes that the spam in question was listed in SORBS, I now cringe. It would have been blocked.
So currently I'm considering asking for partial zone transfers of some of their blocks (our mailer doesn't discriminate against the DNS return address being 127.0.0.x or 127.0.0.y, a hit is a hit) and omitting at least the 'spamtrap' portion (for the same reason we don't use SpamCop directly -- the knee-jerk false positives outweigh the real hits to upset a considerable portion of our user base).
safe.dnsbl.sorbs.net - available on all the public DNS servers and by using the zonefiles.
From the opposite standpoint in acting on spam that originates in our domain, everything to date has been a compromised machine and/or virus. If SpamCop lists our registered mailers, I can at least respond from the abuse address that the problem has been corrected and there are no further interruptions in our mail service. I can only imagine the problems if you end up blacklisted by SORBS if their response time and effort is really this low for cleaning up their lists. While the big ISPs may not act immediately (or at all) on compromised hosts with trojan proxies, we do keep a tight lid on it (and block SMTP from end-users at egress, but that is another discussion).
You will note my post before Christmas about the up and coming whitelisting mechanism - I am still collecting details for people wanting to use it - unfortunately for a variety of reasons the whitelisting mechanism is still not ready to go public. Yours Matthew
Matthew Sullivan wrote:
<snip> You will note my post before Christmas about the up and coming whitelisting mechanism - I am still collecting details for people wanting to use it - unfortunately for a variety of reasons the whitelisting mechanism is still not ready to go public.
Yours
Matthew
Speaking about whitelisting....comp.mail.sendmail google link...Reproduced below.. http://groups.google.com/groups?q=sendmail+whitelist+dns&hl=en&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&selm=ac4e9990.0311250514.65c4e614%40posting.google.com&rnum=9 Hello all, I was wondering if any of you use *dns* lists for whitelisting purposes. I have found a couple of whitelists online (bondedsenders) and their m4 was far from satisfactory. I have found that the below (trivial) modification to dnsblaccess.m4 allows me to specify that a specific return value from the access map will *whitelist* the connection. Has anyone gone in this direction before? Joe M --- dnsblaccess.m4 Sun May 19 17:30:06 2002 +++ /usr/lib/*sendmail*-cf/hack/dnsblaccess.m4 Tue Nov 18 08:03:14 2003 @@ -90,5 +90,6 @@ R<ERROR:$-.$-.$-:$+> $* $#error $@ $1.$2.$3 $: $4 R<ERROR:$+> $* $#error $: $1 R<DISCARD> $* $#discard $: discard +R<*WHITELIST*> $* $#OK R<$*> $* $#error $@ 5.7.1 $: _EDNSBL_MSG_ divert(-1)
On Thu, 15 Apr 2004, Joe Maimon wrote:
Speaking about whitelisting....comp.mail.sendmail google link...Reproduced below..
ok...you've now drifted way off-topic for NANOG IMO. This belongs in spam-tools or spam-l.
I was wondering if any of you use *dns* lists for whitelisting purposes.
Yes...for several years.
I have found a couple of whitelists online (bondedsenders) and their m4 was far from satisfactory.
Why? I came up with essentially the same rules (modified dnsbl.m4 to support DNSWLs) as them back in 2001 and have been using it ever since at multiple sites with privately maintained DNSWLs. For that usage, it works fine. If you want to use it with someone else's DNSWL and they have different 127.x.y.z return codes for different whitelisting reasons, sure, it's too primitive, and you'll likely need to modify enhdnsbl.m4 to make your own enhdnswl.m4, or do something similar. Why the sendmail folks have chosen to support DNSBLs but not DNSWLs, is still a mystery to me...but this has little to do with network operations. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
In case you didn't know, SORBS admins do populate this list from time to time, so I might be worth going through a few things... Jeremy Kister wrote:
I became aware that just about all of 64.115.0.0/16, a network that I (among others) run, has been listed as "dynamic ip space" in sorbs as of April 2nd. On April 6th I sent my first email (via web-form) to sorbs telling them they were mistaken.
What address did you use? What tracking number did you get?
Finding no documentation on how they deem networks "dynamic" or "static" I changed my rDNS scheme from ppp-64-115-x-x to 64-115-x-x Note to all: "ppp" in no way signifies dial-up; we run ppp over almost every circuit we have -- from dialup to OC12, to Ethernet and ATM.
I also stated how all of our network was scanned twice a day for open-relay mail servers. Being a bigish ISP, we are _huge_ on our abuse policies, and our abuse bucket [usually] has only memories of tumbleweed blowing by.
On april 10th I again wrote, only to be ignored further.
Again, tracking number please? Address you used? The reason I am asking is I only fine one ticket from the address you posted from.
Yesterday, April 13th, One of my customers opened a trouble ticket stating that he had successfully received a response from SORBS, and had forwarded me the conversation. I sent an email to duhl@sorbs.net (the author of the email) quoting what they had written one of my customers. They said to my customer that I had to either provide custom reverse DNS for each customer who was not dynamic, or I had to provide sorbs with POCs for all my non-dynamic customers. I stated how this was absurd, and that there was already a functioning medium for this task -- rwhois.
In this same email, I also stated: 1. exactly which 64.115 networks were dynamic
I gather then you are not actually 'abuse@broadviewnet.net' then (see below)...
2. that to prevent further hysteria, I had changed the reverse dns from ppp-64-115-x-x to static-64-115-x-x and dynamic-64-115-x-x, respectively.
And yet the mail I received from 'abuse@broadviewnet.net' - which I found oddly worded for a professional - stated there are no dynamic blocks in the entire /16.... Which is it?
3. their blindness was very unprofessional, deeming SORBS a Worthless Project ran by Ignorant Half-Wits
..who are unpaid, for both answering tickets, and the time in dealing with obnoxious people who threaten various amounts of legal action... not to mention the cost involved in running the services to both the owner and those who generously give resourses to the SORBS project.... Actually the instructions I have given to those answering the DUHL tickets are that if there is no rDNS or rDNS that may indicate the address space is not static then they are to accept requests only from the confirmed RIR PoC... This is specifically because every man and his dog come to us explaining how their part of the net is not dynamic.
As of this date I have not received a response from anyone at sorbs, and do not expect one. Our support crew is overwhelmed with upset customers who cant send email to their associates. Our only response to them is that we have tried to resolve the issue, but could not, and that the remote ISP should stop using sorbs.
Funny the person logging the first ticket also said that...
I am upset that they blindly blacklisted most of 64.115.0.0/16 because some of the reverse dns was generic. 64.115.47.0/25, for example, hasnt very much generic rDNS at all, but was blacklisted just the same.
It was blacklisted because of a tipoff from someone from who is widely known at trusted. I checked up on the tip, and in this case I either didn't look close enough, or your rDNS has changed significantly for the network....
I hope all stop using SORBS. I especially hope Mr. Vixie reconsiders his helpfulness to such a harmful organization.
Now I'm not going to reveal details of the actual comments in the tickets unless you grant your permission and indicate which ticket(s) are yours... I will say though as there are no indications of any dynamic ranges in any of the tickets logged, I spent all day yesturday going through the rDNS logs for the entire /16 (yes we do go through the entire dump), and had I not spent until the early hours of the morning this morning tracking a DoS attack, and then most fo the day in my dayjob I would have already have fixed this... but I guess by your post that doesn't matter. Yours Matthew
Jeremy Kister wrote:
I became aware that just about all of 64.115.0.0/16
In this same email, I also stated: 1. exactly which 64.115 networks were dynamic
Ok now I have settled into another night of fixing things... I see no mails from yourself in the ticketting system which indicate dynamic ranges - all seem to just demand delisting of all the blocking the /16 statin gthey are all static.... (I have not looked at tickets owned by the other SORBS staff) In your mail you indicated some of the rDNS is clear in that it indicates what address ranges are dynamic, and you also say above you have stated them - so I have removed the /16, now lets see a little help and give us this list, and I will then be able to list them.... otherwise I will have to go back to analysing the rDNS dump and guessing which are which again. Yours Mat
participants (5)
-
Jeff Kell -
Jeremy Kister -
jlewis＠lewis.org -
Joe Maimon -
Matthew Sullivan