Use <service>@<yourdomain> as your email address when signing up, and check the To header when receiving emails.
And/or, long-press or right-click on any link to inspect the linked domain.
And/or, long-press or right-click on any link to inspect the linked domain.
I created a little GTK program to help: https://github.com/LightAndLight/gen-alias
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.
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.
^([^@+]+)\+[^@]*(@.*)$
>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.
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.
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.
Also, the +tag could get lost though just normal data clean up / normalization.