Stay tuned I have a pretty cool project I plan on launching very soon. It takes the email alias to the next level, using them as meta tags to actually allow users to trace the source of shady data exchanges. I'm working on the guide and I'm hoping to actually start a community effort here to hold companies accountable for responsible use of PII
back
1 comments
I'm interested. How does it differ from using:
name+service@gmail.com or service@myowndomain.com
...to figure out where the spam originated?
> service@myowndomain.com
Just be aware that this may be very confusing to customer support agents: https://news.ycombinator.com/item?id=32475178
FWIW, I have been using the companyname@mydomain.com auto-alias for many years now and I've never had it challenged nor rejected by a human or a machine.
I’ve also been doing it for quite a few years, and I think I had it rejected by a machine once, and I had it questioned by a human once.
I’ve had way more problems from systems that think TLDs are two or three characters (which has never been true).
Everybody knows name+something@ maps to name@ so it’s trivial for bad actors to strip the plus part and just spam you directly, losing the per-correspondent distinction.
Which is covered by GP's second suggestion. I add short random password-like strings to these aliases to thwart spammers who might be trying obvious aliases, turning e.g paypal@example.com into paypal.nsi873g@example.com
I probably didn’t explain myself well.
On Gmail foo+bar@gmail.com is an “alias” for foo@gmail.com. So if you give someone foo+randomstring@gmail.com hoping that will help you map random string to that particular sender, you’re fucked - because anyone who sees foo+randomstring@gmail.com knows it’s an alias for foo@gmail.com, they can just email that directly and bypass your cleverness.
If you’re using a sane alias provider like you described, then it’s likely not an issue.
In the latter specifically it doesn't differ except for the specific methodology and what we do with the results.