3 ms·
I used to do this, and if signing up online it's fine. But IRL I'm not on my phone generating the email address when asked at the checkout. That inconsistency m
by buro9 5y ago
I used to do this, and if signing up online it's fine. But IRL I'm not on my phone generating the email address when asked at the checkout. That inconsistency meant duplicate accounts, and TBH I figured I was making things excessively complex and <shop>@david.kitchen was perfectly sufficient for my goals.
My goals are just to identify who was compromised when an email address leaks, and secondarily to prevent entirely unconnected merchants or organisations from trivially joining the dots on a connected identity. In both cases good enough is good enough and I'm not trying to achieve perfect security or privacy with email as that's virtually impossible.
- MayeulC 5y agoMy goals are similar. I don't have a catch-all configured, but I have shop@example.com, and often use it with +aliases. Something like shop+epicgames@example.com. I don't have to set those up on my phone, and I generally found cashiers and other customer service to be understanding (they mostly do not ask twice, except for confirming that "plus" is indeed "+"). Once I was looked at like I didn't understand what an e-mail address was supposed to be, until I told them my custom domain name. That works fine for the majority of use-cases, but some refuse the "+" character, others (rarely) refuse my custom domain. Once, a shop refused to have its name. For the edge-cases, I generate a new e-mail address, and sometimes drop them an annoyed e-mail with a technical explanation of what's allowed and how to check for it. I think most client-side verification is here to avoid typos, but it shouldn't lock out the unexpected. Websites might have more success asking users to double-check unusual e-mail addresses or likely typos (like @gamil.com or smantha.lastname@... -- typo in first name), without outright rejecting them.