8 ms·

email:string( regex(".@.\\..*") ) This is incorrect regex for email. The correct one is https://pdw.ex-parrot.com/Mail-RFC822-Address.html https://pdw.ex-par

by xonix 2y ago

email:string( regex(".*@.*\\..*") ) This is incorrect regex for email. The correct one is https://pdw.ex-parrot.com/Mail-RFC822-Address.html https://pdw.ex-parrot.com/Mail-RFC822-Address.html

_yb2s 2y ago
That is an absurdly complex regex
- Twirrim 2y ago
  Email address specs turn out to be rather complicated. I really wish people wouldn't code their own checks rather than use already existing standards. Some languages like Java even include proper checks in their standard library: https://java.net/projects/javamail https://java.net/projects/javamail Several jobs back I had no end of arguments with some Java devs about not writing their own checks, that kept routinely failing on legitimate addresses.
  - smrtinsert 2y ago
    It's all devs in general. As a java dev I have lost count of the number of times I have to tell any dev not to use a damn regex to validate emails.
  - soco 2y ago
    But why do you even need to validate that email? Send the subscriber a confirmation link - if they get it then it was valid, if not then it's on them to fix the situation in whatever way they find fit.
  - _yb2s 2y ago
    A single massive and unreadable regex isn't an appropriate way to validate a spec that complex. With its complexity it can't be logically evaluated- only tested, whereas a function that breaks the spec out into steps/parts is going to be a lot more maintainable, readable, and auditable.
- brabel 2y ago
  It really is, I wonder if anyone has tested that extensively. It's so complex that just by reading it I don't think anyone would be able to confirm it matches the RFC correctly.
