3 ms·

All right, I'll grant you that, though it's minimal: since anyone can create any number of gmail addresses already, there is a minimal policy difference. If th

All right, I'll grant you that, though it's minimal: since anyone can create any number of gmail addresses already, there is a minimal policy difference. If this is a concern then Google can generate an immutable part of it (with high entropy), for example I said "j45rsdfjdocusign " of which "j45rsdfj" may be generated and the user may rewrite only the end of it. The reason it's good for the user to be able to write at least part of it is so they can include the tag and not have to add it as a separate step. Otherwise, it is hard to remember where tags go. An alternative is that during the generation the user could supply their comment which is visible only to them. (So that under this scenario j45rsdfj is generated, and you comment it with "docusign" during generation. Then if j45rsdfj receives email it is tagged with "docusign" (the comment you added during generation). There are no other policy implications. (Though I say that with a bit more hesitation, since you did point out one minimal effect.) By the way this has an additional benefit. Most user-chosen names don't have enough entropy. If I sent an email right now to johnsmith433 there is a 100% chance that it has already been registered by someone. Today, spammers can guess email addresses. (This is a theoretical problem only.) If Gmail generated high entropy as part of this feature, then this would further reduce this (theoretical only) avenue for spam. I don't think this is an actual problem though - I've never heard this being described as an issue.

sethammons 9y ago
There is one thing you are forgetting, and that is working with data at scale. That is not to say it is not solvable, but it requires more thought than just shitting it out in an afternoon. Gmail as the receiving MTA will want to accept or reject a given email recipient. To do this they need to look up the information. They likely have a fancy distributed way of doing this now. If each user now exploded out to N aliases, you are likely adding a new network hop and loads more memory storage before the MTA can accept/reject. When you are processing many billions of email (lookups), this is a significant change. Again, it is solvable if they wanted to do it. But it is nontrivial. Add onto this the need for the product team prioritize the work, other work to be de-prioritized, planning, testing, etc.
- logicallee 9y ago
  You might have missed that Google already does this. They literally already do this with the + markers. Literally all that is necessary is for the user to be allowed to add an entry saying kasdlfj33sdfsketchy = johnsmith23+sketchy so that the user can give out "kasdlfj33sdfsketchy@gmail.com" rather than "johnsmith23+sketchy@gmail.com" as the user can do today. Nothing that you have stated is difficult or a choice, because johnsmith23+sketchy is live today. If you have a gmail account, you can give out your accountname + marker to anyone you want, so that later you can start filtering it. This is security by obscurity, since this can be removed by a regex. I would like them to fix this. As for your other point, where you call the extra data "nontrivial", I am afraid you are wrong, it is almost the definition of trivial. If you have a gmail account, go to it and type a name or any word into the search field. You will instantly receive search results from the entire history of your email archives. That is because your email archives are fully indexed for fast searching. This takes a not-insignificant amount of space. Adding a few bytes of aliases is absolutely trivial compared to the amount of storage and lookup that Gmail does on your behalf. It's almost the definition of trivial. This isn't 1964!

sethammons 9y ago

There is one thing you are forgetting, and that is working with data at scale. That is not to say it is not solvable, but it requires more thought than just shitting it out in an afternoon. Gmail as the receiving MTA will want to accept or reject a given email recipient. To do this they need to look up the information. They likely have a fancy distributed way of doing this now. If each user now exploded out to N aliases, you are likely adding a new network hop and loads more memory storage before the MTA can accept/reject. When you are processing many billions of email (lookups), this is a significant change. Again, it is solvable if they wanted to do it. But it is nontrivial. Add onto this the need for the product team prioritize the work, other work to be de-prioritized, planning, testing, etc.

logicallee 9y ago
You might have missed that Google already does this. They literally already do this with the + markers. Literally all that is necessary is for the user to be allowed to add an entry saying kasdlfj33sdfsketchy = johnsmith23+sketchy so that the user can give out "kasdlfj33sdfsketchy@gmail.com" rather than "johnsmith23+sketchy@gmail.com" as the user can do today. Nothing that you have stated is difficult or a choice, because johnsmith23+sketchy is live today. If you have a gmail account, you can give out your accountname + marker to anyone you want, so that later you can start filtering it. This is security by obscurity, since this can be removed by a regex. I would like them to fix this. As for your other point, where you call the extra data "nontrivial", I am afraid you are wrong, it is almost the definition of trivial. If you have a gmail account, go to it and type a name or any word into the search field. You will instantly receive search results from the entire history of your email archives. That is because your email archives are fully indexed for fast searching. This takes a not-insignificant amount of space. Adding a few bytes of aliases is absolutely trivial compared to the amount of storage and lookup that Gmail does on your behalf. It's almost the definition of trivial. This isn't 1964!