I often go one step futher by appending a short random identifier, `{service}.{id}@{domain}`, to make it harder to guess (in case someone learned of my email address policy).

I created a little GTK program to help: https://github.com/LightAndLight/gen-alias

Yes, it’s really <f(service, rand())>.

What fraction of people do you suppose actually have a <yourdomain> to do this with?

Even some highly technically inclined people (like myself) can be entirely ignorant of the process. It's not as if consumer ISPs provide the service.

Sub-addressing (doing tag+handle@domain.com) is supported by many email services but + may be flagged as an illegal character.

at least hotmail, gmail, apple's various mail, though with apple just using hide my email is that whole idea fully and beautifully automated for normies

The process isn’t difficult and worth acquainting yourself with.

If you don't control your own domain fully, almost all email services let you do:

user+servicetag@domain.com

And have it go to user@domain.com with the servicetag still in the To: field. At least, I have never encountered a problem with this.

Some sites (hulu maybe? iirc) strip off the + and treat it as a bare email, with dedupe checks and all that.

Spammers won't respect the + either, they will clean their list of any +tags before sending.

The best I've actually come across is to abuse gmails period policy. I haven't seen sites dedupe this or perform any other checks or manipulation.

If you have enough letters in your alias you can treat the possible period locations as binary. For example, pests@ would have 4 edible spots, so I could make 16 different dot addresses: pests@, pest.s@, pes.ts@, pes.t.s@, pe.sts@, pe.st.s@, [...], p.e.s.t.s@

Then you can just remember/record the decimal ID you used per site.

> Spammers won't respect the + either, they will clean their list of any +tags before sending.

That's the entire point, if you get an email from the site but it doesn't include your +servicename tag then you immediately can immediately tell it's a phishing attempt or spam. If the tag is there it's not a 100% guarantee that it's legit, but absence of the tag is a big red flag.

You can't tell who it came from though, unlike my method at least.

Also, the +tag could get lost though just normal data clean up / normalization.

The use case here is using a unique email address to help verify the sender of the email, it's not connected to spam usage.

So you’re suggesting the sender use the + modifier on the from address?

Here's the suggestion:

>Use <service>@<yourdomain> as your email address when signing up, and check the To header when receiving emails.

The user of the webservice specifies a unique email per webservice; knowledge of that unique email address serves as a hint that the email came from someone that has discovered that email address, i.e. the webservice itself.

Right, so 99% of the time that’s a spammer that is going to use that discovered email. I updated my message to specify other illegitimate sources to cover that less than 1%