Or possibly even salt_hmac(mnemonic)@domain, to both make the address un-brute-forceable and also cover businesses going "why are we emailing business@yourdomain" and potentially getting huffy (apparently this happens?!).
Only potential issue is that if it's a real HMAC like HMAC-MD5[:16] the nonsense address might give spam middleboxen very bad indigestion.
Or maybe the crazy service addresses used in cloud infrastructure have actually inoculated everything to a reasonable extent and this might work?
> cover businesses going "why are we emailing business@yourdomain" and potentially getting huffy (apparently this happens?!)
It very much happens, I had a business owner lecture me that they owned their domain and I shouldn't be able to use in any part of their domain name in my email address.
> and potentially getting huffy (apparently this happens?!).
It does...
I've had signups blocked using business@domain.tld, (some Samsung service is one I recall) and in one case I had legit sales queries completely ignored until I used an alternate email.
Ha. The more obscure the better, I guess. But you'd want some tooling to make it reasonable to handle.
I have a catchall and it's interesting what type of rubbish appears.
I have gotten phishing that pretends to be an AWS support case ticket reply about how my instances in us-east-whatever are about to be terminated due to a host node going out of commission sent to aws-iam-root-user@domain - a domain that has never used or touched AWS and a left hand side mailbox that has never been used once. If it's anything obvious it's probably made it onto some type of dictionary list.
I do this. I use the same protocol as https://blame.email/ (so that I can use their site). The nice thing about having the name in the clear is that it is easy to map it back to the sender at a glance, rather than having to loop up old messages.
