Some thoughts on new top-level domains being used for spam

August 7, 2021

Over on Twitter, I had a little exchange:

@thatcks: Another day, another new vanity TLD that I'm never accepting email from (because of spam, of course; the dominant use of vanity TLDs in email senders is for spam).

@MrDOS: This is a self-fulfilling prophecy, though: by denying legitimate mail from these TLDs, you're guaranteeing that no one will ever be able use these TLDs for legitimate mail.

@thatcks: When the spammers get there first, the well is poisoned. Un-poisoning the well is not my (or anyone's) problem; we just not want to be fed poisoned water.

On the one hand, I think that my reaction and final tweet are not wrong. Potential receivers of email are under no obligation to help senders get it delivered, and if something only or mostly sends you spam, well, you can sensibly block it and many people will. As a result, spammers can and do poison certain things, including new top level domains (mostly generic TLDs, but sometimes country ones as well).

(Although I can't find a link to it, I believe I once saw a summary of a study on how many new gTLD domains were canceled or removed almost immediately after creation. For many active gTLDs, a surprisingly large number of new domains went away very rapidly. The study didn't conclusively say they were used primarily for spam and other bad purposes, but that was the obvious speculation.)

On the other hand, this feels uncomfortable close to pushing email further toward a closed system in practice, where only large existing senders of email can get their email accepted and other people are frozen out. Setting up a broad based block of any sort (whether a gTLD or a large network (IP) area) makes it incrementally harder for people to send email from new, not well established hosts, and anecdotally that's already hard.

On the third hard, my personal email box is a much different thing than a large mail provider. Decisions made by Google, Microsoft, and so on about who they will accept email from (and what they will require from that email) have far bigger effects than my decisions do. It also feels like the central decisions of Google and so on are fundamentally different (and more dangerous) than the aggregated distributed decisions of a large number of people, even if they come to roughly the same end result.

I don't have any firm answers, especially universal ones, but I'm not likely to change my own personal blocks. Sorry, gTLDs and people using them, but not really. In the end I care more about my mailbox than anything else, because I've just become too tired of the state of modern email.

(I have mixed views on new TLDs in general, but that's somewhat separate from their use in email.)


Comments on this page:

By Katy Guest at 2021-08-08 19:27:11:

I'd say this is trending towards moot once AI is trained to identify SPAM. Instead of a hammer and nail, trained AI would be very contextually sensitive. Will it happen? Depends of course in the near term but as AI matures, for sure :)

I have skin in the game, since I've moved to one of the new TLDs for mail (.land), but, as much as it's true that the majority of mail from the new TLDs is spam, the same is true (although I'll concede the proportion different) for any domain. That said, I agree with the other commenter that it's largely moot with modern spam filtering technology (I hesitate to call it AI). Any discriminating pattern in spam mail, including the sender domain, will be more effectively "spotted" by hidden markov models and similar. Worrying about the sender TLD seems to me similar to the pre-bayes world of hundreds of hand-written, fine-tuned SpamAssassin rules: a folly I thought we'd left in the past.

Written on 07 August 2021.
« Some bits of how Bash and GNU Readline's "bracketed paste" mode behaves
The xterm terminal emulator can do a lot more than just display text »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Aug 7 23:31:31 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.