warkdarrior 2y ago
There is a typo on line 17.
OJFord 2y ago
It's a pragmatic one. It has no false negatives, and there's rarely a reason to care about false positives. (Especially not where a stricter regex would (be the only mechanism to) catch it, but a fake-but-valid address wouldn't trivially bypass it.)
- boulos 2y ago
  At the very least, I assume .+ at the start is a better choice. The RFC says: addr-spec = local-part "@" domain ; global address atom = 1*<any CHAR except specials, SPACE and CTLs> word = atom / quoted-string so I think the bit in front of the @ has to be non-empty.
  - OJFord 2y ago
    Yeah, I agree, I think I'd have written that myself, but I don't think I'd reject it in review on that basis. I don't agree with sibling comment that it's 'shitty', it's trivially improved sure but it basically doesn't matter - if you want it to be actually correct you need to send an email to it for verification anyway. Otherwise we can start saying not just not empty, it also needs no other @s etc. and before you know it we're rivalling the actually correct attempt up-thread. If you just want to catch typos, encourage entering real address (not just a space or full stop to fill mandatory field) then any basic thing is something, a compromise between legibility and how much it'll catch, we know there's a tonne of (mainly adversarial) bad input it'll miss, that's fine.
    - boulos 2y ago
      Agreed. I should have said so, too.
- petesergeant 2y ago
  I agree with the sentiment, but this one is just shitty. Switch out the stars for pluses and it’d be a lot better
- deleted 2y ago
  [deleted]
IncreasePosts 2y ago
At a certain point I think you're allowed to say you don't care if the person with this email address is capable of signing up or using your service: very.”(),:;<>[]”.VERY.”very@\\ "very”.unusual@strange.example.com
- immibis 2y ago
  Too bad - if that's my email address and you're rejecting it, I'm going to sue you for denying service arbitrarily and win. Not every country is the USA.
  - wk_end 2y ago
    Is there a country where this has happened?
  - Touche 2y ago
    [flagged]
  - DEADMINCE 2y ago
    The denial of service was not intentional so I doubt you would win anything.
    - immibis 2y ago
      You'd have to fix your code, at least.
  - petesergeant 2y ago
    > I'm going to sue you for denying service arbitrarily and win Which country are you claiming this entirely implausible legal scenario would work in?

email:string( regex(".*@.*\\..*") ) This is incorrect regex for email. The correct one is https://pdw.ex-parrot.com/Mail-RFC822-Address.html https://pdw.ex-par

by xonix 2y ago

email:string( regex(".*@.*\\..*") ) This is incorrect regex for email. The correct one is https://pdw.ex-parrot.com/Mail-RFC822-Address.html https://pdw.ex-parrot.com/Mail-RFC822-Address.html

_yb2s 2y ago

That is an absurdly complex regex

Twirrim 2y ago
Email address specs turn out to be rather complicated. I really wish people wouldn't code their own checks rather than use already existing standards. Some languages like Java even include proper checks in their standard library: https://java.net/projects/javamail https://java.net/projects/javamail Several jobs back I had no end of arguments with some Java devs about not writing their own checks, that kept routinely failing on legitimate addresses.
- smrtinsert 2y ago
  It's all devs in general. As a java dev I have lost count of the number of times I have to tell any dev not to use a damn regex to validate emails.
- soco 2y ago
  But why do you even need to validate that email? Send the subscriber a confirmation link - if they get it then it was valid, if not then it's on them to fix the situation in whatever way they find fit.
- _yb2s 2y ago
  A single massive and unreadable regex isn't an appropriate way to validate a spec that complex. With its complexity it can't be logically evaluated- only tested, whereas a function that breaks the spec out into steps/parts is going to be a lot more maintainable, readable, and auditable.
brabel 2y ago
It really is, I wonder if anyone has tested that extensively. It's so complex that just by reading it I don't think anyone would be able to confirm it matches the RFC correctly.

warkdarrior 2y ago

There is a typo on line 17.

OJFord 2y ago

It's a pragmatic one. It has no false negatives, and there's rarely a reason to care about false positives. (Especially not where a stricter regex would (be the only mechanism to) catch it, but a fake-but-valid address wouldn't trivially bypass it.)

boulos 2y ago
At the very least, I assume .+ at the start is a better choice. The RFC says: addr-spec = local-part "@" domain ; global address atom = 1*<any CHAR except specials, SPACE and CTLs> word = atom / quoted-string so I think the bit in front of the @ has to be non-empty.
- OJFord 2y ago
  Yeah, I agree, I think I'd have written that myself, but I don't think I'd reject it in review on that basis. I don't agree with sibling comment that it's 'shitty', it's trivially improved sure but it basically doesn't matter - if you want it to be actually correct you need to send an email to it for verification anyway. Otherwise we can start saying not just not empty, it also needs no other @s etc. and before you know it we're rivalling the actually correct attempt up-thread. If you just want to catch typos, encourage entering real address (not just a space or full stop to fill mandatory field) then any basic thing is something, a compromise between legibility and how much it'll catch, we know there's a tonne of (mainly adversarial) bad input it'll miss, that's fine.
  - boulos 2y ago
    Agreed. I should have said so, too.
petesergeant 2y ago
I agree with the sentiment, but this one is just shitty. Switch out the stars for pluses and it’d be a lot better
deleted 2y ago
[deleted]

IncreasePosts 2y ago

At a certain point I think you're allowed to say you don't care if the person with this email address is capable of signing up or using your service: very.”(),:;<>[]”.VERY.”very@\\ "very”.unusual@strange.example.com

immibis 2y ago
Too bad - if that's my email address and you're rejecting it, I'm going to sue you for denying service arbitrarily and win. Not every country is the USA.
- wk_end 2y ago
  Is there a country where this has happened?
- Touche 2y ago
  [flagged]
- DEADMINCE 2y ago
  The denial of service was not intentional so I doubt you would win anything.
  - immibis 2y ago
    You'd have to fix your code, at least.
- petesergeant 2y ago
  > I'm going to sue you for denying service arbitrarily and win Which country are you claiming this entirely implausible legal scenario would work in?