Security administrators use firewalls, web proxies, or antispam gateways to block traffic sources that exhibit suspicious or known attack pattern behaviors. Blocking individual IP addresses has been a staple defensive measure for years. Security system administrators have also blocked entire IP network allocations to mitigate attacks and on rare occasions, they have blocked all of the addresses that have been allocated to an ISP. Are enterprise and ISP email operators poised to apply similarly sweeping security measures to protect their organizations against perceived or reported domain name abuse by blocking TLDs to manage spam?
The Roles of Blocklists
Administrators of private networks, public networks, or mail exchange services use reputation block lists and community (threat) intelligence to mitigate security threats; for example, email operators often create filters to prevent delivery of spam or phishing email originating from blocklisted IP addresses or domain names; similarly, security administrators will use blocklists in web application proxies to prevent users from visiting web sites known to host malware.
The SURBL Most Abused TLDs list is one of several reports from reputation service providers that call attention to Internet address space, hyperlink, or domain name abuse. SURBL reports hourly on the number of domain names it has block listed, by top-level domain. Others that report on the most abused TLDs include Domain Tools and the Spamhaus Project. These and other blocklists serve as trust or confidence indicators for individual domain names or IP addresses, Internet Service Providers, hosting providers, and increasingly, for Top-level Domains.
Spam Is A Singularly Worrisome Security Threat
Spam is a widely employed delivery mechanism for phishing or malware site hyperlinks or malicious attachments, and for delivering advanced email threats such as business email compromise or ransomware as well. Because spam is so diversely used, preventing delivery of spam is a priority concern for email administrators.
Domain names, hyperlinks and IP addresses are commonly encountered in email message headers or bodies. Spam mitigation measures accept or deny email based on rules that may include any or all of these identifiers. Do organizations that employ these mitigation measures have Top-level Domains in their crosshairs?
Community Forums: Discussion Sites for Spam Mitigation Policy Enforcement
Community forums offer a source for understanding evolving sentiments among participating email administrators towards Internet Identifier abuse. Email administrators discuss measures they take to detect or block potential spam as openly as developers share programs or scripts in community forums such as Stack Overflow or github. Email services or email security product vendors moderate certain of these sites: others are open communities for acquiring knowledge, sharing abuse intelligence, or discussing practices.
Discussion threads in Barracuda Forums, Vamsoft Community, SpamTitan Spiceworks Community, HowtoForge, Slipstick Exchange Server Community, SpamAssassin and Topicdesk.com forums reveal a common and important operating principle:
Email administrators weigh risk against reward when they make decisions regarding how to mitigate spam. They think first or exclusively about the security of their organization, their users, or their customers.
Email administrators are willing and by their own accounts do apply filtering rules to block delivery of email from entire TLDs. Blocking at the TLD level is a practice that has been and continues to be applied to ccTLDs. One administrator justifies this practice saying, “some countries have no laws against spam, and providers are happy to take money from spammers and allow them to send millions of emails.”
Administrators have blocked entire TLDs in the past, using event logs or “most abused lists” as the basis for blocklisting. Several strategies regarding new TLDs appear in discussion threads:
- Administrators in several email communities have discussed the merits of implementing a policy to block abused TLDs or all new TLDs and have shared policy configurations because they believe that this action will reduce their organizational or subscribers’ risk.
- Some administrators comment that they use their passive DNS replication data to block all newly registered domains in new TLDs in order to catch abuse domain names that have not yet been added to URI blocklists.
- Some administrators are willing to tolerate false positives to mitigate spam if they believe that this action will effectively block abuse domains used in spam attacks. Administrators who appear more familiar with domain registration services claim to create filtering rules that block email based on the name server names that are associated with registrars that have poor reputations, again demonstrating a willingness to accept false positives until the registrar’s reputation improves.
- Email administrators admit to blocking entire new TLDs to mitigate spam when their organizations conclude that there is little likelihood that it will receive legitimate business correspondence from any but a few recognized legacy TLDs.
Small or medium business administrators across several email communities have suggested that policies of these kinds are reasonable because the implementation, while severe, is simple to deploy and the risk associated with such policies are perceived to be low relative to their organization sizes. One administrator comments that, “a fortune 500 company has a lot more to lose by whacking those [new TLDs], but someone with 100 users is probably ok blocking anything”.
Review sites such as Yelp!, TripAdvisor and consumer product ratings at emerchant sites have made reputation an integral part of consumer choice. The amplification factor from social media further empowers consumers to express dissatisfaction or fear of harm. Wittingly or not, our societies are becoming accustomed to assessing risk through reputation. It’s worth noting that these ratings do not have the same accuracy, reliability, accountability characteristics of reputation blocklists yet they still shape decision making.
Email community forums are neither trade nor industry policy associations. They are, however, influential; in particular, administrators from small and medium businesses greatly value sharing opportunities with administrators who are employed at larger organizations. The informal discussions in such forums, however anecdotal, illustrate that abuse reputation matters. The ICANN community may find it beneficial to consider the attitudes within email communities regarding TLDs and consider, too, the policies and attitudes that email administrators have shared during discussions about spam or other abuse filtering.
Registry operators may also wish to consider the importance of earning the confidence of the administrator communities to ensure that their TLDs and possibly all domain names registered in their TLDs are not preemptively blocked from email delivery or access via other client (e.g., web) connections. Consider engaging with these communities. Some registries already participate: in one thread, the co-founder of .Club Domains LLC offers to set up a "feedback loop with your company so that any club URLs determined to be spam etc can be forwarded to us, investigated and shut down." This kind of outreach encourages dialog and cooperation and other operators should consider the benefit to demonstrating that Top-level Domain reputation does indeed matter.