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%