[sans_souse]

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

[iamben]

I'm interested. How does it differ from using:

[e-mail] or [e-mail]

...to figure out where the spam originated?

[buu700]

> [e-mail]

Just be aware that this may be very confusing to customer support agents: https://news.ycombinator.com/item?id=32475178

[rsync]

FWIW, I have been using the [e-mail] auto-alias for many years now and I've never had it challenged nor rejected by a human or a machine.

[chrismorgan]

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).

[loloquwowndueo]

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.

[homebrewer]

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 [e-mail] into [e-mail]

[loloquwowndueo]

I probably didn’t explain myself well.

On Gmail [e-mail] is an “alias” for [e-mail]. So if you give someone [e-mail] hoping that will help you map random string to that particular sender, you’re fucked - because anyone who sees [e-mail] knows it’s an alias for [e-mail], 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.

[sans_souse]

In the latter specifically it doesn't differ except for the specific methodology and what we do with the results.