Spam: The Security Threat You Easily Forget
What is Ransomware

How Far Will Email Operators Take Blocklisting to Prevent Spam?

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?

5321244474_7fe4068d2b_z
Image by Waxy Dan

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”.

Reputation Matters

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.

 

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.

Your Information

(Name is required. Email address will not be displayed with the comment.)