3 ms·

How does sending email to it prove it's not a duplicate? For example: john.doe@gmail.com johndoe@gmail.com Both resolve to the same email at the user

by gitgud 9y ago

How does sending email to it prove it's not a duplicate? For example: john.doe@gmail.com johndoe@gmail.com Both resolve to the same email at the users end.

jedberg 9y ago
Exactly, and then the consumer clicks a link to verify their email and they have a second account, and it's up to them to put them together, or up to you to see that they already have a login cookie and combine the accounts.
- Sohcahtoa82 9y ago
  A user attempting to game a system like that could easily just delete their cookie or use browse in incognito mode.
Spooks 9y ago
well with gmail they are the same email. But with other mail applications, those could be two different email addresses. You are going to need to test all the different email services and find out which do this and which do not do this... which is no easy task
- gitgud 9y ago
  Exactly, so you're better off not accounting for all these special cases. As there's a never-ending list of email providers. A better approach might be to limit the effect that a new account can have in the system. Hackernews, Reddit, Stackoverflow all do this through reputation. A new account on these systems is unable to achieve much until time is spent proving the account is being used. Thus reducing the incentive for an individual to create multiple accounts.
- TheDong 9y ago
  > which is no easy task Which is impossible; a number of people run their own email or use a small friend-run email server, and you can't possible discern the delivery rules from the outside.
  - ubernostrum 9y ago
    number of people run their own Yes. A small number is a number. If we could go back in time and force every single implementer to follow every relevant RFC to utter perfection (and make sure all the RFCs were perfectly unambiguous), I'd be more sympathetic. But email is fucked. The sheer number of oddball things, hacks, workarounds, deviations and other bits of mess that implementers have engaged in over the years means the RFCs should be treated as at best a loose hopeful outline of how email might in theory work.

by gitgud 9y ago

How does sending email to it prove it's not a duplicate? For example: john.doe@gmail.com johndoe@gmail.com Both resolve to the same email at the users end.

jedberg 9y ago

Exactly, and then the consumer clicks a link to verify their email and they have a second account, and it's up to them to put them together, or up to you to see that they already have a login cookie and combine the accounts.

Sohcahtoa82 9y ago
A user attempting to game a system like that could easily just delete their cookie or use browse in incognito mode.

Spooks 9y ago

well with gmail they are the same email. But with other mail applications, those could be two different email addresses. You are going to need to test all the different email services and find out which do this and which do not do this... which is no easy task

gitgud 9y ago
Exactly, so you're better off not accounting for all these special cases. As there's a never-ending list of email providers. A better approach might be to limit the effect that a new account can have in the system. Hackernews, Reddit, Stackoverflow all do this through reputation. A new account on these systems is unable to achieve much until time is spent proving the account is being used. Thus reducing the incentive for an individual to create multiple accounts.
TheDong 9y ago
> which is no easy task Which is impossible; a number of people run their own email or use a small friend-run email server, and you can't possible discern the delivery rules from the outside.
- ubernostrum 9y ago
  number of people run their own Yes. A small number is a number. If we could go back in time and force every single implementer to follow every relevant RFC to utter perfection (and make sure all the RFCs were perfectly unambiguous), I'd be more sympathetic. But email is fucked. The sheer number of oddball things, hacks, workarounds, deviations and other bits of mess that implementers have engaged in over the years means the RFCs should be treated as at best a loose hopeful outline of how email might in theory work.