It's always fun interacting with customer service reps when they for example confirm my email address... "errrrrr yeah so we email you at ourname@...?"
That still leaves custom mailservers and non-alias (as in aliases via plus or dot, not actual mailserver aliases) which does give an indication as to who is sharing your data.
Of course when I complained they said it must have been something I did...
I use this one for two or three vital services, like banking and receiving government messages.
Meaning i have some backup should i forget to renew the .email domain...
- "Oh! You work with us? At which store?"
Of course, this only becomes an issue when the masses start doing it. I'm very surprised how few spammers remove tge +tag, given that that's semi-mainstream by now.
personally i don't worry about spam, i want to track who leaks their users email addresses, and then be able to filter on labels that have gone bad
If a mail comes in from an unknown sender to known address I know that the address is compromised.
Ideally I would like to plug my password manager to generate an address and automatically add email filters in place.
Although I was thinking about a service that would just give randomalphanumeric@example.com for all its users, so they would be on the same host and no connection between addresses could be implied. It could or even should be receive only.
If you do, how well does your 12 random letter system work for that use case?
Also, I once encountered a site where spam+xyz worked for signup but failed validation on the login form. I think it was something important too, like a utility or bank.
You're less likely to bump into issues with -.
Some shops don't like their trade name in the email, so rot13 (g? in vim) solves that if your goal is to trace back the leaks. I have not found a reliable way of auto dropping mail from bad sources, sometimes companies change name which makes it hard to validate From with recipient.
Even better: postfix and dovecot (as of v2.3) now both allow specifying multiple recipient delimiters. So if you run your own mail server you can specify as many recipient delimiters and switch between them if websites are being picky.
I wish seive were better supported in mail clients. It works fine on the back end, but I edit my .seive file by logging into the server and sparking up Emacs rather than being able to handle it directly from my mail client.
I figured sites wouldn't want to accept it because they know you are most likely filtering their emails so they have a much less chance of getting through to you.
If someone is stealing emails/passwords from a site obviously they will just strip characters after the plus to obtain your normal email address?
bar.foo@gmail.com
gets rejected as email address doesn't exist when my gmail is bar@gmail.com
So if you wanted to use it like this you would try something like b.ar@gmail.com
johndoe@gmail.com
john.doe@gmail.com
j.o.h.n.d.o.e@gmail.com
johndoe+spam@gmail.com
john....doe+spam@gmail.com
but johndoe.spam@gmail.com wouldn't go to the same mailbox.But sure, you could have `(my name is)john."..".doe+spam(...)@gmail.com` if you wanted to. Syntactically valid! The parenthesised bits would be stripped out before sending, and I have no idea whether Gmail would be willing to accept the quoted dots bit.
As for parens, I recollect the spec lets you nest your parens and quotes! It's insane. e.g. `f(oo."(bar."baz")."quux)@example.com` is valid in the spec.
I wrote an Oracle regex to parse for valid email addresses and I went against the spec rather than what is what's practically used. It was an insane thing.
For example: foobar@ foo.bar@ f.o.o.b.a.r@ are all valid and normalize the case without the periods.