Re: [mailop] SORBS Closing.
Am 07.06.24 um 23:33 schrieb Bill Cole: You do not even need to do that. All SORBS-referencing rules were removed from the updates.spamasssassin.org rules channel earlier this week. Scanning the latest deployed (by sa-update) version r1918114 I see no surviving references to SORBS. since yesterday I do see no queries to dnsbl.sorbs.net. in my network anymore. So: thanks for the (spamassassin)-update :-) Andreas
Re: [mailop] SORBS Closing.
On 2024-06-06 at 19:53:02 UTC-0400 (Thu, 6 Jun 2024 19:53:02 -0400) J Doe is rumored to have said: [...] > Hi Rob and list, > > Speaking as a small user of SORBS via SpamAssassin 4.0, I assume the > correct response to disable use of SORBS is to place the following in my > local.cf file: > > dns_query_restriction deny sorbs.net > > Is that correct and is there any additional portions of local.cf I need > to configure so that I am no longer consulting SORBS ? You do not even need to do that. All SORBS-referencing rules were removed from the updates.spamasssassin.org rules channel earlier this week. Scanning the latest deployed (by sa-update) version r1918114 I see no surviving references to SORBS. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Fwd: [mailop] SORBS Closing.
On 2024-06-05 04:44, Rob McEwen via users wrote: From "Frido Otten" mailto:fr...@0tten.nl>> So is there anything that needs to be done to prevent false positives happening right after the shutdown? They said they were emptying the zone files, not actually "listing the world" - so this shouldn't cause false any positives - but might cause some false negatives, especially for anyone who was overly relying on SORBS in their spam filtering? But yet - after some years - lists like this - once they've been dead for many many years - do /sometimes/ "list the world" as a final push to get others to stop using them - if that even ever happens with SORBS? And if it ever did, I doubt that would happen anytime soon. But definately make sure that your spam filter is ONLY ever acting on specific and valid SORBS return codes - and NOT treating ANY query being resolved that isn't NXDOMAIN - as a listing. Anyone */misusing/* SORBS in that way - might one day have a very bad day. But that's a general truth for all DSNBLs - make sure your rules/setup for its usage only treat it as a valid listing when specific return codes are returned, that match that DNSBL's instructions, and thus */NOT/* taking action just because /some /IP address was resolved by the query. /(I think any built-in/default SpamAssassin rules for SORBS - already does all of this correctly.)/ Rob McEwen, invaluement Hi Rob and list, Speaking as a small user of SORBS via SpamAssassin 4.0, I assume the correct response to disable use of SORBS is to place the following in my local.cf file: dns_query_restriction deny sorbs.net Is that correct and is there any additional portions of local.cf I need to configure so that I am no longer consulting SORBS ? Thanks, - J
Re: Fwd: [mailop] SORBS Closing.
From "Frido Otten" So is there anything that needs to be done to prevent false positives happening right after the shutdown? They said they were emptying the zone files, not actually "listing the world" - so this shouldn't cause false any positives - but might cause some false negatives, especially for anyone who was overly relying on SORBS in their spam filtering? But yet - after some years - lists like this - once they've been dead for many many years - do sometimes "list the world" as a final push to get others to stop using them - if that even ever happens with SORBS? And if it ever did, I doubt that would happen anytime soon. But definately make sure that your spam filter is ONLY ever acting on specific and valid SORBS return codes - and NOT treating ANY query being resolved that isn't NXDOMAIN - as a listing. Anyone misusing SORBS in that way - might one day have a very bad day. But that's a general truth for all DSNBLs - make sure your rules/setup for its usage only treat it as a valid listing when specific return codes are returned, that match that DNSBL's instructions, and thus NOT taking action just because some IP address was resolved by the query. (I think any built-in/default SpamAssassin rules for SORBS - already does all of this correctly.) Rob McEwen, invaluement
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
Fwd: [mailop] SORBS Closing.
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 OpenPGP_0xCCDCFB22C59E9DD2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: sorbs :/
> https://www.irccloud.com/pastebin/XPl5OZ0y/sorbs.pl > > lets just test more dns fails, please fix qname, reduce zones that ends > in same nameserver ip > Yes, seeing that here, too, for months and months. Spamhaus also sucks real bad. 06-Oct-2023 13:57:12.880 resolver: loop detected resolving ' musashi.spamhaus.net/A' 06-Oct-2023 13:57:12.880 resolver: loop detected resolving ' hideyoshi.spamhaus.net/A' These are also ultimately qname security problems they simply won't even acknowledge, let alone fix. 26-Sep-2023 21:04:49.571 lame-servers: FORMERR resolving ' mykey.hbl.dq.spamhaus.net/NS/IN': 82.117.252.122#53 26-Sep-2023 21:04:49.598 resolver: DNS format error from 209.239.115.2#53 resolving mykey.hbl.dq.spamhaus.net/NS for : reply has no answer Also seeing this? 07-Oct-2023 11:49:03.789 resolver: loop detected resolving 'ns3.pccc.com/A' And barracuda using an IP registered with them: 05-Oct-2023 11:10:11.868 query-errors: client @0x7f3234752b68 127.0.0.1#55912 (20.0.135.147.bb.barracudacentral.org): query failed (timed out) for 20.0.135.147.bb.barracudacentral.org/IN/A at ../../../lib/ns/query.c:7824
sorbs :/
https://www.irccloud.com/pastebin/XPl5OZ0y/sorbs.pl lets just test more dns fails, please fix qname, reduce zones that ends in same nameserver ip
Re: sorbs blocklist spamassassin.apache.org
On 1/15/2023 10:20 AM, Benny Pedersen wrote: https://multirbl.valli.org/lookup/95.216.194.37.html but who cares ? On 15.01.23 10:53, Kevin A. McGrail wrote: No one, likely cares. I don't think that machine sends email. I get my mail from this list via that machine: Jan 15 16:20:51 fantomas postfix/smtpd[672]: A31B2A012C: client=mxout1-he-de.apache.org[95.216.194.37] Jan 15 16:20:51 fantomas postfix/cleanup[677]: A31B2A012C: message-id= Jan 15 16:20:52 fantomas postfix/qmgr[3230]: A31B2A012C: from=, size=4133, nrcpt=1 (queue active) luckily it's listed in dnswl.org: Jan 15 16:20:44 fantomas postfix/dnsblog[666]: addr 95.216.194.37 listed by domain list.dnswl.org as 127.0.4.2 however, I use safe.dnsbl.sorbs.net and it's not included there. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Posli tento mail 100 svojim znamim - nech vidia aky si idiot Send this email to 100 your friends - let them see what an idiot you are
Re: sorbs blocklist spamassassin.apache.org
Kevin A. McGrail skrev den 2023-01-15 17:47: That's the mail infrastructure run by infrastructure at Apache not by the projects. See https://infra.apache.org/ i can't confirm infra only The mailing lists at Apache are run by Infra not the project. If you are having delivery issues, see that website and make sure you open a ticket there. Discussing it here is unlikely to get any resolution. good X-Spam-Status: No, score=-8.8 required=5.0 tests=AWL,DMARC_MISSING, KAM_DMARC_STATUS,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W,RCVD_IN_MSPIKE_H2,RELAYCOUNTRY_GREY,SPF_HELO_PASS, SPF_PASS,USER_IN_DEF_SPF_WL shortcircuit=no autolearn=ham autolearn_force=no version=4.0.0 X-Spam-AWL: AWL=-0.1 MEAN=-6.1 COUNT=8.0 PRESCORE=-6.2 X-Spam-Relay-Country: US US DE US X-Spam-ASN: AS14618 3.224.0.0/12 i did not say i have problems not using sorbs
Re: sorbs blocklist spamassassin.apache.org
That's the mail infrastructure run by infrastructure at Apache not by the projects. See https://infra.apache.org/ i can't confirm infra only The mailing lists at Apache are run by Infra not the project. If you are having delivery issues, see that website and make sure you open a ticket there. Discussing it here is unlikely to get any resolution. Regards, KAM
Re: sorbs blocklist spamassassin.apache.org
Kevin A. McGrail skrev den 2023-01-15 16:56: On 1/15/2023 10:53 AM, Kevin A. McGrail wrote: On 1/15/2023 10:20 AM, Benny Pedersen wrote: https://multirbl.valli.org/lookup/95.216.194.37.html but who cares ? No one, likely cares. I don't think that machine sends email. Checking more thoroughtly SpamAssassin.apache.org is on 151.101.2.132 That IP is mxout1-he-de.apache.org. That's the mail infrastructure run by infrastructure at Apache not by the projects. See https://infra.apache.org/ i can't confirm infra only 324 skynet.nemocnice-vs.cz 2023-01-14 00:09:02 | -- 1 junc.eu 95.216.194.37 nonefailfail local_policy( arc=fail ) | -- 1 junc.eu 3.227.148.255 nonefailfail local_policy( arc=fail ) i have used Mail::DMARC before spamassassin supported it
Re: sorbs blocklist spamassassin.apache.org
Kevin A. McGrail skrev den 2023-01-15 16:53: On 1/15/2023 10:20 AM, Benny Pedersen wrote: https://multirbl.valli.org/lookup/95.216.194.37.html but who cares ? No one, likely cares. I don't think that machine sends email. or none are using sorbs https://www.dnswl.org/s/?s=3084 i gave that ip from my Mail::DMARC logs reporting, with did dkim fail, spf fail that normaly not being dkim fail unless apache org do use spamassassing 4 now :)
Re: sorbs blocklist spamassassin.apache.org
On 1/15/2023 10:53 AM, Kevin A. McGrail wrote: On 1/15/2023 10:20 AM, Benny Pedersen wrote: https://multirbl.valli.org/lookup/95.216.194.37.html but who cares ? No one, likely cares. I don't think that machine sends email. Checking more thoroughtly SpamAssassin.apache.org is on 151.101.2.132 That IP is mxout1-he-de.apache.org. That's the mail infrastructure run by infrastructure at Apache not by the projects. See https://infra.apache.org/ Regards, KAM -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
RE: sorbs blocklist spamassassin.apache.org
> > https://multirbl.valli.org/lookup/95.216.194.37.html > > but who cares ? What is the problem? I am even surprised that there are so many green listings. I have even configured that hosts with a reverse xxx.your-server.de are not allowed to connect.
Re: sorbs blocklist spamassassin.apache.org
On 1/15/2023 10:20 AM, Benny Pedersen wrote: https://multirbl.valli.org/lookup/95.216.194.37.html but who cares ? No one, likely cares. I don't think that machine sends email. -- Kevin A. McGrail kmcgr...@apache.org Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
sorbs blocklist spamassassin.apache.org
https://multirbl.valli.org/lookup/95.216.194.37.html but who cares ?
Re: Problems with SORBS?
On Sat, 2018-04-07 at 02:07 -0400, Bill Cole wrote: > On 6 Apr 2018, at 8:08, Martin Gregorie wrote: > > > I'm getting a lot of SORBS lookups rejected due to an "unexpected > > RCODE". Is anybody else seeing these? > > I'm sure someone is... > > There are none of those where I see. If the "unexpected RCODE" is > SERVFAIL, it was likely transient on their end. > Yep, all are SERVFAIL and another big bunch appeared in my logwatch report today. My volume is far too small to trigger REFUSED and I do run a non-forwarding dns server. Thanks for your explanation, though its looking a bit more like an intransigent transient than it did earlier. Martin
Re: Problems with SORBS?
On 6 Apr 2018, at 8:08, Martin Gregorie wrote: I'm getting a lot of SORBS lookups rejected due to an "unexpected RCODE". Is anybody else seeing these? I'm sure someone is... There are none of those where I see. If the "unexpected RCODE" is SERVFAIL, it was likely transient on their end. If it was REFUSED then you may need to whether you might be hitting whatever the volume caps are (I have no idea what the SORBS volume caps are.)
Problems with SORBS?
I'm getting a lot of SORBS lookups rejected due to an "unexpected RCODE". Is anybody else seeing these? I'm running BIND 9.11.3-RedHat-9.11.3-2.fc27 Martin
Re: Turning off queries to SORBS
Am 20.04.2016 um 14:30 schrieb Michelle Sullivan: $ /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...! ) the problem is most likely a /opt/local/bin/whois from the last century [harry@rh:~]$ whois --version Version 5.2.12. [harry@rh:~]$ ls /usr/bin/whois.md -rwxr-xr-x 1 root root 136K 2016-03-29 15:54 /usr/bin/whois.md [harry@rh:~]$ /usr/bin/whois 174.36.198.233 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # # # The following results may also be obtained via: # https://whois.arin.net/rest/nets;q=174.36.198.233?showDetails=true=false=false=netref2 # NetRange: 174.36.0.0 - 174.37.255.255 CIDR: 174.36.0.0/15 NetName:SOFTLAYER-4-7 NetHandle: NET-174-36-0-0-1 Parent: NET174 (NET-174-0-0-0-0) NetType:Direct Allocation OriginAS: AS36351 Organization: SoftLayer Technologies Inc. (SOFTL) RegDate:2008-09-12 Updated:2013-07-12 Ref:https://whois.arin.net/rest/net/NET-174-36-0-0-1 OrgName:SoftLayer Technologies Inc. OrgId: SOFTL Address:4849 Alpha Rd. City: Dallas StateProv: TX PostalCode: 75244 Country:US RegDate:2005-10-26 Updated:2013-02-20 Ref:https://whois.arin.net/rest/org/SOFTL ReferralServer: rwhois://rwhois.softlayer.com:4321 OrgTechHandle: IPADM258-ARIN OrgTechName: IP Admin OrgTechPhone: +1-214-442-0601 OrgTechEmail: ipad...@softlayer.com OrgTechRef:https://whois.arin.net/rest/poc/IPADM258-ARIN OrgAbuseHandle: ABUSE1025-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-214-442-0601 OrgAbuseEmail: ab...@softlayer.com OrgAbuseRef:https://whois.arin.net/rest/poc/ABUSE1025-ARIN RAbuseHandle: ABUSE1025-ARIN RAbuseName: Abuse RAbusePhone: +1-214-442-0601 RAbuseEmail: ab...@softlayer.com RAbuseRef:https://whois.arin.net/rest/poc/ABUSE1025-ARIN RTechHandle: IPADM258-ARIN RTechName: IP Admin RTechPhone: +1-214-442-0601 RTechEmail: ipad...@softlayer.com RTechRef:https://whois.arin.net/rest/poc/IPADM258-ARIN RNOCHandle: IPADM258-ARIN RNOCName: IP Admin RNOCPhone: +1-214-442-0601 RNOCEmail: ipad...@softlayer.com RNOCRef:https://whois.arin.net/rest/poc/IPADM258-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # Verweis auf rwhois.softlayer.com:4321 gefunden. %rwhois V-1.5:003fff:00 rwhois.attcloudarchitect.com (by Network Solutions, Inc. V-1.5.9.6) network:Auth-Area:174.36.192.0/18 network:Class-Name:network network:Street-Address:NA network:City:NA network:Postal-Code:27 network:Country-Code:SA network:Tech-Contact;I:sysadm...@softlayer.com network:Abuse-Contact;I:ab...@softlayer.com network:Admin-Contact;I:IPADM258-ARIN network:Created:2008-06-12 16:43:22 network:Updated:2014-01-20 07:00:50 network:Updated-By:ipad...@softlayer.com %ok signature.asc Description: OpenPGP digital signature
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
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 network:Street-Address:15300 Weston Parkway, Suite 104 network:City:Cary network:State:NC network:Postal-Code:27513 network:Country-Code:US network:Tech-Contact;I:sysadm...@softlayer.com network:Abuse-Contact;I:ab...@gfi.com network:Admin-Contact;I:IPADM258-ARIN network:Created:2010-02-22 10:26:09 network:Updated:2015-04-18 20:06:14 network:Updated-By:ipad...@softlayer.com %ok
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: Turning off queries to SORBS
On 13 May 2015, at 20:24, Chris wrote: So I guess then that the bottom line is that eventually the queries are getting through to SORBS but I'll still be seeing some errors and just don't worry about it. Does that sound about right? Yes.
Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 02:05 +, Jeremy McSpadden wrote: dig +trace and see if your ISP is intercepting queries. -- Jeremy McSpadden | Flux Labs Local - 850-250-5590x501 | Mobile - 850-890-2543 Fax - 850-254-2955 | Toll Free - 877-699-FLUX Web - http://www.fluxlabs.net Jeremy, I'm replying to you again and Ccing the list which I forgot to do last night. Below are the results of the above command. I don't see anywhere my ISP is involved. I've put the output on pastebin so it doesn't get mangled here on the list dig +trace 54.139.130.12.dnsbl.sorbs.net http://pastebin.com/up0A2xD1 Chris On May 12, 2015, at 8:49 PM, Chris cpoll...@embarqmail.com wrote: Is there a way to turn off queries to SORBS so I don't keep seeing this in my logs: error (connection refused) resolving '23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53 I have Bind9 setup as a caching name server and am using 127.0.0.1 as my DNS -- Chris KeyID 0xE372A7DA98E6705C 31.11°N 97.89°W (Elev. 1092 ft) 08:44:59 up 2 days, 2:54, 3 users, load average: 0.20, 0.18, 0.23 Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar 31 02:07:04 UTC 2015
Re: Turning off queries to SORBS
Chris wrote:
Is there a way to turn off queries to SORBS so I don't keep seeing this
in my logs:
error (connection refused) resolving
'23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53
I have Bind9 setup as a caching name server and am using 127.0.0.1 as my
DNS.
Are you seeing problems with the actual lookups failing, or just upset
about the log noise?
I get a fair volume of similar failures in my own log on my personal
server (4 live accounts, ~500 messages daily, most spam; log since
weekly rotation on Sunday):
[root@hex ]# grep 'connection refused' /var/log/messages|grep sorbs|awk
'{ print $10; }'|sort|uniq -c
2 113.52.8.150#53
79 174.36.198.233#53
74 174.36.235.174#53
40 67.228.187.34#53
yet the actual lookups don't fail, they fall over to another upstream
server.
If it's really that big a problem, you can suppress all such log
messages in the BIND config. Depending on which syslog daemon you're
using, you may be able to suppress only the SORBS failures from reaching
the log file. I'm not sure, but you may even be able to tell BIND to
either not log failures only for SORBS, or never attempt lookups off of
the failing servers in the first place.
-kgd
Re: Turning off queries to SORBS
From: Chris cpoll...@embarqmail.com Sent: Wednesday, May 13, 2015 8:50 AM To: Jeremy McSpadden Cc: users@spamassassin.apache.org Subject: Re: Turning off queries to SORBS On Wed, 2015-05-13 at 02:05 +, Jeremy McSpadden wrote: dig +trace and see if your ISP is intercepting queries. -- Jeremy McSpadden | Flux Labs Local - 850-250-5590x501 | Mobile - 850-890-2543 Fax - 850-254-2955 | Toll Free - 877-699-FLUX Web - http://www.fluxlabs.net Jeremy, I'm replying to you again and Ccing the list which I forgot to do last night. Below are the results of the above command. I don't see anywhere my ISP is involved. I've put the output on pastebin so it doesn't get mangled here on the list dig +trace 54.139.130.12.dnsbl.sorbs.net http://pastebin.com/up0A2xD1 Dig +trace doesn't work quite like that. It will show you exactly what a recursive DNS server would do on a client's behalf when doing a full recursive query to the Internet -- not forwarding to another DNS caching server. It's very helpful to troubleshoot DNS servers giving bad/stale info but it's not able to help you see your DNS query flow. You just have to look at your /etc/resolv.conf to see where it's pointed and start there. If you aren't sure that the DNS server in /etc/resolv.conf isn't doing full recursive lookups on it's own, then you need to find one or stand up your own private DNS server so you know what it's doing for sure. If you have a high volume of mail (more than a few hundred to a thousand mailboxes as a rough number), I would recommend setting up your own DNS recursive server (PowerDNS recursor or BIND) with forwarding disabled. Then also setup the same thing on each SA mail server but forward to your new private DNS server, then update the /etc/resolv.conf to point to 127.0.0.1. SA server (/etc/resolv.conf) - 127.0.0.1 - private DNS server (not forwarding) - Internet Chris On May 12, 2015, at 8:49 PM, Chris cpoll...@embarqmail.com wrote: Is there a way to turn off queries to SORBS so I don't keep seeing this in my logs: error (connection refused) resolving '23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53 I have Bind9 setup as a caching name server and am using 127.0.0.1 as my DNS -- Chris KeyID 0xE372A7DA98E6705C 31.11°N 97.89°W (Elev. 1092 ft) 08:44:59 up 2 days, 2:54, 3 users, load average: 0.20, 0.18, 0.23 Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar 31 02:07:04 UTC 2015
Re: Turning off queries to SORBS
On 5/13/2015 10:08 AM, David Jones wrote: From: Chris cpoll...@embarqmail.com Sent: Wednesday, May 13, 2015 8:50 AM To: Jeremy McSpadden Cc: users@spamassassin.apache.org Subject: Re: Turning off queries to SORBS On Wed, 2015-05-13 at 02:05 +, Jeremy McSpadden wrote: dig +trace and see if your ISP is intercepting queries. -- Jeremy McSpadden | Flux Labs Local - 850-250-5590x501 | Mobile - 850-890-2543 Fax - 850-254-2955 | Toll Free - 877-699-FLUX Web - http://www.fluxlabs.net Jeremy, I'm replying to you again and Ccing the list which I forgot to do last night. Below are the results of the above command. I don't see anywhere my ISP is involved. I've put the output on pastebin so it doesn't get mangled here on the list dig +trace 54.139.130.12.dnsbl.sorbs.net http://pastebin.com/up0A2xD1 Dig +trace doesn't work quite like that. It will show you exactly what a recursive DNS server would do on a client's behalf when doing a full recursive query to the Internet -- not forwarding to another DNS caching server. It's very helpful to troubleshoot DNS servers giving bad/stale info but it's not able to help you see your DNS query flow. You just have to look at your /etc/resolv.conf to see where it's pointed and start there. If you aren't sure that the DNS server in /etc/resolv.conf isn't doing full recursive lookups on it's own, then you need to find one or stand up your own private DNS server so you know what it's doing for sure. If you have a high volume of mail (more than a few hundred to a thousand mailboxes as a rough number), I would recommend setting up your own DNS recursive server (PowerDNS recursor or BIND) with forwarding disabled. Then also setup the same thing on each SA mail server but forward to your new private DNS server, then update the /etc/resolv.conf to point to 127.0.0.1. SA server (/etc/resolv.conf) - 127.0.0.1 - private DNS server (not forwarding) - Internet To make sure you are not forwarding queries to your ISP, check you named.conf file for any forwarders lines. If you have any, remove them so your server will do the lookups itself rather than forwarding them elsewhere. -- Bowie
Re: Turning off queries to SORBS
From: Reindl Harald h.rei...@thelounge.net Sent: Wednesday, May 13, 2015 12:35 PM To: users@spamassassin.apache.org Subject: Re: Turning off queries to SORBS Am 13.05.2015 um 19:26 schrieb David Jones: Connection refused errors are specific UDP responses from upstream DNS servers that are being denied due to rate limiting, bad query packets, or something that simply ticked off that upstream DNS server. I would point to a different DNS server or disable forwarding on the local DNS cache and do my own recursive lookups and the connection refused messages should go away if you would follow that thread you would know that the named configuration in the meantime *is* a caching nameserver doing recursion I did follow the thread but my point is that you should be able to insulate yourself from all of the bad zone delegations and misconfigured DNS servers out there that would give the connection refused response if you setup your own servers in the proper way. Maybe simply changing from a BIND caching server on localhost to dnsmasq (disable the DHCP server), unbound, or pdns-recursor might at least clear up the noise in /var/log/messages. The more I use pdns-recursor and other DNS servers, the less I like BIND.
Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 13:49 -0400, Kris Deugau wrote:
Chris wrote:
Not upset about the 'noise', to my untrained eye it looks to me as if
the lookups are failing:
chris@localhost:/var/log$ grep 'connection refused' /var/log/syslog|grep
sorbs|awk '{ print $10; }'|sort|uniq -c
1 '11.1.4.96.dnsbl.sorbs.net/A/IN':
1 '114.210.57.173.dnsbl.sorbs.net/A/IN':
1 '139.207.161.25.dnsbl.sorbs.net/A/IN':
1 '183.163.46.207.dnsbl.sorbs.net/A/IN':
1 '54.139.130.12.dnsbl.sorbs.net/A/IN':
2 'aftershock.sorbs.net/A/IN':
2 'cannonball.sorbs.net/A/IN':
2 'ns0.sorbs.net/A/IN':
1 'ns2.sorbs.net//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//IN':
3 'ns4.sorbs.net/A/IN':
The above is just from todays syslog starting at 7:40 this morning.
Try print $11 in the awk (this prints the 11th field or non-whitespace
chunk); that should show the failing server IP instead of the lookup.
Your log seems to have another non-whitespace blob somewhere earlier in
the line compared to mine, where the remote server IP is the 10th field:
May 13 07:52:57 hex named[3790]: connection refused resolving
'130.102.149.83.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
Also try doing the lookups that appear to fail with dig or host, and see
if the actual client lookup succeeds or fails; just because one
nameserver for a zone refused the connection doesn't mean the actual
lookup failed.
I tried the first 5 above plus a couple more from my own log, and all
returned NXDOMAIN - except one lookup took a few seconds to return, so
it probably hit one of those nameservers that's not accepting connections.
I really don't want to suppress the syslog entries nor do I not want to
query SORBS, I would just like to figure out why the connection is
refused.
The particular nameservers refusing connections are either failed or
overloaded. A big DNSBL like SORBS has many nameservers, and it's
likely that each entry from eg dig dnsbl.sorbs.net ns is a cluster of
machines.
-kgd
I'll answer several questions in this post hopefully.
First, the line in my resolv.conf fire search PK5001Z, pertains to my
Zyxel PK5001Z modem, so as a test I've commented out that line in
my /etc/resolv.conf and ran sudo resolvconf -u. If it makes a difference
I'll make the appropriate changes elsewhere to make it permanent.
As far as running something other than Bind, I'd run it for many years
on my old Mandriva box before it crashed. Once I got it up and running
(with some help from the Bind users list) I never had one single
problem.
chris@localhost:~$ grep 'connection refused' /var/log/syslog.1|grep
sorbs|awk '{ print $11; }'|sort|uniq -c
2 113.52.8.150#53
8 174.36.198.233#53
14 174.36.235.174#53
9 67.228.187.34#53
Again, to my untrained eye this shows less info than using $10 in the
awk statement.
A spam came through a bit ago and this was in the SA markup:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.75.74 listed in dnsbl.sorbs.net]
Looking back at my spam folder this was the markup on a spam that came
in earlier today before I made the change to my resolv.conf and
commented out the 'search' line:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.79.50 listed in dnsbl.sorbs.net]
The output as shown in my syslog is attached which shows
named[1091]: error (connection refused) resolving
'50.79.197.70.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
Am I screwed up in the head here and it's working as shown in the markup
above or is the queries to SORBS not working and I need to fix
something?
Chris
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
14:46:02 up 2 days, 8:55, 3 users, load average: 0.06, 0.21, 0.22
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015
May 13 13:41:52 localhost spamd[7746]: spamd: connection from ip6-localhost
[::1]:32843 to port 783, fd 6
May 13 13:41:52 localhost spamd[7746]: spamd: setuid to chris succeeded
May 13 13:41:52 localhost spamd[7746]: spamd: processing message
d6.e0.17575.18a93...@mx02.agate.dfw.synacor.com for chris:1000
May 13 13:41:52 localhost clamd[1975]: Accepted connection from 127.0.0.1 on
port 1764, fd 13
May 13 13:41:52 localhost named[1091]: error (connection refused) resolving
'50.79.197.70.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
May 13 13:42:02 localhost spamd[7746]: spamd: identified spam (25.8/5.0) for
chris:1000 in 9.7 seconds, 21097 bytes.
May 13 13:42:02 localhost spamd[7746]: spamd: result: Y 25 -
ANY_BOUNCE_MESSAGE,AWL,BAYES_99,BAYES_999,BODY_URI_ONLY,BOTNET,BOUNCE_MESSAGE,DKIM_ADSP_NXDOMAIN,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,MISSING_HEADERS,RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_NONE
Re: Turning off queries to SORBS
On 13 May 2015, at 16:58, Chris wrote:
On Wed, 2015-05-13 at 13:49 -0400, Kris Deugau wrote:
Chris wrote:
Not upset about the 'noise', to my untrained eye it looks to me as
if
the lookups are failing:
chris@localhost:/var/log$ grep 'connection refused'
/var/log/syslog|grep
sorbs|awk '{ print $10; }'|sort|uniq -c
1 '11.1.4.96.dnsbl.sorbs.net/A/IN':
1 '114.210.57.173.dnsbl.sorbs.net/A/IN':
1 '139.207.161.25.dnsbl.sorbs.net/A/IN':
1 '183.163.46.207.dnsbl.sorbs.net/A/IN':
1 '54.139.130.12.dnsbl.sorbs.net/A/IN':
2 'aftershock.sorbs.net/A/IN':
2 'cannonball.sorbs.net/A/IN':
2 'ns0.sorbs.net/A/IN':
1 'ns2.sorbs.net//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//IN':
3 'ns4.sorbs.net/A/IN':
The above is just from todays syslog starting at 7:40 this morning.
Try print $11 in the awk (this prints the 11th field or
non-whitespace
chunk); that should show the failing server IP instead of the
lookup.
Your log seems to have another non-whitespace blob somewhere earlier
in
the line compared to mine, where the remote server IP is the 10th
field:
May 13 07:52:57 hex named[3790]: connection refused resolving
'130.102.149.83.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
Also try doing the lookups that appear to fail with dig or host, and
see
if the actual client lookup succeeds or fails; just because one
nameserver for a zone refused the connection doesn't mean the actual
lookup failed.
I tried the first 5 above plus a couple more from my own log, and all
returned NXDOMAIN - except one lookup took a few seconds to return,
so
it probably hit one of those nameservers that's not accepting
connections.
I really don't want to suppress the syslog entries nor do I not want
to
query SORBS, I would just like to figure out why the connection is
refused.
The particular nameservers refusing connections are either failed or
overloaded. A big DNSBL like SORBS has many nameservers, and it's
likely that each entry from eg dig dnsbl.sorbs.net ns is a cluster
of
machines.
After a fashion that seems so, if you consider fast flux DNS a form of
clustering (I say it is, for nameservers.)
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.
[...]
chris@localhost:~$ grep 'connection refused' /var/log/syslog.1|grep
sorbs|awk '{ print $11; }'|sort|uniq -c
2 113.52.8.150#53
8 174.36.198.233#53
14 174.36.235.174#53
9 67.228.187.34#53
Again, to my untrained eye this shows less info than using $10 in the
awk statement.
No, it tells you that those specific 4 nameserver addresses didn't
respond to queries. 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. 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.
So yes: SORBS has some sort of DNS problem, but it isn't fatal.
A spam came through a bit ago and this was in the SA markup:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.75.74 listed in dnsbl.sorbs.net]
Looking back at my spam folder this was the markup on a spam that came
in earlier today before I made the change to my resolv.conf and
commented out the 'search' line:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.79.50 listed in dnsbl.sorbs.net]
The output as shown in my syslog
Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 20:19 -0400, Bill Cole wrote:
On 13 May 2015, at 16:58, Chris wrote:
On Wed, 2015-05-13 at 13:49 -0400, Kris Deugau wrote:
Chris wrote:
Not upset about the 'noise', to my untrained eye it looks to me as
if
the lookups are failing:
chris@localhost:/var/log$ grep 'connection refused'
/var/log/syslog|grep
sorbs|awk '{ print $10; }'|sort|uniq -c
1 '11.1.4.96.dnsbl.sorbs.net/A/IN':
1 '114.210.57.173.dnsbl.sorbs.net/A/IN':
1 '139.207.161.25.dnsbl.sorbs.net/A/IN':
1 '183.163.46.207.dnsbl.sorbs.net/A/IN':
1 '54.139.130.12.dnsbl.sorbs.net/A/IN':
2 'aftershock.sorbs.net/A/IN':
2 'cannonball.sorbs.net/A/IN':
2 'ns0.sorbs.net/A/IN':
1 'ns2.sorbs.net//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//IN':
3 'ns4.sorbs.net/A/IN':
The above is just from todays syslog starting at 7:40 this morning.
Try print $11 in the awk (this prints the 11th field or
non-whitespace
chunk); that should show the failing server IP instead of the
lookup.
Your log seems to have another non-whitespace blob somewhere earlier
in
the line compared to mine, where the remote server IP is the 10th
field:
May 13 07:52:57 hex named[3790]: connection refused resolving
'130.102.149.83.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
Also try doing the lookups that appear to fail with dig or host, and
see
if the actual client lookup succeeds or fails; just because one
nameserver for a zone refused the connection doesn't mean the actual
lookup failed.
I tried the first 5 above plus a couple more from my own log, and all
returned NXDOMAIN - except one lookup took a few seconds to return,
so
it probably hit one of those nameservers that's not accepting
connections.
I really don't want to suppress the syslog entries nor do I not want
to
query SORBS, I would just like to figure out why the connection is
refused.
The particular nameservers refusing connections are either failed or
overloaded. A big DNSBL like SORBS has many nameservers, and it's
likely that each entry from eg dig dnsbl.sorbs.net ns is a cluster
of
machines.
After a fashion that seems so, if you consider fast flux DNS a form of
clustering (I say it is, for nameservers.)
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.
[...]
chris@localhost:~$ grep 'connection refused' /var/log/syslog.1|grep
sorbs|awk '{ print $11; }'|sort|uniq -c
2 113.52.8.150#53
8 174.36.198.233#53
14 174.36.235.174#53
9 67.228.187.34#53
Again, to my untrained eye this shows less info than using $10 in the
awk statement.
No, it tells you that those specific 4 nameserver addresses didn't
respond to queries. 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. 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.
So yes: SORBS has some sort of DNS problem, but it isn't fatal.
A spam came through a bit ago and this was in the SA markup:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.75.74 listed in dnsbl.sorbs.net]
Looking back at my spam folder this was the markup on a spam that came
in earlier today before I made the change to my resolv.conf
Re: Turning off queries to SORBS
Chris wrote:
I'll answer several questions in this post hopefully.
First, the line in my resolv.conf fire search PK5001Z, pertains to my
Zyxel PK5001Z modem, so as a test I've commented out that line in
my /etc/resolv.conf and ran sudo resolvconf -u. If it makes a difference
I'll make the appropriate changes elsewhere to make it permanent.
I'm mildly allergic to resolvconf as it seems to Do The Wrong Thing any
time I've let it have its way. Otherwise your DNS cache appears to be
set up correctly.
The search line is a red herring since it's only used, as David Jones
pointed out, on lookups with a tool like host or dig where you've just
specified a host part.
As far as running something other than Bind, I'd run it for many years
on my old Mandriva box before it crashed. Once I got it up and running
(with some help from the Bind users list) I never had one single
problem.
*nod* I continue to use it on my own server and as a LAN cache because
I'm familiar with it and its minor warts don't cause issue. (And one
arguable misfeature makes certain parts of managing my own LAN DNS a
little simpler.) About all switching would do is give you minor
headaches learning the new configuration, and probably fresh new
confusing log entries.
chris@localhost:~$ grep 'connection refused' /var/log/syslog.1|grep
sorbs|awk '{ print $11; }'|sort|uniq -c
2 113.52.8.150#53
8 174.36.198.233#53
14 174.36.235.174#53
9 67.228.187.34#53
Again, to my untrained eye this shows less info than using $10 in the
awk statement.
From your logs, $10 (the tenth blob of non-whitespace) is the lookup
that was attempted. $11 is the remote server your cache tried first and
got refused by.
That looks like essentially the same list as I found, so it looks like
SORBS has a number of bad servers. I checked the list of nameservers
returned by host -t ns dnsbl.sorbs.net, and I find it curious that
only the first one seems to actually be in that list, but given the
scale they're operating on I can imagine several reasons an apparently
uninvolved IP would be responding for their DNSBL subzone.
There's nothing on your end to do other than fiddle with logging to hide
the noise; so long as what you're looking up in DNS can be found on
another server, your client lookups (either by hand with host, dig,
etc or by eg SpamAssassin) will succeed.
A spam came through a bit ago and this was in the SA markup:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.75.74 listed in dnsbl.sorbs.net]
score RCVD_IN_SORBS_DUL 0 0.001 0 0.001
This is an advisory rule, mainly used in meta rules.
Looking back at my spam folder this was the markup on a spam that came
in earlier today before I made the change to my resolv.conf and
commented out the 'search' line:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.79.50 listed in dnsbl.sorbs.net]
The output as shown in my syslog is attached which shows
named[1091]: error (connection refused) resolving
'50.79.197.70.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
Your BIND cache tried to look up 50.79.197.70.dnsbl.sorbs.net from
174.36.235.174, but was refused, so it tried another nameserver and got
a response (I get 127.0.0.10 as of writing).
It's not so great that one or more of their nameservers is refusing
queries, but their DNSBL data is served from 13 or more logical servers
as listed by host -t ns dnsbl.sorbs.net, and it's likely there's more
than one physical machine for each of those NS listings.
It's only a problem when a zone only *has* one listed nameserver, or
*all* of the nameservers refuse queries. In that case you can't get an
answer, but otherwise your cache (of any flavour) should walk the list
of nameservers until it gets a response of some kind.
Am I screwed up in the head here and it's working as shown in the markup
above or is the queries to SORBS not working and I need to fix
something?
The problem is with a couple of SORBS nameservers, your cache is just
reporting the problem before retrying the query with another one from
the list. SpamAssassin (or any other client doing a DNS lookup) doesn't
know and doesn't care.
What you're seeing logged by BIND is a transient failure that only slows
down lookups in dnsbl.sorbs.net.
-kgd
Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 10:12 -0400, Kris Deugau wrote:
Chris wrote:
Is there a way to turn off queries to SORBS so I don't keep seeing this
in my logs:
error (connection refused) resolving
'23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53
I have Bind9 setup as a caching name server and am using 127.0.0.1 as my
DNS.
Are you seeing problems with the actual lookups failing, or just upset
about the log noise?
I get a fair volume of similar failures in my own log on my personal
server (4 live accounts, ~500 messages daily, most spam; log since
weekly rotation on Sunday):
[root@hex ]# grep 'connection refused' /var/log/messages|grep sorbs|awk
'{ print $10; }'|sort|uniq -c
2 113.52.8.150#53
79 174.36.198.233#53
74 174.36.235.174#53
40 67.228.187.34#53
yet the actual lookups don't fail, they fall over to another upstream
server.
If it's really that big a problem, you can suppress all such log
messages in the BIND config. Depending on which syslog daemon you're
using, you may be able to suppress only the SORBS failures from reaching
the log file. I'm not sure, but you may even be able to tell BIND to
either not log failures only for SORBS, or never attempt lookups off of
the failing servers in the first place.
-kgd
Not upset about the 'noise', to my untrained eye it looks to me as if
the lookups are failing:
chris@localhost:/var/log$ grep 'connection refused' /var/log/syslog|grep
sorbs|awk '{ print $10; }'|sort|uniq -c
1 '11.1.4.96.dnsbl.sorbs.net/A/IN':
1 '114.210.57.173.dnsbl.sorbs.net/A/IN':
1 '139.207.161.25.dnsbl.sorbs.net/A/IN':
1 '183.163.46.207.dnsbl.sorbs.net/A/IN':
1 '54.139.130.12.dnsbl.sorbs.net/A/IN':
2 'aftershock.sorbs.net/A/IN':
2 'cannonball.sorbs.net/A/IN':
2 'ns0.sorbs.net/A/IN':
1 'ns2.sorbs.net//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//IN':
3 'ns4.sorbs.net/A/IN':
The above is just from todays syslog starting at 7:40 this morning.
Here's yesterdays:
chris@localhost:/var/log$ grep 'connection refused' /var/log/syslog.1|
grep sorbs|awk '{ print $10; }'|sort|uniq -c
1 '112.89.189.91.dnsbl.sorbs.net/A/IN':
2 '11.67.255.128.dnsbl.sorbs.net/A/IN':
1 '119.123.171.166.dnsbl.sorbs.net/A/IN':
2 '121.34.211.207.dnsbl.sorbs.net/A/IN':
1 '136.207.152.107.dnsbl.sorbs.net/A/IN':
2 '15.6.255.128.dnsbl.sorbs.net/A/IN':
1 '173.190.42.208.dnsbl.sorbs.net/A/IN':
1 '178.18.143.94.dnsbl.sorbs.net/A/IN':
1 '18.167.87.216.dnsbl.sorbs.net/A/IN':
1 '19.94.189.91.dnsbl.sorbs.net/A/IN':
1 '202.135.201.205.dnsbl.sorbs.net/A/IN':
3 '212.163.111.63.dnsbl.sorbs.net/A/IN':
1 '23.164.11.209.dnsbl.sorbs.net/A/IN':
1 '236.47.41.192.dnsbl.sorbs.net/A/IN':
1 '243.86.197.70.dnsbl.sorbs.net/A/IN':
1 '36.58.176.166.dnsbl.sorbs.net/A/IN':
1 '48.200.56.41.dnsbl.sorbs.net/A/IN':
2 '54.139.130.12.dnsbl.sorbs.net/A/IN':
1 '57.103.45.66.dnsbl.sorbs.net/A/IN':
1 '73.31.231.89.dnsbl.sorbs.net/A/IN':
1 '79.242.62.166.dnsbl.sorbs.net/A/IN':
1 '8.167.87.216.dnsbl.sorbs.net/A/IN':
1 '96.207.152.107.dnsbl.sorbs.net/A/IN':
2 'ns0.sorbs.net//IN':
2 'ns0.sorbs.net/A/IN':
I really don't want to suppress the syslog entries nor do I not want to
query SORBS, I would just like to figure out why the connection is
refused.
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
09:46:29 up 2 days, 3:55, 2 users, load average: 0.04, 0.08, 0.11
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015
Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 14:08 +, David Jones wrote:
From: Chris cpoll...@embarqmail.com
Sent: Wednesday, May 13, 2015 8:50 AM
To: Jeremy McSpadden
Cc: users@spamassassin.apache.org
Subject: Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 02:05 +, Jeremy McSpadden wrote:
dig +trace and see if your ISP is intercepting queries.
--
Jeremy McSpadden | Flux Labs
Local - 850-250-5590x501 | Mobile - 850-890-2543
Fax - 850-254-2955 | Toll Free - 877-699-FLUX
Web - http://www.fluxlabs.net
Jeremy, I'm replying to you again and Ccing the list which I forgot to
do last night. Below are the results of the above command. I don't see
anywhere my ISP is involved. I've put the output on pastebin so it
doesn't get mangled here on the list dig +trace
54.139.130.12.dnsbl.sorbs.net
http://pastebin.com/up0A2xD1
Dig +trace doesn't work quite like that. It will show you exactly what a
recursive DNS server would do on a client's behalf when doing a full
recursive query to the Internet -- not forwarding to another DNS caching
server. It's very helpful to troubleshoot DNS servers giving bad/stale info
but it's not able to help you see your DNS query flow.
You just have to look at your /etc/resolv.conf to see where it's pointed and
start there. If you aren't sure that the DNS server in /etc/resolv.conf isn't
doing full recursive lookups on it's own, then you need to find one or stand
up your own private DNS server so you know what it's doing for sure.
If you have a high volume of mail (more than a few hundred to a thousand
mailboxes as a rough number), I would recommend setting up your own DNS
recursive server (PowerDNS recursor or BIND) with forwarding disabled. Then
also setup the same thing on each SA mail server but forward to your new
private DNS server, then update the /etc/resolv.conf to point to 127.0.0.1.
SA server (/etc/resolv.conf) - 127.0.0.1 - private DNS server (not
forwarding) - Internet
Chris
On May 12, 2015, at 8:49 PM, Chris cpoll...@embarqmail.com wrote:
Is there a way to turn off queries to SORBS so I don't keep seeing
this
in my logs:
error (connection refused) resolving
'23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53
I have Bind9 setup as a caching name server and am using 127.0.0.1
as my
DNS
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
08:44:59 up 2 days, 2:54, 3 users, load average: 0.20, 0.18, 0.23
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015
David, here is my /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
nameserver 127.0.0.1
search PK5001Z
I only get 100 emails a day, most are directed to the appropriate boxes
by procmail even before they get routed through SA. The rest, maybe 30
or so are either going to be marked as ham or spam by SA.
My /etc/bind/named.conf.options
acl goodclients {
127.0.0.1;
localhost;
localnets;
};
options {
directory /var/cache/bind;
recursion yes;
allow-query { goodclients; };
dnssec-validation auto;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
My /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
dns-nameservers 127.0.0.1
--
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
11:10:30 up 2 days, 5:19, 1 user, load average: 0.08, 0.12, 0.13
Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015
Re: Turning off queries to SORBS
On Wed, 2015-05-13 at 18:59 -0400, Kris Deugau wrote:
Chris wrote:
I'll answer several questions in this post hopefully.
First, the line in my resolv.conf fire search PK5001Z, pertains to my
Zyxel PK5001Z modem, so as a test I've commented out that line in
my /etc/resolv.conf and ran sudo resolvconf -u. If it makes a difference
I'll make the appropriate changes elsewhere to make it permanent.
I'm mildly allergic to resolvconf as it seems to Do The Wrong Thing any
time I've let it have its way. Otherwise your DNS cache appears to be
set up correctly.
The search line is a red herring since it's only used, as David Jones
pointed out, on lookups with a tool like host or dig where you've just
specified a host part.
As far as running something other than Bind, I'd run it for many years
on my old Mandriva box before it crashed. Once I got it up and running
(with some help from the Bind users list) I never had one single
problem.
*nod* I continue to use it on my own server and as a LAN cache because
I'm familiar with it and its minor warts don't cause issue. (And one
arguable misfeature makes certain parts of managing my own LAN DNS a
little simpler.) About all switching would do is give you minor
headaches learning the new configuration, and probably fresh new
confusing log entries.
chris@localhost:~$ grep 'connection refused' /var/log/syslog.1|grep
sorbs|awk '{ print $11; }'|sort|uniq -c
2 113.52.8.150#53
8 174.36.198.233#53
14 174.36.235.174#53
9 67.228.187.34#53
Again, to my untrained eye this shows less info than using $10 in the
awk statement.
From your logs, $10 (the tenth blob of non-whitespace) is the lookup
that was attempted. $11 is the remote server your cache tried first and
got refused by.
That looks like essentially the same list as I found, so it looks like
SORBS has a number of bad servers. I checked the list of nameservers
returned by host -t ns dnsbl.sorbs.net, and I find it curious that
only the first one seems to actually be in that list, but given the
scale they're operating on I can imagine several reasons an apparently
uninvolved IP would be responding for their DNSBL subzone.
There's nothing on your end to do other than fiddle with logging to hide
the noise; so long as what you're looking up in DNS can be found on
another server, your client lookups (either by hand with host, dig,
etc or by eg SpamAssassin) will succeed.
A spam came through a bit ago and this was in the SA markup:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.75.74 listed in dnsbl.sorbs.net]
score RCVD_IN_SORBS_DUL 0 0.001 0 0.001
This is an advisory rule, mainly used in meta rules.
Looking back at my spam folder this was the markup on a spam that came
in earlier today before I made the change to my resolv.conf and
commented out the 'search' line:
0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP
address
[70.197.79.50 listed in dnsbl.sorbs.net]
The output as shown in my syslog is attached which shows
named[1091]: error (connection refused) resolving
'50.79.197.70.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
Your BIND cache tried to look up 50.79.197.70.dnsbl.sorbs.net from
174.36.235.174, but was refused, so it tried another nameserver and got
a response (I get 127.0.0.10 as of writing).
It's not so great that one or more of their nameservers is refusing
queries, but their DNSBL data is served from 13 or more logical servers
as listed by host -t ns dnsbl.sorbs.net, and it's likely there's more
than one physical machine for each of those NS listings.
It's only a problem when a zone only *has* one listed nameserver, or
*all* of the nameservers refuse queries. In that case you can't get an
answer, but otherwise your cache (of any flavour) should walk the list
of nameservers until it gets a response of some kind.
Am I screwed up in the head here and it's working as shown in the markup
above or is the queries to SORBS not working and I need to fix
something?
The problem is with a couple of SORBS nameservers, your cache is just
reporting the problem before retrying the query with another one from
the list. SpamAssassin (or any other client doing a DNS lookup) doesn't
know and doesn't care.
What you're seeing logged by BIND is a transient failure that only slows
down lookups in dnsbl.sorbs.net.
-kgd
I understand now Kris, I guess I've been going on about nothing
basically as like you said if the reply from one server fails it tries
another and so on. I don't mind the logging to syslog and I guess I
should have realized awhile back that not every query in every message
fails but it just didn't hit me that way. I guess this happens when you
get old, little things tend to bother you.
Thanks again
Chris
--
Chris
KeyID
Re: Turning off queries to SORBS
Am 14.05.2015 um 00:59 schrieb Kris Deugau: As far as running something other than Bind, I'd run it for many years on my old Mandriva box before it crashed. Once I got it up and running (with some help from the Bind users list) I never had one single problem. *nod* I continue to use it on my own server and as a LAN cache because I'm familiar with it and its minor warts don't cause issue. (And one arguable misfeature makes certain parts of managing my own LAN DNS a little simpler.) About all switching would do is give you minor headaches learning the new configuration, and probably fresh new confusing log entries well, we operate some hundret doomains using BIND as nameservers, but that don't make it the best caching-only resolver while unbound's cache-min-ttl helps to reduce the outgoing dns queries to spamhaus by ignore the very low TTL and the config is just simple, evem a tuned one like below server: verbosity: 1 statistics-interval: 86400 statistics-cumulative: no extended-statistics: no num-threads: 1 outgoing-range: 1024 num-queries-per-thread: 512 msg-cache-slabs: 8 rrset-cache-slabs: 8 infra-cache-slabs: 8 key-cache-slabs: 8 so-rcvbuf: 4m so-sndbuf: 4m minimal-responses: yes msg-cache-size: 96m neg-cache-size: 96m rrset-cache-size: 192m cache-min-ttl: 600 cache-max-ttl: 10800 interface: 127.0.0.1 access-control: 127.0.0.0/8 allow interface-automatic: no port: 53 do-ip4: yes do-ip6: no do-udp: yes max-udp-size: 1024 edns-buffer-size: 1024 do-tcp: yes do-daemonize: yes username: unbound use-syslog: yes log-time-ascii: yes hide-identity: yes hide-version: yes harden-glue: yes harden-dnssec-stripped: no harden-referral-path: no use-caps-for-id: no unwanted-reply-threshold: 1000 do-not-query-localhost: no prefetch: yes prefetch-key: yes signature.asc Description: OpenPGP digital signature
Re: Turning off queries to SORBS
Am 13.05.2015 um 18:53 schrieb Reindl Harald: Am 13.05.2015 um 18:17 schrieb Chris: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 nameserver 127.0.0.1 search PK5001Z as already suggested days ago REMOVE search PK5001Z because that may end for unqualified queries (missing trailing dot) to first ask whatever.PK5001Z and if they make it to RBL's the reaction likely is refuse further queries because a broken resolver detcted and BTW consider using unbound instead of bind for a caching-only server finally if just some random queries are failing don't bother, the RBLs are a cluster of servers and it happens multiple times each week that barracuda auth servers saying b.barracudacentral.org NXDOMAIN because errors there if you would make a drama for each failing DNS query on a heavy used network you would have a lot to cry - as long as you are not using a forwarder there is not much reason to worry, except your IP itself is on a sorbs blacklist and hence refused - maybe your MX is listed as DUL which is no problem if it is only incoming mail and not intended for sending but a valid reason to reject rbl queries by the policy of the rbl owner signature.asc Description: OpenPGP digital signature
Re: Turning off queries to SORBS
From: Reindl Harald h.rei...@thelounge.net Sent: Wednesday, May 13, 2015 11:53 AM To: users@spamassassin.apache.org Subject: Re: Turning off queries to SORBS Am 13.05.2015 um 18:17 schrieb Chris: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 nameserver 127.0.0.1 search PK5001Z as already suggested days ago REMOVE search PK5001Z because that may end for unqualified queries (missing trailing dot) to first ask whatever.PK5001Z and if they make it to RBL's the reaction likely is refuse further queries because a broken resolver detcted That's not how the search is used in the resolv.conf. It's used when the query contains no dots like a short name. If someone queried for test with that resolv.conf, it would try test.PK5001Z which isn't a valid zone. That doesn't mean a query of example.com would become example.com.PK5001Z like you said above. You are correct about it being a broken query and it should be removed but that isn't causing connection refused errors. You should be pointing to a reliable DNS resolver, like 127.0.0.1 in this case. Then it should either be doing direct lookups or forwarding to a known reliable DNS resolver that is not forwarding to an ISP DNS server like 8.8.8.8. Unbound is a good suggestion. Even dnsmasq would be easy to setup (just disable the DHCP server). Connection refused errors are specific UDP responses from upstream DNS servers that are being denied due to rate limiting, bad query packets, or something that simply ticked off that upstream DNS server. I would point to a different DNS server or disable forwarding on the local DNS cache and do my own recursive lookups and the connection refused messages should go away.
Re: Turning off queries to SORBS
Am 13.05.2015 um 18:17 schrieb Chris: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 nameserver 127.0.0.1 search PK5001Z as already suggested days ago REMOVE search PK5001Z because that may end for unqualified queries (missing trailing dot) to first ask whatever.PK5001Z and if they make it to RBL's the reaction likely is refuse further queries because a broken resolver detcted signature.asc Description: OpenPGP digital signature
Re: Turning off queries to SORBS
Am 13.05.2015 um 19:26 schrieb David Jones: Connection refused errors are specific UDP responses from upstream DNS servers that are being denied due to rate limiting, bad query packets, or something that simply ticked off that upstream DNS server. I would point to a different DNS server or disable forwarding on the local DNS cache and do my own recursive lookups and the connection refused messages should go away if you would follow that thread you would know that the named configuration in the meantime *is* a caching nameserver doing recursion signature.asc Description: OpenPGP digital signature
Re: Turning off queries to SORBS
Chris wrote:
Not upset about the 'noise', to my untrained eye it looks to me as if
the lookups are failing:
chris@localhost:/var/log$ grep 'connection refused' /var/log/syslog|grep
sorbs|awk '{ print $10; }'|sort|uniq -c
1 '11.1.4.96.dnsbl.sorbs.net/A/IN':
1 '114.210.57.173.dnsbl.sorbs.net/A/IN':
1 '139.207.161.25.dnsbl.sorbs.net/A/IN':
1 '183.163.46.207.dnsbl.sorbs.net/A/IN':
1 '54.139.130.12.dnsbl.sorbs.net/A/IN':
2 'aftershock.sorbs.net/A/IN':
2 'cannonball.sorbs.net/A/IN':
2 'ns0.sorbs.net/A/IN':
1 'ns2.sorbs.net//IN':
3 'ns2.sorbs.net/A/IN':
1 'ns4.sorbs.net//IN':
3 'ns4.sorbs.net/A/IN':
The above is just from todays syslog starting at 7:40 this morning.
Try print $11 in the awk (this prints the 11th field or non-whitespace
chunk); that should show the failing server IP instead of the lookup.
Your log seems to have another non-whitespace blob somewhere earlier in
the line compared to mine, where the remote server IP is the 10th field:
May 13 07:52:57 hex named[3790]: connection refused resolving
'130.102.149.83.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
Also try doing the lookups that appear to fail with dig or host, and see
if the actual client lookup succeeds or fails; just because one
nameserver for a zone refused the connection doesn't mean the actual
lookup failed.
I tried the first 5 above plus a couple more from my own log, and all
returned NXDOMAIN - except one lookup took a few seconds to return, so
it probably hit one of those nameservers that's not accepting connections.
I really don't want to suppress the syslog entries nor do I not want to
query SORBS, I would just like to figure out why the connection is
refused.
The particular nameservers refusing connections are either failed or
overloaded. A big DNSBL like SORBS has many nameservers, and it's
likely that each entry from eg dig dnsbl.sorbs.net ns is a cluster of
machines.
-kgd
Turning off queries to SORBS
Is there a way to turn off queries to SORBS so I don't keep seeing this in my logs: error (connection refused) resolving '23.164.11.209.dnsbl.sorbs.net/A/IN': 67.228.187.34#53 I have Bind9 setup as a caching name server and am using 127.0.0.1 as my DNS. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11°N 97.89°W (Elev. 1092 ft) 20:47:11 up 1 day, 14:56, 1 user, load average: 0.66, 0.43, 0.33 Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar 31 02:07:04 UTC 2015
Re: Turning off queries to SORBS
dig +trace and see if your ISP is intercepting queries. -- Jeremy McSpadden | Flux Labs Local - 850-250-5590x501tel:850-250-5590;501 | Mobile - 850-890-2543tel:850-890-2543 Fax - 850-254-2955tel:850-254-2955 | Toll Free - 877-699-FLUXtel:877-699-FLUX Web - http://www.fluxlabs.nethttp://www.fluxlabs.net/ On May 12, 2015, at 8:49 PM, Chris cpoll...@embarqmail.commailto:cpoll...@embarqmail.com wrote: Is there a way to turn off queries to SORBS so I don't keep seeing this in my logs: error (connection refused) resolving '23.164.11.209.dnsbl.sorbs.net/A/IN':http://dnsbl.sorbs.net/A/IN': 67.228.187.34#53 I have Bind9 setup as a caching name server and am using 127.0.0.1 as my DNS. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11?N 97.89?W (Elev. 1092 ft) 20:47:11 up 1 day, 14:56, 1 user, load average: 0.66, 0.43, 0.33 Ubuntu 14.04.2 LTS, kernel 4.0.0-997-generic #201503310205 SMP Tue Mar 31 02:07:04 UTC 2015
Re: SA Sorbs Usage/Rules
On Fri, 2011-12-16 at 13:57 -0500, dar...@chaosreigns.com wrote: Basically, without evidence money is not charged to be delisted from any of those three lists, they're going to stay out of the default rule set. On 17.12.11 12:16, Noel Butler wrote: Lastly, I would have thought SA dev team would have liked to see hard evidence that someone was _forced_ to pay the 50 donation to be delisted, because all I here is the web site says it which frankly doesn't cut it with me, we were nobody special to SORBS, so I can't see why they'd remove us for free but forcibly demand payments from others, the only common ground we had with Matt back then was we were both located in the same city, along with 2 million others. afaik, the request for donating $50 to charity (not paying SORBS! some people did have lied about this) was removed some time ago, and delisting is now done upon request. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. You have the right to remain silent. Anything you say will be misquoted, then used against you.
Re: SA Sorbs Usage/Rules
On Mon, 2011-12-19 at 11:20 +0100, Matus UHLAR - fantomas wrote: On Fri, 2011-12-16 at 13:57 -0500, dar...@chaosreigns.com wrote: Basically, without evidence money is not charged to be delisted from any of those three lists, they're going to stay out of the default rule set. On 17.12.11 12:16, Noel Butler wrote: Lastly, I would have thought SA dev team would have liked to see hard evidence that someone was _forced_ to pay the 50 donation to be delisted, because all I here is the web site says it which frankly doesn't cut it with me, we were nobody special to SORBS, so I can't see why they'd remove us for free but forcibly demand payments from others, the only common ground we had with Matt back then was we were both located in the same city, along with 2 million others. afaik, the request for donating $50 to charity (not paying SORBS! some people did have lied about this) was removed some time ago, and delisting is now done upon request. Paying to charities correct, but hey, you know, some people can't let the facts get in the way of a ruining a good whinge, and you're right, it was my understanding also this was being removed from the website some time ago, but haven't been to check it out so can not comment one way or another. Cheers signature.asc Description: This is a digitally signed message part
SA Sorbs Usage/Rules
I know some of the discussions in the past about usage of Sorbs RBLs
in Spamassassin. The scores today are as follows:
score RCVD_IN_SORBS_BLOCK 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_DUL 0 0.001 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_HTTP 0 2.499 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_MISC 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_SMTP 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_SOCKS 0 2.443 0 1.927 # n=0 n=2
score RCVD_IN_SORBS_WEB 0 0.614 0 0.770 # n=0 n=2
score RCVD_IN_SORBS_ZOMBIE 0 # n=0 n=1 n=2 n=3
The 0-Scores for DUL was done because lot of people thought there
were too much false positives within that (I dont see so, but ok).
Another Argument for 0-Scoring or not using sorbs was that the rbl
contains a lot of old (meaning not actual) entries in the spam
section (in mind of the dislist policy). Ok.
But today I take a deeper look at the sorbs rbls and found, that
there is a very simple misconfigration in the SA rules. The rbl
check is done against the big 'dnsbl.sorbs.net' zone:
eval:check_rbl('sorbs', 'dnsbl.sorbs.net.')
And _that_ in my opinion is wrong. The rbl lookup should be done
against the rbl 'safe.dnsbl.sorbs.net' instead. This rbl is a
compilation of most of the sorbs partial lists as dnsbl.sorbs.net
but with a simple difference: In opposite to dnsl.sorbs.net it
does not contain the 'recent.spam' and the 'old.spam' partial
lists, which are contained in 'dnsbl.sorbs.net'. The only spam
listed in this 'safe.dnsbl.sorbs.net' contains spam of the last
24 hours, so the arguments against using sorbs especially because
of its spam delisting policy do not exist. One could simply change
the rbl lookup to the right zone and so also score spams within
that rbl (low).
Description of the different sorbs partial-zones as of the
aggregate zones here: https://www.sorbs.net/using.shtml
Re: SA Sorbs Usage/Rules
Interesting. Will cross-post to dev and see if anyone has some
input.
On 12/16/2011 12:22 PM, Lutz Petersen wrote:
I know some of the discussions in the past about usage of Sorbs RBLs
in Spamassassin. The scores today are as follows:
score RCVD_IN_SORBS_BLOCK 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_DUL 0 0.001 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_HTTP 0 2.499 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_MISC 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_SMTP 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_SOCKS 0 2.443 0 1.927 # n=0 n=2
score RCVD_IN_SORBS_WEB 0 0.614 0 0.770 # n=0 n=2
score RCVD_IN_SORBS_ZOMBIE 0 # n=0 n=1 n=2 n=3
The 0-Scores for DUL was done because lot of people thought there
were too much false positives within that (I dont see so, but ok).
Another Argument for 0-Scoring or not using sorbs was that the rbl
contains a lot of old (meaning not actual) entries in the spam
section (in mind of the dislist policy). Ok.
But today I take a deeper look at the sorbs rbls and found, that
there is a very simple misconfigration in the SA rules. The rbl
check is done against the big 'dnsbl.sorbs.net' zone:
eval:check_rbl('sorbs', 'dnsbl.sorbs.net.')
And _that_ in my opinion is wrong. The rbl lookup should be done
against the rbl 'safe.dnsbl.sorbs.net' instead. This rbl is a
compilation of most of the sorbs partial lists as dnsbl.sorbs.net
but with a simple difference: In opposite to dnsl.sorbs.net it
does not contain the 'recent.spam' and the 'old.spam' partial
lists, which are contained in 'dnsbl.sorbs.net'. The only spam
listed in this 'safe.dnsbl.sorbs.net' contains spam of the last
24 hours, so the arguments against using sorbs especially because
of its spam delisting policy do not exist. One could simply change
the rbl lookup to the right zone and so also score spams within
that rbl (low).
Description of the different sorbs partial-zones as of the
aggregate zones here: https://www.sorbs.net/using.shtml
--
Kevin A. McGrail
President
Peregrine Computer Consultants Corporation
3927 Old Lee Highway, Suite 102-C
Fairfax, VA 22030-2422
http://www.pccc.com/
703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-359-8451 (fax)
kmcgr...@pccc.com
Re: SA Sorbs Usage/Rules
On 12/16, Lutz Petersen wrote:
I know some of the discussions in the past about usage of Sorbs RBLs
in Spamassassin. The scores today are as follows:
score RCVD_IN_SORBS_BLOCK 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_DUL 0 0.001 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_HTTP 0 2.499 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_MISC 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_SMTP 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_SOCKS 0 2.443 0 1.927 # n=0 n=2
score RCVD_IN_SORBS_WEB 0 0.614 0 0.770 # n=0 n=2
score RCVD_IN_SORBS_ZOMBIE 0 # n=0 n=1 n=2 n=3
The 0-Scores for DUL was done because lot of people thought there
were too much false positives within that (I dont see so, but ok).
Another Argument for 0-Scoring or not using sorbs was that the rbl
contains a lot of old (meaning not actual) entries in the spam
section (in mind of the dislist policy). Ok.
But today I take a deeper look at the sorbs rbls and found, that
there is a very simple misconfigration in the SA rules. The rbl
check is done against the big 'dnsbl.sorbs.net' zone:
eval:check_rbl('sorbs', 'dnsbl.sorbs.net.')
And _that_ in my opinion is wrong. The rbl lookup should be done
against the rbl 'safe.dnsbl.sorbs.net' instead. This rbl is a
compilation of most of the sorbs partial lists as dnsbl.sorbs.net
but with a simple difference: In opposite to dnsl.sorbs.net it
does not contain the 'recent.spam' and the 'old.spam' partial
lists, which are contained in 'dnsbl.sorbs.net'. The only spam
listed in this 'safe.dnsbl.sorbs.net' contains spam of the last
24 hours, so the arguments against using sorbs especially because
of its spam delisting policy do not exist. One could simply change
the rbl lookup to the right zone and so also score spams within
that rbl (low).
Description of the different sorbs partial-zones as of the
aggregate zones here: https://www.sorbs.net/using.shtml
After digging into this a bit, I believe your entire objection is to the
default rule set not handling the 127.0.0.6 return code, used by the
following lists?
new.spam.dnsbl.sorbs.net127.0.0.6
recent.spam.dnsbl.sorbs.net127.0.0.6
old.spam.dnsbl.sorbs.net127.0.0.6
spam.dnsbl.sorbs.net127.0.0.6
escalations.dnsbl.sorbs.net127.0.0.6
The rule for that return code is commented out in the default rule set with
this comment:
# delist: $50 fee for RCVD_IN_SORBS_SPAM, others have free retest on request
Which seems likely to have resulted from this bug:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=2221
Lists returning the 127.0.0.6 code in the safe.dnsbl.sorbs.net agregate
zone are:
new.spam.dnsbl.sorbs.net
recent.spam.dnsbl.sorbs.net
escalations.dnsbl.sorbs.net
new.spam is only hosts from the last 48 hours.
recent.spam is hosts from the last 28 days.
escalations doesn't seem to have a time limit.
So it seems your statement that The only spam listed in this
'safe.dnsbl.sorbs.net' contains spam of the last 24 hours is incorrect.
Basically, without evidence money is not charged to be delisted from any
of those three lists, they're going to stay out of the default rule set.
With the currently enabled default rules, there would be *no* difference
if you changed from dnsbl.sorbs.net to safe.dnsbl.sorbs.net because we're
not using the lists as an aggregate (we don't only have a RCVD_IN_SORBS
rule), but have separate rules for each of the return codes. And there
is no difference in what lists are providing which return codes between
those two aggregate lists other than the 127.0.0.6 (spam) value (which is
disabled).
Also, I wouldn't say the 0 scores were done because lot of people thought
there were too much false positives. The scores are flagged
as mutable, meaning optimal scores are generated daily
using masscheck data. Related statistics can be seen here:
http://ruleqa.spamassassin.org/?daterev=20111210rule=%2Fsorbs
RCVD_IN_SORBS_DUL seems to have a decent hit rate for both spam and ham, so
somehow the score generator just decided the most spams would be caught
without exceeding 1 false positive in 2500 hams with that score. It's not
always clear what exactly it's thinking. It could be, for example,
that almost all of the spam hits from RCVD_IN_SORBS_DUL overlapped with
another blacklist, and the SORBS_DUL list caused more false positives
than that other blacklist, so that other blacklist got a decent score,
and SORBS_DUL didn't. But these scores do not come from the whims
of humans.
--
Anarchy is based on the observation that since few are fit to rule
themselves, even fewer are fit to rule others. -Edward Abbey
http://www.ChaosReigns.com
Re: SA Sorbs Usage/Rules
On Fri, 2011-12-16 at 13:57 -0500, dar...@chaosreigns.com wrote: Basically, without evidence money is not charged to be delisted from any of those three lists, they're going to stay out of the default rule set. Plenty of people can attest to the fact there is no payment taking place, its just a scare tactic to coerce admins to act rather then ignore and hope it sorts itself out. Don't use DNSBL's in SA myself, I use them in MTA (frankly, where they belong). At least under the control of its original owner there wasn't anyway, and yes, we, like most large ISP's, had a couple of times the odd different outbound smtp server listed with them, typically we were alerted of the listing quickly (by use of mon) , a login to the SORBS site for info, and the culprit was identified and we were unlisted in hours, only one time did it take about 24 hours, and, IIRC, that was a holiday season, happy to say not had any my servers listed anywhere that I know of since 2005. Lastly, I would have thought SA dev team would have liked to see hard evidence that someone was _forced_ to pay the 50 donation to be delisted, because all I here is the web site says it which frankly doesn't cut it with me, we were nobody special to SORBS, so I can't see why they'd remove us for free but forcibly demand payments from others, the only common ground we had with Matt back then was we were both located in the same city, along with 2 million others. signature.asc Description: This is a digitally signed message part
Re: How do I get delisted from SORBS? [OT]
On Fri, 22 Apr 2011 18:19:09 -0700 (PDT), maddog2020 landscat...@live.com wrote: Corpus here doesn't seem to understand that your can get blacklisted if you email host puts you on a shared server with a spammer. Therefore, by no fault of your own, you are effectively blacklisted. Furthermore, it is more than likely that the spammer on my shared server does not have an email address or even know about a domain i'm trying to send email to. So because this spammer-1 sends a message that SORBS consider's spam to XYZ.com, ABC.com blocks my email along with anyone else that is hosted on my server eventhough no one at any of the domains hosted on my server intends to spam ABC.com all because they use SORBS and are too lazy to create their own blacklist. What kind of sense does that make? dont know, but i agre ip blacklist will be last resort if postmaster@sender_domain.example.org does not solve it, to many hosts somply host 700 domains on one ip webserver and dont care of ip blacklists or even scan outgoing emails from that WEBSERVER ip suggested is to have diff ip for MAILSERVER and WEBSERVER or atleast scan outgoing mails As for SORBS, the easy way to get delisted and quit whining about how long it takes, is to *not* get listed in the first place. It's really a case of actions have consequences. Not careful in your output, don't expect any sympathy. atleast sorbs have still not listed my own ip as dynamic as spamhaus had for around 2 weeks ago, but it was simple me that used my postmaster @ junc dot org and acted on a respondse email to spamhaus and it was delisted in less then one hour use dnswl.org to help you out with pr domain whitelisting, and then hope sorbs use dnswl my ripe range is listed as mix of mobile dynamic and static ips and on top of that its less then 12 months old range, still keep problems of dns not working since its not unlisted in border routers and dns servers where the range is acl blackholed eg rfc-ignorant.org was not possible to use for my spammassassin, that is resolved now
Re: How do I get delisted from SORBS? [OT]
Corpus here doesn't seem to understand that your can get blacklisted if you email host puts you on a shared server with a spammer. Therefore, by no fault of your own, you are effectively blacklisted. Furthermore, it is more than likely that the spammer on my shared server does not have an email address or even know about a domain i'm trying to send email to. So because this spammer-1 sends a message that SORBS consider's spam to XYZ.com, ABC.com blocks my email along with anyone else that is hosted on my server eventhough no one at any of the domains hosted on my server intends to spam ABC.com all because they use SORBS and are too lazy to create their own blacklist. What kind of sense does that make? As for SORBS, the easy way to get delisted and quit whining about how long it takes, is to *not* get listed in the first place. It's really a case of actions have consequences. Not careful in your output, don't expect any sympathy. -- View this message in context: http://old.nabble.com/How-do-I-get-delisted-from-SORBS---OT--tp29905820p31459742.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Problems with sorbs and this list Fwd: Re: What blacklists are you using at your MTA?
On 03.04.11 21:56, dar...@chaosreigns.com wrote: If you go through the garbage required to register to get to the contents of this link, you'll see that this IP hits two listings, Escalated entries, and DUHL entries, both of which are colored green, which it says means Historical Listings (inactive). But it's still listed: $ host 171.225.210.67.dnsbl.sorbs.net 171.225.210.67.dnsbl.sorbs.net has address 127.0.0.10 - Forwarded message from Jonathan Nichols jnich...@pbp.net - users@spamassassin.apache.org: host mx1.eu.apache.org[192.87.106.230] said: 550 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?67.210.225.171 (in reply to RCPT TO command) - End forwarded message - oh... with 300 TTL we should better not trust you this is NOT dynamic IP. It's one of things mentioned at SORBS page... 171.225.210.67.in-addr.arpa. 300 IN PTR heap.pbp.net. ;; AUTHORITY SECTION: 225.210.67.in-addr.arpa. 300IN NS heap.pbp.net. ;; ADDITIONAL SECTION: heap.pbp.net. 300 IN A 67.210.225.171 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
Problems with sorbs and this list Fwd: Re: What blacklists are you using at your MTA?
Figured I'd forward this along, since he can't post to the list due apparently to this list's use of sorbs. The IP address I got it from was 67.210.225.171. Interestingly, sorbs' website says it's not actively listed, but their DNS zone says otherwise. And their website conveys a general state of brokenness. And requires too damn much personal information to be able to do anything. (I did end up disabling sorbs and enabling psbl at my MTA.) And I don't know anything about this guy or this IP other than what was just emailed to me here. Other than it has a DNSWL rank of low, which could easily mean we know nothing bad about it, but just haven't had enough info to increase its rank. And it has no DNSWL abuse reports. - Forwarded message from Jonathan Nichols jnich...@pbp.net - Date: Sun, 3 Apr 2011 18:45:56 -0500 From: Jonathan Nichols jnich...@pbp.net To: dar...@chaosreigns.com Cc: users@spamassassin.apache.org Subject: Re: What blacklists are you using at your MTA? X-DNSWL: low pbp.net DNSWLId 23144 On Apr 2, 2011, at 8:24 PM, dar...@chaosreigns.com wrote: I'm curious what blacklists other people are currently using at their MTA, rejecting during delivery, before mail gets to spamassassin. For a while I've been using zen.spamhaus.org and dnsbl.sorbs.net. Based on recent stats ( http://ruleqa.spamassassin.org/?daterev=20110319 ) I think I'm dropping sorbs and adding psbl.surriel.com. At the MTA? None at the moment, and I have no idea if this will reach you since SORBS still has my entire netblock incorrectly listed as dynamic and they absolutely refuse to communicate about it - or address the issue. The irony. I cannot write to the Spamassassin list because Apache.org is using SORBS - which is broken and is incorrectly flagging clean IPs still. Thus limiting my ability to communicate with peers and help address the spam problem I have going on.. one that SORBS sure hasn't helped. The IPs that are spamming me? Listed clean in SORBS. :/ - End forwarded message - -- I love God. He's so deliciously evil. - Stewie Griffin, Family Guy 2x02 http://www.ChaosReigns.com
Re: Problems with sorbs and this list Fwd: Re: What blacklists are you using at your MTA?
If you go through the garbage required to register to get to the contents of this link, you'll see that this IP hits two listings, Escalated entries, and DUHL entries, both of which are colored green, which it says means Historical Listings (inactive). But it's still listed: $ host 171.225.210.67.dnsbl.sorbs.net 171.225.210.67.dnsbl.sorbs.net has address 127.0.0.10 - Forwarded message from Jonathan Nichols jnich...@pbp.net - users@spamassassin.apache.org: host mx1.eu.apache.org[192.87.106.230] said: 550 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?67.210.225.171 (in reply to RCPT TO command) - End forwarded message - -- ...this thing we call 'failure' is not the falling down, but the staying down. - Mary Pickford http://www.ChaosReigns.com
Re: Comment - GFI/SORBS
This is a long and somewhat complex story. I've been running my own mail for 15+ years or so, always on a fixed IP. A few years ago business picked up so I got some additional IP's from my supplier (BT); it turned out that they were decommissioned DUL's renewed as statics. Initially we jumped the hoops (both BT I) and after several fraught weeks the issue was resolved. Now we hit November 27th this year, suddenly I'm in SORBS again. Nothing changed this end, same IP, same RIPE entry, same everything... apart from SORBS, who, apparently, redid their db at the end of November. Happily I am now clean and clear. How did I really end up there? I've no real idea, I suspect the reload. I really do appreciate the work RBL's do, mostly; it's a thankless task and if the same wit were applied adversely a lot of money could be made. That they are moral and work as they do makes the life of all legit server admins much easier until they get too rabid. For those of you that supply reliable rbl's, please accept my profound thanks. Some maybe could do better, perhaps those should be carefully judged before inclusion into sa, or perhaps made an optional? All that said, SA isn't the direct problem. Admins blocking purely on, for example, SORBS, should maybe rethink their strategy and adjust scoring on rules within SA. All of the above is my opinion only; I don't think SORBS do a bad job, I just think they could do it better, and maybe accept that we all get it wrong sometimes... Just my 2.5p worth :-D Kind regards Nigel On Tue, 14 Dec 2010 22:41:40 -0500, Jason Bertoch ja...@i6ix.com wrote: On 12/14/2010 8:06 PM, Bart Schaefer wrote: http://blog.wordtothewise.com/2010/12/gfi-sorbs-considered-harmful-part-5/ I've seen the headaches of getting off SORBS, but how did you really end up there? While I agree that SORBS is not reliable enough for use at the MTA level, I've not seen one complaint from my customers over using SORBS in SA. Isn't the beauty of SA the fact that you can score gray areas and not be stuck with black or white? In case it's a mystery, SA scores are automatically generated based on results from the corpus. If those results weren't productive, the rules would either be disabled or their scores adjusted even lower. However, if the corpus isn't representative, the generated scores are in error, and that means we need more trusted submitters. Or maybe your traffic is relatively unique and you should already be generating your own scores? Ultimately, this seems to be more of a witch hunt against SORBS than a SA issue. Although I'm not opposed to a SORBS witch hunt, I don't think it belongs here. /$.02
Re: Comment - GFI/SORBS
On Wed, 15 Dec 2010 07:04:18 +, corpus.defero corpus.def...@idnet.com wrote: Ultimately, this seems to be more of a witch hunt against SORBS than a SA issue. Although I'm not opposed to a SORBS witch hunt, I don't think it belongs here. Indeed, and it's Lynford and his money grabbing cronies mostly behind it - hence it lacks sophistication. I guess we all have our opinions based on our experiences. Personally, I've had no issue with zen, though cbl does seem sometimes to have an issue with back-scatter. That said, proper spf should help stop back-scatter. Kind regards Nigel
Comment - GFI/SORBS
Hi All, Is sorbs going to be continued as a scoring option in SA? Having hit yet more problems with them I've zeroed their scoring. I found this a couple of days ago, maybe it can add weight. http://blog.wordtothewise.com/2010/12/gfi-sorbs-considered-harmful/ Best to all Nigel
Re: Comment - GFI/SORBS
On Tue, 2010-12-14 at 16:58 +, Nigel Frankcom wrote: Hi All, Is sorbs going to be continued as a scoring option in SA? Having hit yet more problems with them I've zeroed their scoring. ... I hope so. I find SORBS wonderful in dealing with those troublesome mailers that have managed to by passage from the likes of $pamhau$$ and Barracuda myself. That said, I'd like to see the total removal of rules that favour that haven of transactional spammers - Return Path.
Re: Comment - GFI/SORBS
http://blog.wordtothewise.com/2010/12/gfi-sorbs-considered-harmful-part-5/
Re: Comment - GFI/SORBS
On 12/14/2010 8:06 PM, Bart Schaefer wrote: http://blog.wordtothewise.com/2010/12/gfi-sorbs-considered-harmful-part-5/ I've seen the headaches of getting off SORBS, but how did you really end up there? While I agree that SORBS is not reliable enough for use at the MTA level, I've not seen one complaint from my customers over using SORBS in SA. Isn't the beauty of SA the fact that you can score gray areas and not be stuck with black or white? In case it's a mystery, SA scores are automatically generated based on results from the corpus. If those results weren't productive, the rules would either be disabled or their scores adjusted even lower. However, if the corpus isn't representative, the generated scores are in error, and that means we need more trusted submitters. Or maybe your traffic is relatively unique and you should already be generating your own scores? Ultimately, this seems to be more of a witch hunt against SORBS than a SA issue. Although I'm not opposed to a SORBS witch hunt, I don't think it belongs here. /$.02 -- /Jason
Re: Comment - GFI/SORBS
Ultimately, this seems to be more of a witch hunt against SORBS than a SA issue. Although I'm not opposed to a SORBS witch hunt, I don't think it belongs here. Indeed, and it's Lynford and his money grabbing cronies mostly behind it - hence it lacks sophistication.
Re: How do I get delisted from SORBS? [OT]
corpus.defero wrote: On Fri, 2010-10-08 at 20:13 +0200, Per Jessen wrote: corpus.defero wrote: On Thu, 2010-10-07 at 08:56 -1000, Alexandre Chapellon wrote: Indeed no IP should be blacklisted undefinitely... at least without checking regularily. I don't agree. An IP that hops on and off lists should stay ON until the blocklist operator is satisfied that no further abuse will come from it. How does that differ from what Alexandre said? It differs because I am saying they *should* remain listed forever. Actually, as far as I can tell, you said until the blocklist operator is satisfied that no further abuse will come from it which is clearly not forever. Personally if I were running the show I'd seek a large deposit to remove an IP and any repeat would result in the loss of that deposit with no further chance to remove the IP until it was clearly and demonstrably reassigned. I doubt if a list with such a policy would be of much interest to anyone. Just my opinion, of course. /Per Jessen, Zürich
Re: How do I get delisted from SORBS? [OT]
On Sat, 2010-10-09 at 15:58 +0200, Per Jessen wrote: corpus.defero wrote: On Fri, 2010-10-08 at 20:13 +0200, Per Jessen wrote: corpus.defero wrote: On Thu, 2010-10-07 at 08:56 -1000, Alexandre Chapellon wrote: Indeed no IP should be blacklisted undefinitely... at least without checking regularily. I don't agree. An IP that hops on and off lists should stay ON until the blocklist operator is satisfied that no further abuse will come from it. How does that differ from what Alexandre said? It differs because I am saying they *should* remain listed forever. Actually, as far as I can tell, you said until the blocklist operator is satisfied that no further abuse will come from it which is clearly not forever. No, in my clarification I have been precise and clear and said: I am saying they *should* remain listed forever Really, I cannot be any more exact than that. This is all OT for a Spamassassin. If you want to bitch about blocklists why not do it on SPAM-L or at NANAE?
Re: How do I get delisted from SORBS? [OT]
corpus.defero wrote: This is all OT for a Spamassassin. If you want to bitch about blocklists why not do it on SPAM-L or at NANAE? I'm not bitching about anything. /Per Jessen, Zürich
Re: How do I get delisted from SORBS? [OT]
On Thu, 2010-10-07 at 05:27 -0700, Marc Perkel wrote: Got this listing on sorbs: SORBS DNSBL http://www.de.sorbs.net/ 127.0.0.2 Aggregate zone See: http://www.sorbs.net/lookup.shtml?65.49.42.106; http://www.de.sorbs.net/overview.shtml Went to their web site and can't find a way to remove it. Their web site is barely responsive and there doesn't seem to be a removal tool. Anyone else having this problem or can give me some insight as to what is going on? If you create a support ticket they respond ( usually within a month :-) ) and most likely delist the ip address. The problem with sorbs is that they take unreasonably long time to list or delist I have had machines listed because of relaying spams due to bad passwords. While the listing itself is quiet reasonable .. SORBS seems to notice the oubreak only a month after the spam outbreak happened and was stopped. Thanks Ram
Re: How do I get delisted from SORBS? [OT]
On Thu, 2010-10-07 at 08:56 -1000, Alexandre Chapellon wrote: on getting delisted at SORBS. At least they give a time window :) Try to know why you're listed at barracuda: This is true pain! This is not correct. Barracuda offer a 24 hour phone service when you can speak to a real person should you have an issue. Getting delisted is simple but ongoing offenders can simply forget it. Indeed no IP should be blacklisted undefinitely... at least without checking regularily. I don't agree. An IP that hops on and off lists should stay ON until the blocklist operator is satisfied that no further abuse will come from it. Hoping on and off as spammers/esp's run around a ring of IP's for a few weeks defeats the point somewhat. As for SORBS, the easy way to get delisted and quit whining about how long it takes, is to *not* get listed in the first place. It's really a case of actions have consequences. Not careful in your output, don't expect any sympathy.
Re: How do I get delisted from SORBS? [OT]
corpus.defero wrote: On Thu, 2010-10-07 at 08:56 -1000, Alexandre Chapellon wrote: Indeed no IP should be blacklisted undefinitely... at least without checking regularily. I don't agree. An IP that hops on and off lists should stay ON until the blocklist operator is satisfied that no further abuse will come from it. How does that differ from what Alexandre said? As for SORBS, the easy way to get delisted and quit whining about how long it takes, is to *not* get listed in the first place. Which is clearly not to get *delisted*, but to avoid having the need to be. It's really a case of actions have consequences. Not careful in your output, don't expect any sympathy. Well, in this case, SORBS screwed up royally, so consequence = don't use them? /Per Jessen, Zürich
Re: How do I get delisted from SORBS? [OT]
Le vendredi 08 octobre 2010 à 18:55 +0100, corpus.defero a écrit : On Thu, 2010-10-07 at 08:56 -1000, Alexandre Chapellon wrote: on getting delisted at SORBS. At least they give a time window :) Try to know why you're listed at barracuda: This is true pain! This is not correct. Barracuda offer a 24 hour phone service when you can speak to a real person should you have an issue. Getting delisted is simple but ongoing offenders can simply forget it. Cool! Calling some indian call center to get an idea of why one single IP is listed What a great tool! Indeed no IP should be blacklisted undefinitely... at least without checking regularily. I don't agree. An IP that hops on and off lists should stay ON until the blocklist operator is satisfied that no further abuse will come from it. until the blocklist operator is satisfied... That's exactly what I said. Barracuda was listing more than 8000 of my IPs. Thoose IP was listed years ago and never unlisted. Port 25 was blocked for months for this subnets and Barracuda explicitly refused to do bulk removal ... because it was too much wrok for them... We had to hire someone to manually delist filling their form (with captcha). Now manual delisting is over for weeks and *none* of the delisted IPs has been listed again... Yes am a bit angry against barracuda issue handling :). Hoping on and off as spammers/esp's run around a ring of IP's for a few weeks defeats the point somewhat. As for SORBS, the easy way to get delisted and quit whining about how long it takes, is to *not* get listed in the first place. It's really a case of actions have consequences. Not careful in your output, don't expect any sympathy. -- Follow us on: twitter https://www.twitter.com/manainternet
Re: How do I get delisted from SORBS? [OT]
On Fri, 2010-10-08 at 08:19 -1000, Alexandre Chapellon wrote: This is not correct. Barracuda offer a 24 hour phone service when you can speak to a real person should you have an issue. Getting delisted is simple but ongoing offenders can simply forget it. Cool! Calling some indian call center to get an idea of why one single IP is listed What a great tool! Err, it's *not* an Indian call centre. They have a support office in India, but the majority of calls are handled in the USA and UK - and they operate around the clock 'following the sun'. The only time India would handle a call is if (a) something went very wrong (b) you were located in India seeking service in India. Barracuda are *very* good at reputation lists - one of the best for all their other failings. They can easily tell you the extent of your spamming and support it with evidence. If you've got listed at Barracuda *YOU HAVE SENT SPAM* so quit bleating. Barracuda was listing more than 8000 of my IPs. Thoose IP was listed years ago and never unlisted. Port 25 was blocked for months for this subnets and Barracuda explicitly refused to do bulk removal ... because it was too much wrok for them... We had to hire someone to manually delist filling their form (with captcha). Now manual delisting is over for weeks and *none* of the delisted IPs has been listed again... Yes am a bit angry against barracuda issue handling :). Don't spam then. Simple. I think you've mistaken me for someone that gives a damn.
Re: How do I get delisted from SORBS? [OT]
On Fri, 2010-10-08 at 20:13 +0200, Per Jessen wrote: corpus.defero wrote: On Thu, 2010-10-07 at 08:56 -1000, Alexandre Chapellon wrote: Indeed no IP should be blacklisted undefinitely... at least without checking regularily. I don't agree. An IP that hops on and off lists should stay ON until the blocklist operator is satisfied that no further abuse will come from it. How does that differ from what Alexandre said? It differs because I am saying they *should* remain listed forever. Personally if I were running the show I'd seek a large deposit to remove an IP and any repeat would result in the loss of that deposit with no further chance to remove the IP until it was clearly and demonstrably reassigned. Hopefully my take on it, and how it differs is now clear for you. Warm regards
Re: How do I get delisted from SORBS? [OT]
It differs because I am saying they *should* remain listed forever. False positives are far worst than false negatives for businesses. Some blacklists do not tolerate a FP of more than 1%. Blacklists are behind the line as they don't fight zero-hour attacks, and the only reason why blacklists are appeasing is really their low FP rate. This is why Google made a blacklist to fight phish and malware --- Google wanted FP that is well below 1% (0.04% IIRC) A blacklist with high FP, such as SORBS, is no use. We'd better use heuristics, at least we can fight zero hour attacks with = FP rate. My 0.02. --- Mahmoud Khonji
Re: How do I get delisted from SORBS? [OT]
Hello Marc Perkel, Am 2010-10-07 05:27:39, hacktest Du folgendes herunter: Got this listing on sorbs: SORBS DNSBL http://www.de.sorbs.net/ 127.0.0.2 Aggregate zone See: http://www.sorbs.net/lookup.shtml?65.49.42.106; http://www.de.sorbs.net/overview.shtml Went to their web site and can't find a way to remove it. Their web site is barely responsive and there doesn't seem to be a removal tool. Anyone else having this problem or can give me some insight as to what is going on? Send a drone with a nuclear warhead to there DataCenter! :-D Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsyst...@tdnet France EURL itsyst...@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature
How do I get delisted from SORBS? [OT]
Got this listing on sorbs: SORBS DNSBL http://www.de.sorbs.net/ 127.0.0.2 Aggregate zone See: http://www.sorbs.net/lookup.shtml?65.49.42.106; http://www.de.sorbs.net/overview.shtml Went to their web site and can't find a way to remove it. Their web site is barely responsive and there doesn't seem to be a removal tool. Anyone else having this problem or can give me some insight as to what is going on? -- Marc Perkel - Sales/Support supp...@junkemailfilter.com http://www.junkemailfilter.com Junk Email Filter dot com 415-992-3400
Re: How do I get delisted from SORBS? [OT]
Marc Perkel wrote: Got this listing on sorbs: SORBS DNSBL http://www.de.sorbs.net/ 127.0.0.2 Aggregate zone See: http://www.sorbs.net/lookup.shtml?65.49.42.106; http://www.de.sorbs.net/overview.shtml host 106.42.49.65.dnsbl.sorbs.net. 106.42.49.65.dnsbl.sorbs.net has address 127.0.0.10 127.0.0.10 - dynamic address Something's clearly not quite right at SORBS. /Per Jessen, Zürich
Re: How do I get delisted from SORBS? [OT]
On 10/7/2010 6:42 AM, Per Jessen wrote: Marc Perkel wrote: Got this listing on sorbs: SORBS DNSBLhttp://www.de.sorbs.net/ 127.0.0.2 Aggregate zone See: http://www.sorbs.net/lookup.shtml?65.49.42.106; http://www.de.sorbs.net/overview.shtml host 106.42.49.65.dnsbl.sorbs.net. 106.42.49.65.dnsbl.sorbs.net has address 127.0.0.10 127.0.0.10 - dynamic address Something's clearly not quite right at SORBS. /Per Jessen, Zürich The Sorbs web site is broken too. Can't get to any delisting pages. Running very slow and lots of errors. Sorbs is definitely broken today. -- Marc Perkel - Sales/Support supp...@junkemailfilter.com http://www.junkemailfilter.com Junk Email Filter dot com 415-992-3400
Re: How do I get delisted from SORBS? [OT]
* Marc Perkel supp...@junkemailfilter.com: Got this listing on sorbs: SORBS DNSBL http://www.de.sorbs.net/ 127.0.0.2 Aggregate zone See: http://www.sorbs.net/lookup.shtml?65.49.42.106; http://www.de.sorbs.net/overview.shtml I feel your pain. Went to their web site and can't find a way to remove it. Their web site is barely responsive and there doesn't seem to be a removal tool. Anyone else having this problem or can give me some insight as to what is going on? No idea. We also got listed and can't even find out why. It says last occurence somedate.in.2006 - WTF? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: How do I get delisted from SORBS? [OT]
* Marc Perkel supp...@junkemailfilter.com: Got this listing on sorbs: On 07.10.10 16:33, Ralf Hildebrandt wrote: No idea. We also got listed and can't even find out why. It says last occurence somedate.in.2006 - WTF? our ranges that have been removed from DUHL years ago got there again. Probably old records re-appeared because of something... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I wonder how much deeper the ocean would be without sponges.
Re: How do I get delisted from SORBS? [OT]
On 10/7/2010 7:56 AM, Matus UHLAR - fantomas wrote: * Marc Perkelsupp...@junkemailfilter.com: Got this listing on sorbs: On 07.10.10 16:33, Ralf Hildebrandt wrote: No idea. We also got listed and can't even find out why. It says last occurence somedate.in.2006 - WTF? our ranges that have been removed from DUHL years ago got there again. Probably old records re-appeared because of something... Sure is screwing me up. Got several customers whose email is bouncing when we are forward it as good. I'm disabling all sorbs tests on my end to prevent false positives. -- Marc Perkel - Sales/Support supp...@junkemailfilter.com http://www.junkemailfilter.com Junk Email Filter dot com 415-992-3400
SORBS is definitely hosed today
Not sure what is happening but they appear to be down and when they are up they have a lot of people blacklists that shouldn't be. I noticed that this list uses sorbs and the admins might want to disable it. I don't know what's happening but I wish them the best.
Re: SORBS is definitely hosed today
I can't see any problem right now with SORBS... is it related to a specific Sorbs DNSBL? Le jeudi 07 octobre 2010 à 09:09 -0700, Marc Perkel a écrit : Not sure what is happening but they appear to be down and when they are up they have a lot of people blacklists that shouldn't be. I noticed that this list uses sorbs and the admins might want to disable it. I don't know what's happening but I wish them the best. -- Follow us on: twitter https://www.twitter.com/manainternet
Re: SORBS is definitely hosed today
On Thu, 2010-10-07 at 08:29 -1000, Alexandre Chapellon wrote:
I can't see any problem right now with SORBS... is it related to a
specific Sorbs DNSBL?
Le jeudi 07 octobre 2010 à 09:09 -0700, Marc Perkel a écrit :
Not sure what is happening but they appear to be down and when they
are up they have a lot of people blacklists that shouldn't be. I noticed
that this list uses sorbs and the admins might want to disable it.
I don't know what's happening but I wish them the best.
http://isc.sans.edu/diary.html?storyid=9685
In particular, note the second comment, by Michelle.
We have experienced a DDoS attack today which was 'smart' we have
mitigated it so the site is now operational if a user waits about
10-15 seconds for the response.
We have had reports that we have a database corruption, there is no
evidence of that but to be safe we have emptied the DNS zone files and
the rsync files until we can check the database for any possible
errors. We expect this to be complete within 24 hours.
--
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: How do I get delisted from SORBS? [OT]
Le jeudi 07 octobre 2010 à 16:33 +0200, Ralf Hildebrandt a écrit : * Marc Perkel supp...@junkemailfilter.com: Got this listing on sorbs: SORBS DNSBL http://www.de.sorbs.net/ 127.0.0.2 Aggregate zone See: http://www.sorbs.net/lookup.shtml?65.49.42.106; http://www.de.sorbs.net/overview.shtml I feel your pain. Went to their web site and can't find a way to remove it. Their web site is barely responsive and there doesn't seem to be a removal tool. Anyone else having this problem or can give me some insight as to what is going on? No idea. We also got listed and can't even find out why. It says last occurence somedate.in.2006 - WTF? At least they give a time window :) Try to know why you're listed at barracuda: This is true pain! Indeed no IP should be blacklisted undefinitely... at least without checking regularily. -- Follow us on: twitter https://www.twitter.com/manainternet
The SORBS problem explained
There's a good article just popped up on The Register about the SORBS problem. It mostly seems to have come from a conversation with Michelle Sullivan. It gives details of what happened and why and points out that the DOS attack happened to coincide with the problem but didn't cause it. http://www.theregister.co.uk/2010/10/07/sorbs_cockup/ Martin
Re: [OT] was SORBS
Lee Dilkie wrote: First, I'd like to point out that not everyone has the option of changing ISP's. Believe it or not, there are many folks who have only one choice for high-speed internet access (myself included). The choice of ISP for your client connection is unrelated to the choice of ISP for your outgoing email. You always have the option of renting a server on the net and sending the email from there. There are many very cost effective plans available. Use a low cost server with a static IP on the net to relay mail from your dynamic addresses. Second. The fact that a mail server rejects, outright, based on something so false-positivity as a db for dynamic ip's is irresponsible on the part of the admin. Sure, add some spammy points and do a scan but an outright rejection? I hard reject all incoming mail from addresses identified as belonging to dynamic address pools. Bob
Re: [OT] was SORBS
- Original Message - On Fri, 2010-04-30 at 16:50 +0100, Nigel Frankcom wrote: We're on a BT only exchange here so it's them or nothing, well not quite, I could go CoLo... hmmm maybe not, or satellite, I was involved in setting that up in Cyprus. Nigel Is there such a thing? I appreciate many are not unbundled, but the BTW agreement means you should have no problems getting a wires-only with someone like Zen, IDNET or Newnet. Believe me, the service just pee's over BT. I was with IDNET and they were awesome. Only reason why I moved to Xilo was to lower my monthly costs. CW unbundled has been really good. If cost is not a factor I would always recommend IDNET over anybody else! They do still manage my BT line :) -- Thanks, Phil
[OT] was SORBS
Here's the chuckle Mail transport error, MTSPro SMTP Relay Agent could not deliver the following message for users@spamassassin.apache.org. Reason: 550 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?217.36.54.209 --==-- Original Message Headers Follow --==-- Received: from snakepit.bleh (snakepit.bleh [192.168.2.32]) by blue-canoe.org.uk (envelope-sender ni...@blue-canoe.com) with ESMTPA (MTSPro MTSSmtp 1.61) for users@spamassassin.apache.org; Fri, 30 Apr 2010 11:25:10 +0100 From: Nigel Frankcom ni...@blue-canoe.com To: SpamAssassin users@spamassassin.apache.org Subject: [OT] Was SORBS Date: Fri, 30 Apr 2010 11:25:09 +0100 Organization: Blue Canoe Networks Message-ID: kfblt5t3h1mksks6taaa9r1kohe1psj...@blue-canoe.net X-Mailer: Forte Agent 6.00/32.1186 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Abuse-Report-URL: http://www.blue-canoe.net/abuse X-Envelope-Sender: ni...@blue-canoe.com X-Envelope-Receiver: users@spamassassin.apache.org Here's my message :-D Hi All, First a big thanks to all those who offered advice and actively assisted in getting my SORBS problem resolved. BT have admitted they screwed things up with SORBS a while ago and, at least on an individual level, regret that. That aside, they have worked hard and with patience and professionalism to help me get this resolved. For those of you with BT accounts that find yourself in the same situation, give me a shout and I'll happily pass on the info for the people and departments I worked with... Someone may read the archives :-D Once again, thanks one and all for your help and support (and to the list admins for not yelling at me to say this had nothing to do with SA :-D) Cheers all Nigel
Re: [OT] was SORBS
On Fri, 2010-04-30 at 11:46 +0100, n.frank...@gmail.com wrote: Here's the chuckle Mail transport error, MTSPro SMTP Relay Agent could not deliver the following message for users@spamassassin.apache.org. Reason: 550 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?217.36.54.209 And has it taken you all that time to get BT to add this to their whois: descr: Single Static IP Addresses Man, that is quality service. I take it you've spoken with phone: +44 207 777 7766 fax-no: +44 1524 34523 e-mail: steve.r.wri...@bt.com e-mail: ab...@bt.net remarks:trouble: 1st Line Support remarks:Please send delisting issues to btnet...@bt.net ... and they have actually spoken with SORBS? The old bucket still holds water. It is your ISP that needs to resolve this - as a customer you can do nothing. Really they should have dealt with this a long time ago. I've lost track of it, is this two weeks later now? Really - you should sack your ISP and go to someone competent. You may fair better taking this to the SPAM-L mailing list where you may find someone that actually cares. Here you will only get generic opinion and nothing tangible to help. Spam-l mailing list - http://spam-l.com/mailman/listinfo/spam-l
Re: [OT] was SORBS
On 4/30/2010 7:43 AM, corpus.defero wrote: On Fri, 2010-04-30 at 11:46 +0100, n.frank...@gmail.com wrote: Here's the chuckle Mail transport error, MTSPro SMTP Relay Agent could not deliver the following message for users@spamassassin.apache.org. Reason: 550 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?217.36.54.209 The old bucket still holds water. It is your ISP that needs to resolve this - as a customer you can do nothing. Really they should have dealt with this a long time ago. I've lost track of it, is this two weeks later now? Really - you should sack your ISP and go to someone competent. First, I'd like to point out that not everyone has the option of changing ISP's. Believe it or not, there are many folks who have only one choice for high-speed internet access (myself included). Second. The fact that a mail server rejects, outright, based on something so false-positivity as a db for dynamic ip's is irresponsible on the part of the admin. Sure, add some spammy points and do a scan but an outright rejection? -lee
Re: [OT] was SORBS
On Fri, 2010-04-30 at 08:43 -0400, Lee Dilkie wrote: On 4/30/2010 7:43 AM, corpus.defero wrote: On Fri, 2010-04-30 at 11:46 +0100, n.frank...@gmail.com wrote: Here's the chuckle Mail transport error, MTSPro SMTP Relay Agent could not deliver the following message for users@spamassassin.apache.org. Reason: 550 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?217.36.54.209 The old bucket still holds water. It is your ISP that needs to resolve this - as a customer you can do nothing. Really they should have dealt with this a long time ago. I've lost track of it, is this two weeks later now? Really - you should sack your ISP and go to someone competent. First, I'd like to point out that not everyone has the option of changing ISP's. Believe it or not, there are many folks who have only one choice for high-speed internet access (myself included). Second. The fact that a mail server rejects, outright, based on something so false-positivity as a db for dynamic ip's is irresponsible on the part of the admin. Sure, add some spammy points and do a scan but an outright rejection? -lee Without wishing to come accross rude. I accept your points as they are, in part, valid. But; 1. In this case the OP has a choice and has elected to trust a notoriously awful former state owned ISP to deal with it. 2. No mail server rejects based on SORBS. It rejected where admins choose to implement SORBS at an SMTP level. Doing so they are usually well aware of the caveats of using SORBS. 3. This is all irrelevant to the Spamassassin list. Like I say there may be some opinion here, there may be mixed advice here, but there is no resolution or listening ear here. Michelle 'listens' to NANAE and SPAM-L last time I checked, but again it's an issue for BT to deal with. The fact the OP has to go around chasing this is a clear indication of failure of his ISP. It's blunt, but it's really that simple.
Re: [OT] was SORBS
On Fri, 2010-04-30 at 08:43 -0400, Lee Dilkie wrote: First, I'd like to point out that not everyone has the option of changing ISP's. Believe it or not, there are many folks who have only one choice for high-speed internet access (myself included). However, that doesn't apply to the OP, who is using British Telecom as his ISP. My broadband connection goes through the local BT exchange and copper after that, but BT has never been my ISP. I initially used Demon as my ISP, switching to my current ISP (who subcontract broadband connectivity to a third party, *not* BT) when I discovered that Demon didn't offer a suitable package that included domain registration. The OP can do exactly what I did. Out of pure curiosity, what is there about the broadband set-up in your locality that could prevent you from doing something similar? Are both your broadband provider and your ISP monopolies? Martin
Re: [OT] was SORBS
On 4/30/10 8:22 AM, Martin Gregorie mar...@gregorie.org wrote: On Fri, 2010-04-30 at 08:43 -0400, Lee Dilkie wrote: First, I'd like to point out that not everyone has the option of changing ISP's. Believe it or not, there are many folks who have only one choice for high-speed internet access (myself included). However, that doesn't apply to the OP, who is using British Telecom as his ISP. My broadband connection goes through the local BT exchange and copper after that, but BT has never been my ISP. I initially used Demon as my ISP, switching to my current ISP (who subcontract broadband connectivity to a third party, *not* BT) when I discovered that Demon didn't offer a suitable package that included domain registration. The OP can do exactly what I did. Out of pure curiosity, what is there about the broadband set-up in your locality that could prevent you from doing something similar? Are both your broadband provider and your ISP monopolies? For me, it was the case the last time I renegotiated my contract for my business-class broadband at home. Short of bringing in a T1 at $600-$1000/month, I had exactly one choice for a provider that would provide me with a static /29 and a SWIP record - the monopoly cable provider. In another year or so I'll see if the monopoly POTS provider can provide the service I need - they promise the moon in their advertisements but balk really fast when you start to ask specific, tangible questions. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: [OT] was SORBS
On Fri, 2010-04-30 at 10:10 -0500, Daniel McDonald wrote: On 4/30/10 8:22 AM, Martin Gregorie mar...@gregorie.org wrote: On Fri, 2010-04-30 at 08:43 -0400, Lee Dilkie wrote: First, I'd like to point out that not everyone has the option of changing ISP's. Believe it or not, there are many folks who have only one choice for high-speed internet access (myself included). However, that doesn't apply to the OP, who is using British Telecom as his ISP. My broadband connection goes through the local BT exchange and copper after that, but BT has never been my ISP. I initially used Demon as my ISP, switching to my current ISP (who subcontract broadband connectivity to a third party, *not* BT) when I discovered that Demon didn't offer a suitable package that included domain registration. The OP can do exactly what I did. Out of pure curiosity, what is there about the broadband set-up in your locality that could prevent you from doing something similar? Are both your broadband provider and your ISP monopolies? For me, it was the case the last time I renegotiated my contract for my business-class broadband at home. Short of bringing in a T1 at $600-$1000/month, I had exactly one choice for a provider that would provide me with a static /29 and a SWIP record - the monopoly cable provider. In another year or so I'll see if the monopoly POTS provider can provide the service I need - they promise the moon in their advertisements but balk really fast when you start to ask specific, tangible questions. I have a number of friends who concur that the US small-business broadband scene is seriously poor so I feel your pain. I can remember the hassle one guy had trying to get a static IP out of Warners. They wanted to up his subscription by a factor of three. In the UK we are really lucky in most cases that we can pick and choose good providers and change fairly easily without it costing an arm and a leg.
Re: [OT] was SORBS
On Fri, 30 Apr 2010 14:22:16 +0100, Martin Gregorie mar...@gregorie.org wrote: On Fri, 2010-04-30 at 08:43 -0400, Lee Dilkie wrote: First, I'd like to point out that not everyone has the option of changing ISP's. Believe it or not, there are many folks who have only one choice for high-speed internet access (myself included). However, that doesn't apply to the OP, who is using British Telecom as his ISP. My broadband connection goes through the local BT exchange and copper after that, but BT has never been my ISP. I initially used Demon as my ISP, switching to my current ISP (who subcontract broadband connectivity to a third party, *not* BT) when I discovered that Demon didn't offer a suitable package that included domain registration. The OP can do exactly what I did. Out of pure curiosity, what is there about the broadband set-up in your locality that could prevent you from doing something similar? Are both your broadband provider and your ISP monopolies? Martin We're on a BT only exchange here so it's them or nothing, well not quite, I could go CoLo... hmmm maybe not, or satellite, I was involved in setting that up in Cyprus. I guess the bottom line is that this is always going to be an issue and it's as much to do with how you deal with your upline suppliers as how you deal with the lists (rbl etc). I may not agree with them all on an individual basis, but life is what it is, I have to work within the constraints imposed on me. I cannot complain about SORBS, though I did, they have a fixed set of rules. If I or my upline provider fails.. well, such is life. BT for what it's worth are very aware of their market and the issues, with luck they and SORBS will open a dialogue. As admins we face and deal with issues every day, sometimes it's nice to know that others out there are listening and, where they can, acting. I have a lot of karma to repay :-D Now, if the SA list would let me post from 'home'. I'd be copacetic :-D All the best Nigel
Re: [OT] was SORBS
On Fri, 2010-04-30 at 16:50 +0100, Nigel Frankcom wrote: We're on a BT only exchange here so it's them or nothing, well not quite, I could go CoLo... hmmm maybe not, or satellite, I was involved in setting that up in Cyprus. Nigel Is there such a thing? I appreciate many are not unbundled, but the BTW agreement means you should have no problems getting a wires-only with someone like Zen, IDNET or Newnet. Believe me, the service just pee's over BT.
Re: [OT] was SORBS
On Fri, 30 Apr 2010 16:59:57 +0100, corpus.defero corpus.def...@idnet.com wrote: On Fri, 2010-04-30 at 16:50 +0100, Nigel Frankcom wrote: We're on a BT only exchange here so it's them or nothing, well not quite, I could go CoLo... hmmm maybe not, or satellite, I was involved in setting that up in Cyprus. Nigel Is there such a thing? I appreciate many are not unbundled, but the BTW agreement means you should have no problems getting a wires-only with someone like Zen, IDNET or Newnet. Believe me, the service just pee's over BT. Fair point. I live in a small village right on the end of a spur. After being burgled at my town offices I moved the whole dammed shebang home and now run it from my own server room. BT may not be the best, but they (or rather OpenReach) own the lines, exchange and pretty much all else... plus they have helped. If I go through a third party I end up with at least one more level of 'have you re-booted your router' etc. Bottom line, I'd rather solve a problem than work round it. As it happens I have a second IP off the range that I could have used, but that would have meant a lot of DNS work etc (and DNS and I are not good friends). IMHO solving is better than blaming. My original post was a request for advice and help. I got a lot of both... plus a lot of opinion. Kind regards Nigel
Re: [OT] was SORBS
On Fri, 2010-04-30 at 17:19 +0100, Nigel Frankcom wrote:
On Fri, 30 Apr 2010 16:59:57 +0100, corpus.defero
corpus.def...@idnet.com wrote:
On Fri, 2010-04-30 at 16:50 +0100, Nigel Frankcom wrote:
We're on a BT only exchange here so it's them or nothing, well not
quite, I could go CoLo... hmmm maybe not, or satellite, I was involved
in setting that up in Cyprus.
Nigel
Is there such a thing? I appreciate many are not unbundled, but the BTW
agreement means you should have no problems getting a wires-only with
someone like Zen, IDNET or Newnet. Believe me, the service just pee's
over BT.
Fair point. I live in a small village right on the end of a spur.
After being burgled at my town offices I moved the whole dammed
shebang home and now run it from my own server room.
There is nothing wrong with that - it makes good environmental sense as
well as security sense.
BT may not be the best, but they (or rather OpenReach) own the lines,
exchange and pretty much all else... plus they have helped.
Having spent 16 years with them I know the ins and outs. Openreach were
not allowed to show any favouritism to BT customers and went out of
their way for 'other licensed operators'. Many BT folk of X years
service found the notion of Openreach rather unpalatable and went out of
their way to be awkward to native BT customers. I'm not sure if that
attitude subset still exists but there really was an attitude towards
all things BT. But good on your for sticking with them.
If I go through a third party I end up with at least one more level of
'have you re-booted your router' etc.
That depends on who you go with. People like Zen, IDNET, aaisp, Newnet
are actually much better than BT at dealing with issues - and usually
much more knowledgeable. This SORBS issue would not even be an issue
with them as they had the brains to sort out their space - rather than
just try and cluelessly blindmug sell it so SOHO's.
Bottom line, I'd rather solve a problem than work round it. As it
happens I have a second IP off the range that I could have used, but
that would have meant a lot of DNS work etc (and DNS and I are not
good friends).
I admire the spirit and good luck with it. If the Lib Dems win the
election they may find a whole in their mad ideas to offer treatment for
those with delusional misguided belief in BT syndrome. (DMBBT).
IMHO solving is better than blaming. My original post was a request
for advice and help. I got a lot of both... plus a lot of opinion.
You knew that would happen. Being a BT customer is nearly as bad as
being a spammer {joke} have a good weekend.
Kind regards
Nigel
Re: [OT] was SORBS
On Fri, 30 Apr 2010 17:48:49 +0100, corpus.defero
corpus.def...@idnet.com wrote:
On Fri, 2010-04-30 at 17:19 +0100, Nigel Frankcom wrote:
On Fri, 30 Apr 2010 16:59:57 +0100, corpus.defero
corpus.def...@idnet.com wrote:
On Fri, 2010-04-30 at 16:50 +0100, Nigel Frankcom wrote:
We're on a BT only exchange here so it's them or nothing, well not
quite, I could go CoLo... hmmm maybe not, or satellite, I was involved
in setting that up in Cyprus.
Nigel
Is there such a thing? I appreciate many are not unbundled, but the BTW
agreement means you should have no problems getting a wires-only with
someone like Zen, IDNET or Newnet. Believe me, the service just pee's
over BT.
Fair point. I live in a small village right on the end of a spur.
After being burgled at my town offices I moved the whole dammed
shebang home and now run it from my own server room.
There is nothing wrong with that - it makes good environmental sense as
well as security sense.
BT may not be the best, but they (or rather OpenReach) own the lines,
exchange and pretty much all else... plus they have helped.
Having spent 16 years with them I know the ins and outs. Openreach were
not allowed to show any favouritism to BT customers and went out of
their way for 'other licensed operators'. Many BT folk of X years
service found the notion of Openreach rather unpalatable and went out of
their way to be awkward to native BT customers. I'm not sure if that
attitude subset still exists but there really was an attitude towards
all things BT. But good on your for sticking with them.
If I go through a third party I end up with at least one more level of
'have you re-booted your router' etc.
That depends on who you go with. People like Zen, IDNET, aaisp, Newnet
are actually much better than BT at dealing with issues - and usually
much more knowledgeable. This SORBS issue would not even be an issue
with them as they had the brains to sort out their space - rather than
just try and cluelessly blindmug sell it so SOHO's.
Bottom line, I'd rather solve a problem than work round it. As it
happens I have a second IP off the range that I could have used, but
that would have meant a lot of DNS work etc (and DNS and I are not
good friends).
I admire the spirit and good luck with it. If the Lib Dems win the
election they may find a whole in their mad ideas to offer treatment for
those with delusional misguided belief in BT syndrome. (DMBBT).
IMHO solving is better than blaming. My original post was a request
for advice and help. I got a lot of both... plus a lot of opinion.
You knew that would happen. Being a BT customer is nearly as bad as
being a spammer {joke} have a good weekend.
Kind regards
Nigel
The world 'aint perfect, but we work with what we have. I'm just happy
it's sorted. With luck anyone that hits similar issues will pick up on
this and yell.
I may take a line or two off different suppliers to se how close
promises and actuality meet.
Best to all
Nigel
Re: [OT] was SORBS
On Fri, 30 Apr 2010, Nigel Frankcom wrote: We're on a BT only exchange here so it's them or nothing, well not quite, I could go CoLo... hmmm maybe not, or satellite, I was involved in setting that up in Cyprus. How about a cheap hosted VPS to handle your outbound mail? If that's all it's doing then you don't need all that much oomph. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Individual liberties are always loopholes to absolute authority. --- 8 days until the 65th anniversary of VE day
