| ▲ | dfabulich 3 hours ago | |||||||||||||||||||||||||||||||
The rules of email validation are not remotely well defined! Syntactic email validation is an impossibly hard problem. https://www.netmeister.org/blog/email.html IMO the industry consensus is never to "validate" email addresses syntactically, but simply to ensure that the email address contains at least one @ and to verify the email address by emailing it an activation code. Proofs would not have uncovered these failures. The proofs would have proved that they rejected your email address as invalid, and the developers would have patted themselves on the back for a job well done. | ||||||||||||||||||||||||||||||||
| ▲ | win311fwg 3 hours ago | parent [-] | |||||||||||||||||||||||||||||||
> The rules of email validation are not remotely well defined! RFC 5322 fully defines the structure. > IMO the industry consensus is never to "validate" email addresses syntactically That is true, but not because it isn't well defined, but because it is hard to get right. Keep in mind that most developers don't even know what a property-based test is, and of those that do, only a small subset of them know how to use them. If you find any testing around it at all, which is a stretch to begin with, you will be lucky to find more than a small set of common addresses without any care or concern for the complex edge cases that lead to problems like I have had as a user in the past. Encouraging developers to only validate for the presence of @ means that there is no additional room to screw things up. But better than to rely on gimping your code to deal with developers is to use the tools at your disposal. > and to verify the email address by emailing it an activation code. That may also be beneficial, but not for the same reason. Not all CRUD use-cases fit that mould. | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||