These seem reasonable.

Just accepting random strings has side effects (security risks) beyond universal acceptance.

On 9/14/2017 3:16 AM, Tex Texin wrote:

Don, thanks for asking the group for opinions.

 

My recommendation is to not offer a regex for validating email and instead the report must emphasize in its conclusion that developers must assure that their code does not

1)      treat top level domains longer than 3 characters as invalid or

IDN TLDs may also be 1 character long

2)      treat domains with non-international characters as invalid or

?? are you referring to ASCII mixing

3)      treat email addresses with non-international characters in the user part as invalid

?? are you referring to ASCII mixing

They can use the data in the study for quality assurance purposes.

 

Further, the report should identify there is a need (and has been for many years) for reference code for proper validation of email addresses since so few people have gotten it right.

 

My arguments for this approach are:

1)      The position that a good solution may be too complex for web or other developers, ignores that a good solution can be packaged as well as we would be needlessly handicapping capable developers.

2)      Although I appreciate the case made for the minimal <stuff>@<stuff> validation coupled with rigorous server side validation, some costs can be reduced by stronger client side validation as well as providing a better user experience. And although I know it can be worked around by the malicious, I still like to filter out addresses that might have deleterious effects- embedded html , sql or other commands. i.e. I don’t care if your email is “delete *”@example.com I will invalidate it.  Therefore, many of us will have filters regardless, and the minimal one is not helpful or worthy of endorsement in that context. (Yes, I understand that I still need to protect against malicious code on the server side.)

Would you do that by black-list filters that describe what is to be prohibited? Instead of some massive Regex that describes what is allowed?

3)      Promoting the minimal regex  hides the real problem, that there is a lack of a good, referenceable answer, whether it is a regex or other implementation. The question simply moves to how to do proper validation on the server side. Providing the minimal regex hides the fact we are not really addressing the community’s problem of how to correctly validate an email address.

 

We should simply make developers clear on the requirements for UA, and at the same time urge the community to define a reference set for the solution.

 

tex