3 ms·
If you are concerned with the maintainability of RegEx (i.e. "Now you have 2 problems"), do it via simple string parsing. It's more code, but it's readable by
by RajT88 5y ago
If you are concerned with the maintainability of RegEx (i.e. "Now you have 2 problems"), do it via simple string parsing. It's more code, but it's readable by mere mortals.
If it has an @ sign, split at the @ sign.
If either string has a space or other invalid character, it's invalid. Yes, there are more invalid characters for the domain than the username (I would make the case the username should just be whitespace chars, and the @ sign).
If the second string doesn't have a dot in it, it's invalid.
Split the second string by dot. If the last string of that array is not a valid TLD, it's invalid. (I realize new TLD's are popping up these days, so this step may not be strictly needed)
Not being too strict is in your interest here. You avoid too many email bounces by allowing some things which may be bad but allowed in some email providers but not others. It's a case of "Perfect is the enemy of good enough".
- deleted 5y ago[deleted]
- supermatt 5y ago> If either string has a space or other invalid character, it's invalid Nope, could have a quoted string which can contain whitespace. addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part qtext = %d33 / ; Printable US-ASCII %d35-91 / ; characters not including %d93-126 / ; "\" or the quote character obs-qtext qcontent = qtext / quoted-pair quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] > If the second string doesn't have a dot in it, it's invalid. Nope, domain names dont require a dot. <domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> > Split the second string by dot. If the last string of that array is not a valid TLD, it's invalid. (I realize new TLD's are popping up these days, so this step may not be strictly needed) Doesnt need to be a "valid TLD" to be a valid domain
- RajT88 5y agoSure. Fine. Skip that part then. The larger point I was trying to make still stands.
- supermatt 5y agoSorry, I added more issues as I copied the corresponding snippets from the RFC. Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start.
- RajT88 5y ago> Your suggestion is to not use a regexp, but is less valid, and likely less efficient than a regexp that checks for the presence of an @ anywhere than at the start. This is actually the whole point of what I wrote. Making the maintenance of the code low-effort, and having it be more permissive (i.e. less valid) and relying for the corner cases to be taken care of via email bounce. See: explainer on "Now you have 2 problems" https://arstechnica.com/information-technology/2014/05/what-is-meant-by-now-you-have-two-problems/ https://arstechnica.com/information-technology/2014/05/what-... If you read this whole comment thread you can see where this leads: increasingly complex regex in order to handle all the corner cases. Forget the corner cases, just make it "good enough" and relegate those corner cases to email bounce. Now - I don't have a case study to prove that this way of going about it is more valid than the strict regex validation you're suggesting. But I wanted to represent it as a middle ground between "just rely on email bounce" and "write a big long regex".
- supermatt 5y agoI like the first comment on that article: Some people, when trying to explain something, think "I know, I'll use a Jamie Zawinski quote." Now they have two things to explain.