Re: [mailop] SORBS Closing.
Nothing will *need* to be done.SORBS *should* be removed from all configurations at the earliest opportunity.SORBS will be shut down properly with the DNS servers and zones returning delagation and empty zones for multiple years (should be 10+.. but that depends on whether Proofpoint exists in 10 years… just like any other company.)Michelle Sullivanhttp://www.mhix.org/If we don't find a way out of this soon, I'm gonna lose it. Lose it... It means go crazy, nuts, insane, bonzo, no longer in possession of ones faculties, three fries short of a Happy Meal, wacko!On 5 Jun 2024, at 18:14, Frido Otten wrote:
A little heads-up from the MailOp mailinglist.
So is there anything that needs to be done to prevent false
positives happening right after the shutdown?
Doorgestuurd bericht
Onderwerp:
[mailop] SORBS Closing.
Datum:
Wed, 05 Jun 2024 10:36:58 +1000
Van:
Michelle Sullivan via mailop
Antwoord-naar:
Michelle Sullivan
Aan:
mailop
For those that haven't heard. Proofpoint is retiring SORBS
effective immediately(ish).
Zones will be emptied shortly and within a few weeks the SORBS
domain will be parked on dedicated "decommissioning" servers.
I am being made redundant as part of the shutdown and my last day
will be 30th June 2024. I will be looking for new positions
following that.
I would like to thank all the SORBS supporters over the years and
Proofpoint for keeping it going for the community for the last 13
years.
Best regards,
Michelle Sullivan
SORBS.
--
Michelle Sullivan
http://www.mhix.org/
___
mailop mailing list
mai...@mailop.org
https://list.mailop.org/listinfo/mailop
Re: Turning off queries to SORBS
Bill Cole wrote: On 28 Jan 2016, at 8:54, Michelle Sullivan wrote: [...] Only the first is currently found in a the collection of authoritative nameservers for dnsbl.sorbs.net, but all of them have symmetric PTR/A records, implying that they aren't some sort of poisoning artifact. Also, the last 3 are in small blocks allocated by SoftLayer to GFI Software, the former owner of SORBS. Where do you see GFI? Nothing should show GFI (all the SL stuff is owned by Proofpoint) Tell that to SL, e.g.: $ /opt/local/bin/whois 174.36.198.233 [... ARIN record elided ...] Found a referral to rwhois.softlayer.com:4321. %rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network Solutions, Inc. V-1.5.9.6) network:Class-Name:network network:ID:NETBLK-SOFTLAYER.174.36.192.0/18 network:Auth-Area:174.36.192.0/18 network:Network-Name:SOFTLAYER-174.36.192.0 network:IP-Network:174.36.198.232/30 network:IP-Network-Block:174.36.198.232-174.36.198.235 network:Organization;I:GFI Software Hehe... out of date rwhois server... you expect anything else? :P (GFI were out of the picture 1 Jul 2011...! ) -- Michelle Sullivan http://www.mhix.org/
Re: Turning off queries to SORBS
Very old thread I know, but have been busy elsewhere... Bill Cole wrote: > > The SOA and 13 in-zone NS records for dnsbl.sorbs.net both have 1-day > TTL's, while the A records for the rbldns$x.sorbs.net names to which > the NS records point have 10-minute TTL's and the IPs those names > resolves to do change, although not every 10 minutes. The sorbs.net > serial is 2015050602, implying that the NS records may have been > stable for a week but that there were 2 or three different rounds of > changes on May 6. Currently, 11 of the 13 NS's for the dnsbl zone are > responding to me, sending back 7 different zone serial numbers between > them, using epoch timestamps spread across 1:02:32. That's not > unreasonable considering that the refresh time is 2 hours. There are 2 > pairs of serial numbers ~2 minutes apart, so I would guess that's the > minimum update frequency. The other 2 (rbldns0 and rbldns1) aren't > responding at all. Interestingly, the upstream glue NS records (from > the sorbs.net authority) pointing at the rbldns$x names have 10-minute > TTLs, > In effect, that means SORBS can swap IP's for their nameservers in and > out and get many more than 13 IP's being hit by different portions of > the net because their nameservers are handing out variant versions of > the zone and clients are looking for new IPs for the nameservers 144 > times per day. You pretty much sum it up... However it's not to swap IPs its to allow us to remove any server that gets DDoSed within a few minutes, similarly if there is a problem with a particular server... It also allows with generation of new zone deltas every minute to get all the NS records cached by the querying servers without resorting to EDNS0 (and therefore TCP) ... which allow me to scale each server to a minimum of 2500 queries per second all the way up to 40,000 queries per second. > > No, it tells you that those specific 4 nameserver addresses didn't > respond to queries. 4 is a little unusual, but 2 or 3 is not and 1 is certain.. As the DNS servers reload their zones they stop responding, the servers can reload their zones every 60 seconds. > Only the first is currently found in a the collection of authoritative > nameservers for dnsbl.sorbs.net, but all of them have symmetric PTR/A > records, implying that they aren't some sort of poisoning artifact. > Also, the last 3 are in small blocks allocated by SoftLayer to GFI > Software, the former owner of SORBS. Where do you see GFI? Nothing should show GFI (all the SL stuff is owned by Proofpoint) > Finally, the last 2 are also supposed to be authoritative for > sorbs.net, and it is possible for the various TTLs' expiration to > leave one in a position of asking those machines instead of the proper > authorities. For information: sorbs.net NS servers will give glue and authority to a sub selection of the RBL servers (rbldns[1-17].sorbs.net currently possible) each zone loaded into the rbldns servers has a random selection of 7 NS records (random at time of generation with any 'Down' servers not in the possible list) > So yes: SORBS has some sort of DNS problem, but it isn't fatal. > No, it's probably normal operation, however it would appear to be an issue when compared to a non-RBL zone. > The queries to SORBS are *eventually* working, because the normal > behavior for BIND is to retry with another server when one doesn't > answer. BIND really wants to tell you about any little problem you'll > listen too, even if it's transient, so you see these events in logs if > you log deeply enough. Some resolvers will send one query to more than one server at the same time, they then cache the server which responds the fastest as where to send all future queries until $timeout. Some send out 3 queries regardless (assuming there are more than 2 servers). (A way to get this to be almost certain behavior is use a single NS record pointing at multiple A records.) Some just send out queries to the same servers as they were told about them, only moving to the next after a lookup failure. Some servers seem to rotate (round robin) all the NS records in their caches and will send queries that way. Some servers randomise the NS servers they will query every time they make a query. ... The SORBS delegation and RBL servers have their current setup/design since 2007 because it seems to be the best compromise when you get DDoSed, and for minimising duplicate data whilst having the ability to reconfigure your network without *most* people noticing... ;-) Regards, -- Michelle Sullivan http://www.mhix.org/
Re: I need professional help
(From the subscribed address this time - sorry if you get it twice) Incorrect. list which includes the sbl-xbl.spamhaus.org and cbl.abuseat.org lists for example. And ZEN includes dul.dnsbl.sorbs.net. And dsn.rfc-ignorant.org is dead now. I am not familiar with the others No SORBS list is included in any Spamhaus list, and it never will be. ZEN is a Spamhaus list, dul.dnsbl.sorbs.net is a SORBS list. Michelle -- Michelle Sullivan http://www.mhix.org/
Re: I need professional help
Bob Proulx wrote: The Spamhaus PBL lists IPs that by policy (policy block list) should not be sending email such as IPs in dynamic IP address ranges. http://www.spamhaus.org/pbl/ So both of those lists are listing addresses known to be in a dynamic address range. Those are often consumer devices that have become victims of spammer viruses. Viruses that are sending mail from dynamic addresses. Those can be avoided if one avoids receiving email from dynamic address ranges through the use of one of those DNSBLs. They should be required to ring a bell and shout Stay back. Unclean! Correct. The PBL is included in XEN. http://www.spamhaus.org/zen/ Correct While probably not a strict superset since the data is compiled independently wouldn't it generally be true that every IP address listed in the dynamic IP range in dul.dnsbl.sorbs.net for being a dynamic address would also be listed in the dynamic IP range in pbl.spamhaus.org for being a dynamic address? Incorrect (SORBS also has a PBL and whilst there is roughly a 70% overlap there is by no means a superset issue) ... of course if you read the wording of the PBL you would correctly be confused into thinking that all dynamics are listed and any statics that by policy should be blocked. As you would thinking that they only 'extras' are dynamic, but reality is it's what Spamhaus think should or should not be sending email (and it does state such.) The SORBS DUHL is just dynamics. The SORBS PBL is just by policy should not be sending email (or have DNS or Webservers on them) The dnsbl.sorbs.net zone includes both of the above (and more.) They are different organizations providing a similarly goaled data set. But the goal is the same so in theory the set of dynamic addresses in each should be quite similar. No? I realize that the policy additions will be different between them. No the PBL is where Spamhaus thinks email should be sent from or not, or have been told email can be sent from or not, nothing more, nothing less... if you want a clearer definition ask Spamhaus, however everyone I know who has just has been pointed at the FAQ as the 'clear' course. My original point being to use the fewest number of DNS lookups that gets the task done. Expecially on a busy mail server the load from DNS can be appreciable. Understood, but being two orgs and saying one or contains the data of the second is incorrect unless it is stated as such by the org in question... I would enjoy reading any comments you might have on optimum DNSBL anti-spam usage. Postfix (as was by the comments/config) will stop doing DNSBl lookups at the first reject hit ... put the most effective first and least effective last. This is how to minimize DNS queries. In the case of SORBS (and others, including Spamhaus) .. if you want multiple zones rather than querying each zone use the aggregate and block on return code (the return codes are cached locally so you can query the same zone for multiple codes without additional DNS loading.) - Note: that is the behavior of Postfix, I do not know about Exim or Sendmail or other mail servers.. Hope this clarifies and helps, Michelle Bob -- Michelle Sullivan http://www.mhix.org/
Re: I need professional help
Of course I fell into an old trap and didn't read before I hit send... corrections below: Michelle Sullivan wrote: The SORBS DUHL is just dynamics. * With the obvious caveat that networks of the world are always changing so listings may be changed to static from time to time and SORBS just plays catchup. (ISPs can administer their own lists as well - without SORBS input - hitting the support form and seeing 'immutable' is where the ISP has set it) The SORBS PBL is just by policy should not be sending email (or have DNS or Webservers on them) The SORBS 'PBL' doesn't exist (I used the acronym so you (and others) would understand it's purpose.. It's the SORBS 'No Servers' list. (noservers.dnsbl.sorbs.net) Unlike the Spamhaus PBL it contains addresses *only* maintained by the ISPs.. SORBS Staff *DO NOT* add or remove *ANY* address from it. Regards, Michelle -- Michelle Sullivan http://www.mhix.org/
