Re: [mailop] Old subject, awareness, given recent Microsoft disclosure.. blocking port 25 from dynamic/DUL networks
on Fri, Jul 09, 2021 at 09:25:57AM +0200, Hans-Martin Mosner via mailop wrote: > IMHP that's the wrong approach. The question isn't whether IP > addresses are dynamically or statically assigned, but whether it is > possible with reasonable effort to find an entity that is responsible > for SMTP traffic coming from an IP address. It doesn't matter whether > the IP address has no pointer, has "dynamicip" or "staticip" or one of > the various anonymous cloud hosting domain names in it. I can assure you that the approach is valid. I don't know of anyone who still accepts mail from hosts without a PTR, period. And I do know for certain that many find distinguishing between generic, static, and dynamic (as well as several other classifications, such as shared or dedicated webhosts, residential university networks, NATs, etc.) extremely useful in the context of not just inbound SMTP but also a variety of other contexts where the nature of the source matters. Correlations are useful. Now, you're right in thinking that reaching a responsible party is an important aspect of making manual decisions as to who to block; with the devastation that is WHOIS and the GDRP that has become well-nigh impossible in many, if not most, cases, and the proliferation of idiocy that is the failure to provide a working abuse@ address for every domain and replacing them with alternates or even jump-through-hoops Web forms for reporting abuse isn't helping. It's a lot easier to set policy based on your tolerance for static/dynamic/generic/etc. and let the MTA or filter make the decisions for you using a dataset based on classified naming conventions. Why should that be any different than how you might use SPF or DKIM/DMARC? YMMV, your server, your rules. But I wouldn't have been able to collect and classify almost 275K naming patterns over the past 18 years, with a coverage of ~97% of the IPv4 PTR namespace, if someone didn't find the dataset valuable... 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://list.mailop.org/listinfo/mailop
Re: [mailop] Old subject, awareness, given recent Microsoft disclosure.. blocking port 25 from dynamic/DUL networks
Am 09.07.21 um 00:20 schrieb Steven Champeon via mailop: > on Thu, Jul 08, 2021 at 02:28:13PM -0700, Michael Peddemors via mailop wrote: >> Ex. 1.186.104.104x1 1.186.104.104.dvois.com > Even better still dvois.com uses the same naming for dynamics and > statics. At least they only have the couple - though they also use > static.dvois.com right anchored PTR naming, they don't ALWAYS, so it's a > risk to just assume. I've dealt with Indian ISPs with hundreds, if not > thousands of naming "conventions". The old vsnl and bsnl were awful. > >> Time to brush off M3AAWG best practices.. listing what ports do not >> need to be open on dynamic IP home style networks.. > That's just it - you can't assume dynamic with dvois.com, and many more. > I have at least 136 patterns that I had to throw my hands up and call > "mixed" because they either lie, don't distinguish, or are so > incompetent they can't be bothered to not hand out statics with 'dyn' > token labels, and vice versa (eg., rima-tde). Much of Brazil is simply > generic, stuff like 1-2-3-4.example.net.br. We tend to assume generic == > dynamic, especially when they've got tiny allocations, but shrug. > > Steve > IMHP that's the wrong approach. The question isn't whether IP addresses are dynamically or statically assigned, but whether it is possible with reasonable effort to find an entity that is responsible for SMTP traffic coming from an IP address. It doesn't matter whether the IP address has no pointer, has "dynamicip" or "staticip" or one of the various anonymous cloud hosting domain names in it. You might want to make individual exceptions for IPs that you know are associated with fixed domains (for example, when SPF records indicate that the IP is being used by that domain and you trust the domain itself), but as a general rule, clients accessing port 25 should have non-generic PTR entries. Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Old subject, awareness, given recent Microsoft disclosure.. blocking port 25 from dynamic/DUL networks
on Thu, Jul 08, 2021 at 02:28:13PM -0700, Michael Peddemors via mailop wrote: > Ex. 1.186.104.104 x1 1.186.104.104.dvois.com Even better still dvois.com uses the same naming for dynamics and statics. At least they only have the couple - though they also use static.dvois.com right anchored PTR naming, they don't ALWAYS, so it's a risk to just assume. I've dealt with Indian ISPs with hundreds, if not thousands of naming "conventions". The old vsnl and bsnl were awful. > Time to brush off M3AAWG best practices.. listing what ports do not > need to be open on dynamic IP home style networks.. That's just it - you can't assume dynamic with dvois.com, and many more. I have at least 136 patterns that I had to throw my hands up and call "mixed" because they either lie, don't distinguish, or are so incompetent they can't be bothered to not hand out statics with 'dyn' token labels, and vice versa (eg., rima-tde). Much of Brazil is simply generic, stuff like 1-2-3-4.example.net.br. We tend to assume generic == dynamic, especially when they've got tiny allocations, but shrug. 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://list.mailop.org/listinfo/mailop
[mailop] Old subject, awareness, given recent Microsoft disclosure.. blocking port 25 from dynamic/DUL networks
It's been quite a few years, and for those of you on this list as long in the tooth as I am, you will remember the battles of the 90's and early 2000's between various RBL's and large telco/cable companies.. Those cable companies did very little about outbound abuse, so several of the RBL's in the day, controversially blocked the largest ISP's networks.. period.. This finally hit the big telco's in the pocket book enough, that they gave in and started blocking port 25 on egress from their dynamic IP ranges, and now most of the ISP's in North America still block port 25 on egress. However, the world is big.. and many other areas in the world are not doing this yet.. eg.. from today, just looking at compromised GPON routers, this one ISP is sending spam from the following.. (any one here have any sway with this company?) Ex. 1.186.104.104 x1 1.186.104.104.dvois.com (fuller list below) Now, there are several countries really having a problem with this. Compromised routers, IoT devices.. and compromised old versions of Windows. And while most email operators already stop them one way or another, it is just a huge drain on resources. (Included samples from Brazil below as well) It was bad enough when all they were doing is spamming, and it is so simple to block port 25 on egress from DUL/Dynamic networks, why is this practice not working its way to emerging markets?? We have brought it up with several CERT's, but little progress is being made on this front, and given the prevalence of older/cheaper IoT routers, and/or older versions of Windows, a lot more compromised devices in those regions. And now, with the latest Microsoft disclosure, we can be sure millions more devices will be compromised.. Isn't it time we renwed this conversation with ISP's and Telco's around the world? Spambots' are dangerous, precursor to much worse things. But at least it is easy to stop. Time to brush off M3AAWG best practices.. listing what ports do not need to be open on dynamic IP home style networks.. .. 1.186.104.104 x1 1.186.104.104.dvois.com 1.186.104.111 x2 1.186.104.111.dvois.com 1.186.104.118 x2 1.186.104.118.dvois.com 1.186.104.119 x1 1.186.104.119.dvois.com 1.186.104.121 x1 1.186.104.121.dvois.com 1.186.104.123 x1 1.186.104.123.dvois.com 1.186.104.128 x1 1.186.104.128.dvois.com 1.186.104.144 x1 1.186.104.144.dvois.com 1.186.104.154 x1 1.186.104.154.dvois.com 1.186.104.160 x1 1.186.104.160.dvois.com 1.186.104.164 x3 1.186.104.164.dvois.com 1.186.104.197 x2 1.186.104.197.dvois.com 1.186.104.207 x2 1.186.104.207.dvois.com 1.186.104.221 x2 1.186.104.221.dvois.com 1.186.104.228 x3 1.186.104.228.dvois.com 1.186.104.237 x1 1.186.104.237.dvois.com 1.186.104.240 x1 1.186.104.240.dvois.com 1.186.104.245 x7 1.186.104.245.dvois.com 1.186.104.25x1 1.186.104.25.dvois.com 1.186.104.65x2 1.186.104.65.dvois.com 1.186.104.72x3 1.186.104.72.dvois.com 1.186.104.76x1 1.186.104.76.dvois.com 1.186.104.99x3 1.186.104.99.dvois.com 1.186.105.1 x5 1.186.105.1.dvois.com 1.186.105.104 x2 1.186.105.104.dvois.com 1.186.105.109 x2 1.186.105.109.dvois.com 1.186.105.117 x5 1.186.105.117.dvois.com 1.186.105.123 x2 1.186.105.123.dvois.com 1.186.105.128 x1 1.186.105.128.dvois.com 1.186.105.133 x2 1.186.105.133.dvois.com 1.186.105.136 x1 1.186.105.136.dvois.com 1.186.105.138 x1 1.186.105.138.dvois.com 1.186.105.142 x1 1.186.105.142.dvois.com 1.186.105.149 x2 1.186.105.149.dvois.com 1.186.105.150 x2 1.186.105.150.dvois.com 1.186.105.153 x4 1.186.105.153.dvois.com 1.186.105.163 x2 1.186.105.163.dvois.com 1.186.105.166 x3 1.186.105.166.dvois.com 1.186.105.171 x5 1.186.105.171.dvois.com 1.186.105.172 x3 1.186.105.172.dvois.com 1.186.105.176 x2 1.186.105.176.dvois.com 1.186.105.187 x2 1.186.105.187.dvois.com 1.186.105.193 x4 1.186.105.193.dvois.com 1.186.105.199 x1 1.186.105.199.dvois.com 1.186.105.206 x4 1.186.105.206.dvois.com 1.186.105.209 x2 1.186.105.209.dvois.com 1.186.105.211 x3 1.186.105.211.dvois.com 1.186.105.215 x4 1.186.105.215.dvois.com 1.186.105.226 x2 1.186.105.226.dvois.com 1.186.105.227 x1 1.186.105.227.dvois.com 1.186.105.231 x5 1.186.105.231.dvois.com 1.186.105.233 x1 1.186.105.233.dvois.com 1.186.105.242 x1 1.186.105.242.dvois.com 1.186.105.246 x2 1.186.105.246.dvois.com 1.186.105.247 x4 1.186.105.247.dvois.com 1.186.105.253 x1 1.186.105.253.dvois.com 1.186.105.254 x3 1.186.105.254.dvois.com 1.186.105.3 x3 1.186.105.3.dvois.com 1.186.105.35x1 1.186.105.35.dvois.com 1.186.105.52x1 1.186.105