Re: [mailop] contact at google
On 17 Apr 2020, at 18:55, Luis E. Muñoz via mailop wrote: On 17 Apr 2020, at 15:20, Al Iverson via mailop wrote: If you're going to copy what he does just block 0/0, it's faster. :\ And cheaper! :-) Al grossly overstates what I block, even for my personal special subdomain full of addresses used on publicly archived mailing lists, to which I do not actively solicit off-list mail FWIW, it appears that the pragmatic reasons for which I was blocking client machines with *.link names and sender address domains under .click went away at some point over 2 years ago, probably sometime around 2016. Yours are the only FPs in the past 2 years (and I was not aware of any earlier) but since I'm no longer getting thousands of spam attempts per day from people who thought cheap new gTLDs were a filter evasion opportunity (which it never was) there's no reason to keep those blocks in place. Thanks for making me aware of the stale config. Not my intention at all. But the collection of network ranges would be useful to me in trying to understand how a large collection of distributed receivers are querying DNS-based sources. I don't believe that is what I've been seeing. I have strong reasons to believe that a substantial fraction of the queries I get for my private DNSBL (despite that never having worked for anyone without permission) are not from mail receivers at all. A large slice is apparently from IPv4 brokers, querying about addresses not currently in the default-free routing table. I believe that most of the rest are spammers. In both cases, I believe that the source of the problem is that somehow Valli and other similar sites discovered my DNSBL and put it in their collection, which spammers then scraped and reused for surveillance of their IPs without any sort of QA. The subtext of the bounce I quoted though makes me question whether the data will be worthwhile. I would argue that my data on what networks attempt to query a DNSBL that has never given useful answers to the general public is unlikely to be useful to anyone as data. It is of pragmatic use for me because I can handle the effects of shunning port 53 traffic from miscreant resolvers at the border and doing so is helpful. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
On 17 Apr 2020, at 15:20, Al Iverson via mailop wrote: If you're going to copy what he does just block 0/0, it's faster. :\ And cheaper! :-) Not my intention at all. But the collection of network ranges would be useful to me in trying to understand how a large collection of distributed receivers are querying DNS-based sources. The subtext of the bounce I quoted though makes me question whether the data will be worthwhile. Best regards -lem ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
If you're going to copy what he does just block 0/0, it's faster. :\ Al On Fri, Apr 17, 2020 at 3:34 PM Luis E. Muñoz via mailop wrote: > > > Wow, > > tried twice to email you directly w no luck > > - The following addresses had permanent fatal errors - > > (reason: 550 5.7.1 : Client > host rejected: Get a real domain, spammy) > > Oh well, thank you anyway. > > -lem > > > On 17 Apr 2020, at 12:31, Bill Cole via mailop wrote: > > > On 17 Apr 2020, at 10:42, Steven Champeon via mailop wrote: > > > >> I sent this to John offlist but here is a list of the IPs that are > >> doing > >> stupid and useless queries against one of our mirrors (couple of days > >> stale > >> but still potentially useful to someone): > >> > >>count IP > >> 122 172.253.12.1 > >> 119 172.253.14.3 > >> 117 172.253.12.2 > >> 117 172.253.11.3 > >> 116 172.253.14.2 > >> 115 172.253.14.1 > >> 114 172.253.11.1 > >> 112 172.253.12.4 > >> 110 172.253.14.5 > >> 110 172.253.12.3 > >> 109 172.253.12.5 > >> 105 172.253.11.5 > >> 104 172.253.11.4 > >> 101 172.253.14.4 > >> 98 172.253.11.2 > >> > >> There are more, but those are the high-count Google IPs. Apparently, > >> there > >> are idiots at Linode, too. But the vast majority of these things are > >> coming > >> from Google netspace. > > > > Bogus DNSBL queries come from all over Google, Level3, Linode, Amazon, > > Cloudflare and other large DNS provider space. I have automation that > > blackholes DNS traffic from /24s around any such miscreants until > > they've stopped for 30 days, and the current consolidated ranges just > > from that /16 are: > > > > 172.253.0.0/23 > > 172.253.2.0/24 > > 172.253.4.0/22 > > 172.253.8.0/22 > > 172.253.12.0/24 > > 172.253.14.0/24 > > 172.253.192.0/24 > > 172.253.194.0/23 > > 172.253.196.0/22 > > 172.253.201.0/24 > > 172.253.210.0/23 > > 172.253.212.0/24 > > 172.253.214.0/23 > > 172.253.217.0/24 > > 172.253.220.0/24 > > 172.253.230.0/24 > > 172.253.233.0/24 > > 172.253.234.0/24 > > 172.253.246.0/24 > > > > My total list has 312 automatically added /24s and along with a few > > manual larger and smaller ranges those consolidate into 257 blocks > > with ranges as large as /20s where every /24 has made a query in the > > last 30 days against a never-public DNSBL that has never given useful > > answers to the world at large. > > > >> Please, make it stop already. You do not understand what you're > >> doing. > > > > They don't just not understand. They don't know, don't want to know, > > don't care, and won't make it stop. > > > > For 15+ years I've tried every form of complaint and DNS trickery I > > can think up to make bogus DNSBL queries stop. The only success I've > > ever had has been with a couple of dumb cargo-culting "check all the > > blacklists" sites that had working contacts I could berate. When I've > > managed to get any response from people operating DNS resolver > > services, that has basically boiled down to "I guess it sucks to be > > you." > > > > -- > > Bill Cole > > b...@scconsult.com or billc...@apache.org > > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > > Not For Hire (currently) > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- al iverson // wombatmail // chicago dns tools are cool! https://xnnd.com Song a day! https://xnnd.com/music ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
Wow, tried twice to email you directly w no luck - The following addresses had permanent fatal errors - (reason: 550 5.7.1 : Client host rejected: Get a real domain, spammy) Oh well, thank you anyway. -lem On 17 Apr 2020, at 12:31, Bill Cole via mailop wrote: On 17 Apr 2020, at 10:42, Steven Champeon via mailop wrote: I sent this to John offlist but here is a list of the IPs that are doing stupid and useless queries against one of our mirrors (couple of days stale but still potentially useful to someone): count IP 122 172.253.12.1 119 172.253.14.3 117 172.253.12.2 117 172.253.11.3 116 172.253.14.2 115 172.253.14.1 114 172.253.11.1 112 172.253.12.4 110 172.253.14.5 110 172.253.12.3 109 172.253.12.5 105 172.253.11.5 104 172.253.11.4 101 172.253.14.4 98 172.253.11.2 There are more, but those are the high-count Google IPs. Apparently, there are idiots at Linode, too. But the vast majority of these things are coming from Google netspace. Bogus DNSBL queries come from all over Google, Level3, Linode, Amazon, Cloudflare and other large DNS provider space. I have automation that blackholes DNS traffic from /24s around any such miscreants until they've stopped for 30 days, and the current consolidated ranges just from that /16 are: 172.253.0.0/23 172.253.2.0/24 172.253.4.0/22 172.253.8.0/22 172.253.12.0/24 172.253.14.0/24 172.253.192.0/24 172.253.194.0/23 172.253.196.0/22 172.253.201.0/24 172.253.210.0/23 172.253.212.0/24 172.253.214.0/23 172.253.217.0/24 172.253.220.0/24 172.253.230.0/24 172.253.233.0/24 172.253.234.0/24 172.253.246.0/24 My total list has 312 automatically added /24s and along with a few manual larger and smaller ranges those consolidate into 257 blocks with ranges as large as /20s where every /24 has made a query in the last 30 days against a never-public DNSBL that has never given useful answers to the world at large. Please, make it stop already. You do not understand what you're doing. They don't just not understand. They don't know, don't want to know, don't care, and won't make it stop. For 15+ years I've tried every form of complaint and DNS trickery I can think up to make bogus DNSBL queries stop. The only success I've ever had has been with a couple of dumb cargo-culting "check all the blacklists" sites that had working contacts I could berate. When I've managed to get any response from people operating DNS resolver services, that has basically boiled down to "I guess it sucks to be you." -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
On 17 Apr 2020, at 10:42, Steven Champeon via mailop wrote: I sent this to John offlist but here is a list of the IPs that are doing stupid and useless queries against one of our mirrors (couple of days stale but still potentially useful to someone): count IP 122 172.253.12.1 119 172.253.14.3 117 172.253.12.2 117 172.253.11.3 116 172.253.14.2 115 172.253.14.1 114 172.253.11.1 112 172.253.12.4 110 172.253.14.5 110 172.253.12.3 109 172.253.12.5 105 172.253.11.5 104 172.253.11.4 101 172.253.14.4 98 172.253.11.2 There are more, but those are the high-count Google IPs. Apparently, there are idiots at Linode, too. But the vast majority of these things are coming from Google netspace. Bogus DNSBL queries come from all over Google, Level3, Linode, Amazon, Cloudflare and other large DNS provider space. I have automation that blackholes DNS traffic from /24s around any such miscreants until they've stopped for 30 days, and the current consolidated ranges just from that /16 are: 172.253.0.0/23 172.253.2.0/24 172.253.4.0/22 172.253.8.0/22 172.253.12.0/24 172.253.14.0/24 172.253.192.0/24 172.253.194.0/23 172.253.196.0/22 172.253.201.0/24 172.253.210.0/23 172.253.212.0/24 172.253.214.0/23 172.253.217.0/24 172.253.220.0/24 172.253.230.0/24 172.253.233.0/24 172.253.234.0/24 172.253.246.0/24 My total list has 312 automatically added /24s and along with a few manual larger and smaller ranges those consolidate into 257 blocks with ranges as large as /20s where every /24 has made a query in the last 30 days against a never-public DNSBL that has never given useful answers to the world at large. Please, make it stop already. You do not understand what you're doing. They don't just not understand. They don't know, don't want to know, don't care, and won't make it stop. For 15+ years I've tried every form of complaint and DNS trickery I can think up to make bogus DNSBL queries stop. The only success I've ever had has been with a couple of dumb cargo-culting "check all the blacklists" sites that had working contacts I could berate. When I've managed to get any response from people operating DNS resolver services, that has basically boiled down to "I guess it sucks to be you." -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
In article , Andrew Barrett via mailop wrote: >Do Gmail/Google consume data from any other RBL, even where G/G might >periodically create a local copy to query? At least one claims G/G does, >but I remain skeptical. I am reasonably sure they do but I am quite sure they do it by a private bulk transfer, not by querying public servers. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
Understand your frustration, especially when the big guys don't SWIP (or rwhois) very clearly... NetRange: 172.253.0.0 - 172.253.255.255 CIDR: 172.253.0.0/16 NetName:GOOGLE NetHandle: NET-172-253-0-0-1 Parent: NET172 (NET-172-0-0-0-0) NetType:Direct Allocation OriginAS: AS15169 Organization: Google LLC (GOGL) RegDate:2013-04-04 Updated:2013-04-04 Ref:https://rdap.arin.net/registry/ip/172.253.0.0 And when they don't have PTR records.. host 172.253.12.1 Host 1.12.253.172.in-addr.arpa not found: 2(SERVFAIL) Hard for you to tell if what/who are these IP(s) operated by, is it google staff, internal projects, or google cloud.. I would suggest that you make the assumption that ANY queries from an IP with NO PTR, you should just reject ;) If they can't be transparent they should not be allowed access to your service. Just use the ACL functions in RBLDNSD to refuse connections for those IP(s) IMHO.. We see all kinds of attempts to 'strip' RBL data, just assume they are 'bad' unless they are not ;) For this, there really is no 'too big to block', for instance on some of our RBL's, we just simply refuse service when queries are coming from the 'open resolvers'. On 2020-04-17 7:42 a.m., Steven Champeon via mailop wrote: I sent this to John offlist but here is a list of the IPs that are doing stupid and useless queries against one of our mirrors (couple of days stale but still potentially useful to someone): count IP 122 172.253.12.1 119 172.253.14.3 117 172.253.12.2 117 172.253.11.3 116 172.253.14.2 115 172.253.14.1 114 172.253.11.1 112 172.253.12.4 110 172.253.14.5 110 172.253.12.3 109 172.253.12.5 105 172.253.11.5 104 172.253.11.4 101 172.253.14.4 98 172.253.11.2 There are more, but those are the high-count Google IPs. Apparently, there are idiots at Linode, too. But the vast majority of these things are coming from Google netspace. # egrep "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\.g" query.log|wc -l 2099 # egrep "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\.g" query.log|grep ' 172.253'|wc -l 1681 Please, make it stop already. You do not understand what you're doing. -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
I sent this to John offlist but here is a list of the IPs that are doing stupid and useless queries against one of our mirrors (couple of days stale but still potentially useful to someone): count IP 122 172.253.12.1 119 172.253.14.3 117 172.253.12.2 117 172.253.11.3 116 172.253.14.2 115 172.253.14.1 114 172.253.11.1 112 172.253.12.4 110 172.253.14.5 110 172.253.12.3 109 172.253.12.5 105 172.253.11.5 104 172.253.11.4 101 172.253.14.4 98 172.253.11.2 There are more, but those are the high-count Google IPs. Apparently, there are idiots at Linode, too. But the vast majority of these things are coming from Google netspace. # egrep "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\.g" query.log|wc -l 2099 # egrep "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\.g" query.log|grep ' 172.253'|wc -l 1681 Please, make it stop already. You do not understand what you're doing. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ Internet security and antispam hostname intelligence: http://enemieslist.com/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
On Mon, Apr 13, 2020, 3:06 PM Brandon Long via mailop wrote: I can guarantee that Gmail/Google doesn't do external rbl queries for live > traffic[1]. > Do Gmail/Google consume data from any other RBL, even where G/G might periodically create a local copy to query? At least one claims G/G does, but I remain skeptical. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
On 2020-04-14 at 00:02 -0400, John Levine via mailop wrote: > In article <20200411183502.ga31...@hesketh.com> you write: > >And yet, for years, Google has been doing reverse-octet lookups against > >it. ... > > Can you provide a list of IPs that are sending the queries? I'd think that > would > be a lot more likely to identify the culprint than "Google". > > Remember that Google is also a big cloud hoster so it may be clueless > customers. > > > >1586629389 172.253.12.1 198.211.246.23.g.enemieslist.com A IN: NOERROR/0/50 The one IP address he is providing does not appear on _netblocks*.google.com but it has the normal whois for Google own IP addresses, not the one for GCE. That IP address does appear on https://developers.google.com/speed/public-dns/faq as being one of those used to perform public dns queries from zrh You may be able to gather some limited information about the actual range that is querying you via Google public dns servers from the EDNS Client Subnet information. Kind regards ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
In article <20200411183502.ga31...@hesketh.com> you write: >And yet, for years, Google has been doing reverse-octet lookups against >it. ... Can you provide a list of IPs that are sending the queries? I'd think that would be a lot more likely to identify the culprint than "Google". Remember that Google is also a big cloud hoster so it may be clueless customers. >1586629389 172.253.12.1 198.211.246.23.g.enemieslist.com A IN: NOERROR/0/50 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
On 2020-04-13 15:00, Steven Champeon via mailop wrote: on Mon, Apr 13, 2020 at 11:54:17AM -0700, Brandon Long wrote: Are you sure this isn't just the Google Public DNS servers? Why would a DNS server be querying our mirrors? it's kinda the obvious use-case innit? I can guarantee that Gmail/Google doesn't do external rbl queries for live traffic[1]. There might be some dashboard around that someone uses to see if any of our addresses are on various rbls, though I haven't seen those used in a long time and I don't see that hostname at all in our configs. Doesn't rule out someone having their own script, I guess. That's kind of what I figure, but it's still epically stupid to do reverse octet style queries against a server that is customized to handle a completely different style of lookup. None of them will ever return a useful result, period, because that's not what those zones are for. I'd really like it if they would knock it off. This sounds very much like seriously clueless lusers using google public DNS servers. "ooh blacklist, shiny!". Firewall it. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
> Why would a DNS server be querying our mirrors? Have you ever seen anyone instruct anyone else to use 8.8.8.8 or 8.8.4.4 as the DNS server configured on their platform? I might even go so far as to surmise that would be a default configuration in the VPSes of more than one provider. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
on Mon, Apr 13, 2020 at 11:54:17AM -0700, Brandon Long wrote: > Are you sure this isn't just the Google Public DNS servers? Why would a DNS server be querying our mirrors? > I can guarantee that Gmail/Google doesn't do external rbl queries for live > traffic[1]. There might be some dashboard around that someone uses to see > if any of our addresses are on various rbls, though I haven't seen those > used in a long time and I don't see that hostname at all in our configs. > Doesn't rule out someone having their own script, I guess. That's kind of what I figure, but it's still epically stupid to do reverse octet style queries against a server that is customized to handle a completely different style of lookup. None of them will ever return a useful result, period, because that's not what those zones are for. I'd really like it if they would knock it off. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ Internet security and antispam hostname intelligence: http://enemieslist.com/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
Are you sure this isn't just the Google Public DNS servers? I can guarantee that Gmail/Google doesn't do external rbl queries for live traffic[1]. There might be some dashboard around that someone uses to see if any of our addresses are on various rbls, though I haven't seen those used in a long time and I don't see that hostname at all in our configs. Doesn't rule out someone having their own script, I guess. Blocking the public dns servers from your rbl seems like a fairly common thing for people to do so you can properly attribute who is using your RBL. Oh, and although we mostly don't allow mail sending on GCE, there are some mail receivers, so we it's possible it's a cloud customer, the IPs for GCE are fairly separate (ie, not in _netblocks.google.com) Brandon [1] Us querying an external RBL in real-time would be a great way to DoS an RBL, especially one with a sparse matrix like yours On Sat, Apr 11, 2020 at 11:37 AM Steven Champeon via mailop < mailop@mailop.org> wrote: > > Are there any Google folks here? > > We have a few rbldnsd mirrors, hosting a custom DNSBL for Enemieslist > which is not your standard reverse-octet IP-based lookup (instead, you > pre-pend a PTR record or HELO to the zones before you query, and get a > reply that lets you know how we've classified that naming convention). > An A query gets you the class and TXT gets you the "tech" (eg, "dsl", > "dialup" "cable", etc.) > > And yet, for years, Google has been doing reverse-octet lookups against > it. I'd rather they don't, but don't know who at Google is doing it. > It's dumb, because they will never receive a useful response, and it's > just adding to the load on our mirrors. And we actually have people who > want to use it for the proper purpose. > > eg: > > 1586629389 172.253.12.1 198.211.246.23.g.enemieslist.com A IN: > NOERROR/0/50 > > So, if anyone at Google can figure out who controls whatever experiment > is epically failing and has been for a long time, I'd appreciate a hand in > making it stop. > > Thanks, and stay safe, > Steve > > -- > hesketh.com/inc. v: +1(919)834-2552 <(919)%20834-2552> f: +1(919)834-2553 > <(919)%20834-2553> w: http://hesketh.com/ > Internet security and antispam hostname intelligence: > http://enemieslist.com/ > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
I should point out, _spf.google.com actually includes three netblocks sub records, _netblocks is not all of them. Brandon On Mon, Apr 13, 2020 at 11:54 AM Brandon Long wrote: > Are you sure this isn't just the Google Public DNS servers? > > I can guarantee that Gmail/Google doesn't do external rbl queries for live > traffic[1]. There might be some dashboard around that someone uses to see > if any of our addresses are on various rbls, though I haven't seen those > used in a long time and I don't see that hostname at all in our configs. > Doesn't rule out someone having their own script, I guess. > > Blocking the public dns servers from your rbl seems like a fairly common > thing for people to do so you can properly attribute who is using your RBL. > > Oh, and although we mostly don't allow mail sending on GCE, there are some > mail receivers, so we it's possible it's a cloud customer, the IPs for GCE > are fairly separate (ie, not in _netblocks.google.com) > > Brandon > > [1] Us querying an external RBL in real-time would be a great way to DoS > an RBL, especially one with a sparse matrix like yours > > On Sat, Apr 11, 2020 at 11:37 AM Steven Champeon via mailop < > mailop@mailop.org> wrote: > >> >> Are there any Google folks here? >> >> We have a few rbldnsd mirrors, hosting a custom DNSBL for Enemieslist >> which is not your standard reverse-octet IP-based lookup (instead, you >> pre-pend a PTR record or HELO to the zones before you query, and get a >> reply that lets you know how we've classified that naming convention). >> An A query gets you the class and TXT gets you the "tech" (eg, "dsl", >> "dialup" "cable", etc.) >> >> And yet, for years, Google has been doing reverse-octet lookups against >> it. I'd rather they don't, but don't know who at Google is doing it. >> It's dumb, because they will never receive a useful response, and it's >> just adding to the load on our mirrors. And we actually have people who >> want to use it for the proper purpose. >> >> eg: >> >> 1586629389 172.253.12.1 198.211.246.23.g.enemieslist.com A IN: >> NOERROR/0/50 >> >> So, if anyone at Google can figure out who controls whatever experiment >> is epically failing and has been for a long time, I'd appreciate a hand in >> making it stop. >> >> Thanks, and stay safe, >> Steve >> >> -- >> hesketh.com/inc. v: +1(919)834-2552 <(919)%20834-2552> f: +1(919)834-2553 >> <(919)%20834-2553> w: http://hesketh.com/ >> Internet security and antispam hostname intelligence: >> http://enemieslist.com/ >> >> ___ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] contact at google
Are there any Google folks here? We have a few rbldnsd mirrors, hosting a custom DNSBL for Enemieslist which is not your standard reverse-octet IP-based lookup (instead, you pre-pend a PTR record or HELO to the zones before you query, and get a reply that lets you know how we've classified that naming convention). An A query gets you the class and TXT gets you the "tech" (eg, "dsl", "dialup" "cable", etc.) And yet, for years, Google has been doing reverse-octet lookups against it. I'd rather they don't, but don't know who at Google is doing it. It's dumb, because they will never receive a useful response, and it's just adding to the load on our mirrors. And we actually have people who want to use it for the proper purpose. eg: 1586629389 172.253.12.1 198.211.246.23.g.enemieslist.com A IN: NOERROR/0/50 So, if anyone at Google can figure out who controls whatever experiment is epically failing and has been for a long time, I'd appreciate a hand in making it stop. Thanks, and stay safe, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ Internet security and antispam hostname intelligence: http://enemieslist.com/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
