Yes, not allowing for + in emails is terrible practice. I wish I bookmarked it but I read a great article a few years ago all about email validation and how futile it pretty much is - the conclusion was to just check for the presence of an '@' character. Email validation is best done by sending an email to the address and seeing if the user opens it/goes to some link within it.
Everything before the '@' is entirely ruled by the mailserver, so any validation rules you apply to this are effectively an assumption on the rules your user's mailserver use. I guess you could validate the post-'@' characters but with how many new TLDs are coming out this seems like more hassle than it's worth. Trust your users to know their emails (but make sure you're still encoding the input so as to avoid nasty SQL injection etc!)
Hopefully doing more than just encoding/escaping -- never place user data directly into a SQL statement! Always use placeholders like ? or whatever your flavor of DB allows. And if it doesn't allow for that, really think hard about why you're using that db (or db sdk)!
Yes, not allowing for + in emails is terrible practice. I wish I bookmarked it but I read a great article a few years ago all about email validation and how futile it pretty much is - the conclusion was to just check for the presence of an '@' character. Email validation is best done by sending an email to the address and seeing if the user opens it/goes to some link within it.
Everything before the '@' is entirely ruled by the mailserver, so any validation rules you apply to this are effectively an assumption on the rules your user's mailserver use. I guess you could validate the post-'@' characters but with how many new TLDs are coming out this seems like more hassle than it's worth. Trust your users to know their emails (but make sure you're still encoding the input so as to avoid nasty SQL injection etc!)
Hopefully doing more than just encoding/escaping -- never place user data directly into a SQL statement! Always use placeholders like ? or whatever your flavor of DB allows. And if it doesn't allow for that, really think hard about why you're using that db (or db sdk)!
Fair, I just wanted to throw in something about security after making the questionably phrased statement of 'trust user input' :D