I have been dealing with spam on my public email address for quite some time now, and it finally got to the peak of my patience with the the following email, sent to my email not so long ago:

I mean, not the most convincing fake in the world, but it did give me a good laugh. And, for quite a long time, I was perfectly willing to leave my public email out there so that these hillarious messages of spam could get through to me, as I don’t use any filter other than explicitly banned addresses. Among other very funny spam messages, here are the two runner ups of best spam emails:

Great email from a Spanish prince this time?

Nice try from The Bee - but I’m neither American nor a taxpayer (yet)

And, you know what? Things were alright. However, I have recently been a victim of a seemingly targetted spamming incident. I was suddenly recieving mail from the mail server warning of low disk space and of high volumes of mail being delivered to this mailbox. I looked into by junk box for the first time in a while and discovered over one hundred emails in the past half an hour. Luckily, due to the helpful nature of mutt bindings, I could mass delete them all in one go. However, this kept happening. Every now and then, I would come across a random bulk email spam from a clearly throw away email address.

However, these obfuscated mailing addresses gave me an idea. How were the spammers obtaining my email address? Well, the obvious answer was that they were randomly accessing the site and scraping using a regex to find a correct email address. It doesn’t matter if some of them are inactive, inaccurate or completely broken - thousands more will be all of the above. So, if I can create something which does not fulfill the regex of an email address, they won’t pick it up. In particular, this requires disrupting the pattern for the box name (the part before the ‘@’ sign) and attempting to disrupt the pattern entirely (remove the ‘@’ sign entirely). The solution? Very simply. The standard UNIX “tr” tool can translate these patterns between them effectively. I chose the ‘*’ to replace the ‘.’ sign, as it is illegal in normal email addresses (regex specifies word characters, from which ‘*’ is excluded). I also chose to replace the ‘@’ sign with a dash to prevent it appearing entirely. The dash was chosen as it actually is legal in email addresses, so will disrupt regexes which find the ‘@’ symbol later on.

Now, I have heard from the AUR maintainers that some spammers are starting to realise of this common obfuscation method and attempt to decode it properly. So, I added an extra layer of obfuscation - the sed layer. At the end of the email pipeline, you will see something which looks like this:

| sed 's/com.au/co.uk/'

All this is doing is substituting the fake domain registrar “.com.au” for the real one in the final email. This means that spam bots will be directed to the entirely false domain of “ethanjmarshall.com.au”, which - as of 2022 - is not registered. This extra layer has reduced my volume of spam to effectively zero. I am assuming that my mail is already out there in some pre-compiled list, but I don’t really care about this: hopefully it will be the highlight of my week when I obtain another email from “metropolitanpolicemps@gmail.com” calling me a pedophile (and spelling it horribly wrong in the process).

This process also helps to eliminate non-UNIX users from being able to email me. As mentioned in the contact page, people who claim that they use WSL occasionally still slip through the net. This is a problem I need to solve, and I do have an idea, From personal experience, I know that neither WSL 1 nor 2 implement direct packet access. So, simple programs like ping(8) will completely fail. So, I could just add:

ping -c1 ethanjmarshall.co.uk >/dev/null 2>&1 && ( <rest of pipeline> )

This will mean that WSL users who don’t know what they’re doing will just get nothing and be really confused. Actual Based UNIX Users™, however, will be unaffected.

In any case, this simple method has reduced my volume of spam by at least two thirds and eliminated my high-volume problem. Good tech, can recommend.

Check your compliance with Based™_ UNIX-ism with the following simple script:_

#!/bin/sh
asdfg() {
        return "this should cause an error"
}
echo $(asdfg)

This should cause an error.