3 ms·

I have this problem. My email is <catchall>@david.kitchen and for most shops I will give them <shop>@david.kitchen . Mostly it works. But when it doesn't wor

by buro9 5y ago

I have this problem. My email is <catchall>@david.kitchen and for most shops I will give them <shop>@david.kitchen . Mostly it works. But when it doesn't work it really doesn't work. And this is OK. If they don't support one of the recent TLDs then I can just fall back to using a throwaway email address. Or if I really need the item I will shop elsewhere :shrug The annoying edge cases: 1. When <catchall>@david.kitchen works but <shop>@david.kitchen didn't work... like they're actively trying to fight the use of unique email addresses. 2. When <catchall>@david.kitchen works for registration on a web site, but doesn't work for signing in on their mobile app. Because the app enforces different email validation than the website. This is pretty annoying, especially as some apps will put the "change email" functionality in the app... rendering the account useless. 3. When <catchall>@david.kitchen works for registration on a web site, but doesn't work for the payment provider and checkout section. This is by far the most frustrating as you've got so far and are invested in the purchase and now you're stopped. I have contacted vendors about this, it's brain dead. When email validation fails it's not because they are using a hard-coded list of domains, it's usually because they have a regexp pattern and only consider a 3 letter suffix valid. I do tell web sites I have this issue, and sometimes they listen. Mostly I take my business elsewhere. Oh well, my choice to have a "difficult" domain name. Also: People really don't understand email addresses. "What's your email?", "oh it's <shop>@david.kitchen", "If you work for us you're eligible to the staff discount, do you have your ID card?" - This happens, or some confusion of it, more than I would expect.

Aissen 5y ago
If you have a catchall, why not simply put <anything unique>@david.kitchen instead of <shop>@david.kitchen, and then use previously received emails to do any eventual pinpointing ?
- 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 ago
    My 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.
rovr138 5y ago
I do something like this. It's on a .com domain I've had forever. There are a few inboxes for different people. There is a regex for each and if it matches, it goes in that inbox. An example rule, it must contain 'zy' in the user and it gets rerouted to inbox 1. If it contains 'yz' it gets rerouted to inbox 2. so, shopzy@example.com and shopyz@example.com
rycomb 5y ago
When the conversation about "oh, you work for us?" started to get too repetitive, I'd just start using "Caesar +1" for the name, that is, <tipq> instead of <shop>. The problem is that I'd still received a lot of spam. Tried graylisting and other methods, but a hard rule (i.e. name must end in a number) ended up working better. Another amusing thing about using a personalized catch-all is finding out who had their users' database hacked/leaked ...and, other than the common ones that we all know (the ones in have I been pwned?), I received some others that were kinda big (i.e. a Spanish airline company)

by buro9 5y ago

Aissen 5y ago

If you have a catchall, why not simply put <anything unique>@david.kitchen instead of <shop>@david.kitchen, and then use previously received emails to do any eventual pinpointing ?

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 ago
  My 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.

rovr138 5y ago

I do something like this. It's on a .com domain I've had forever. There are a few inboxes for different people. There is a regex for each and if it matches, it goes in that inbox. An example rule, it must contain 'zy' in the user and it gets rerouted to inbox 1. If it contains 'yz' it gets rerouted to inbox 2. so, shopzy@example.com and shopyz@example.com

rycomb 5y ago

When the conversation about "oh, you work for us?" started to get too repetitive, I'd just start using "Caesar +1" for the name, that is, <tipq> instead of <shop>. The problem is that I'd still received a lot of spam. Tried graylisting and other methods, but a hard rule (i.e. name must end in a number) ended up working better. Another amusing thing about using a personalized catch-all is finding out who had their users' database hacked/leaked ...and, other than the common ones that we all know (the ones in have I been pwned?), I received some others that were kinda big (i.e. a Spanish airline company)