This is a bit of a silly challenge that came to mind when I saw a discussion about obfuscating mailto links on the unofficial Discord server. This challenge is intentionally meant to be ridiculous and encourages horrendous solutions that should never see the light of day in actual production code.
On the internet, bots are an incredibly common. They may do anything from crawling through webpages to map out valid links on the web, to spamming forums with links to scam websites. Among some of the less ethical uses of bots is the collection of any email addresses that might be sitting around in a webpage's source code, either made visible to the user or hidden behind some alternative text. These bots collect these email addresses for any number of purposes, including phishing attempts to hijack accounts.
Commonly, these emails can be found sitting inside of so-called mailto links, which will open your default mail application and pre-populate the recipient's address, preparing you to send a new email in a single click. It's a safe bet that the vast majority of mailto link implementations aren't very sophisticated, simply providing a snippet that looks much like the following:
<a href="mailto:email@example.com">Contact Me</a>
Given the above, most bots will likely only ever scrape a webpage for a link containing
href="mailto:. A simple form of obfuscation to combat a bot could be to leave the
href attribute empty on initial page load, capture the on click event, dump the mailto email address into the
href attribute, and finally remove the on click event handler from the link before re-sending the click event.
We're not here for simple, however.
As suggested in the title, the challenge is to over-engineer this obfuscation. There is only one hard requirement:
Clicking the "Contact Me" link should, to the user's perception, function (mostly) identically to a simple mailto link. Specifically, clicking the link should ultimately result in the user's mail application opening (or being prompted to open) with no further input from the user and the "to" field being correctly pre-populated with the intended email address. This means that captchas and the like are not allowed. Delays in triggering the mail application due to processing layers of obfuscation, however, are expected and acceptable (although "until well after the heat death of the universe" is not an acceptable delay, so let's be reasonable).
Apart from the requirement above, solutions that require increasingly more sophisticated methods of de-obfuscation for a bot to discover your email address are preferred. The more complicated a bot's design would need to be to discover your email address, and the more painful it is for other programmers to see the abomination you've created, the better.
CSS is not required. A functioning webpage is not required. An entire web server is not required. A full, working web project including a framework with defined routes, security features, a VM provisioning script, and whatever the fuck else you would need is not required. You can build an actual web project around this if you wish, but code snippets and some comments explaining what does what will be more than sufficient.