6 ms·
Not allowing + in an email field is one of my pet peeves. Congrats on finding an amazing-looking regex for email validation instead of thinking about it.
by tclancy 9y ago
Not allowing + in an email field is one of my pet peeves. Congrats on finding an amazing-looking regex for email validation instead of thinking about it.
- Pxtl 9y agoYup. The most email validation I evern implement is "there must be an @ sign with stuff before and after the @ sign". Maybe require a dot in the latter space.
- marksomnian 9y ago.+@.+\..+
- nradov 9y agoThat regex is defective. See benchaney's reply above.
- hfsktr 9y ago.+@.+(\..+)? should satisfy you both right? I use the original or a form of usually when I had to check emails.
- simcop2387 9y agoFully qualified domains actually end in a . If you're allowing sally@google then you must also allow sally@google. To be valid
- eridius 9y agoNo you don't. Email addresses explicitly require any periods in the domain to have at least one (non-period) character after the period. From RFC 5322, the relevant grammar production for the domain looks like dot-atom-text = 1*atext *("." 1*atext) (where atext is letters, digits, or a set of specific punctuation characters that doesn't include periods).
- simcop2387 9y agoAh, I wasn't aware that email addresses defined that differently. it looks like it's also the same way as part of obs-domain as defined by the addr-spec part of that. RFC 822 also seems to say the same thing, it's been way too long since i've tried to read those RFCs.
- dasil003 9y agoThat's identical to just doing .+@.+
- sgustard 9y agoThankfully my email is @@@@@@@.......
- glandium 9y agoOne (probably forgotten) reason people validated email addresses with convoluted regexps is that there are multiple (actually valid per RFC) email addresses formats that can do nasty things. Like explicitly specifying a series of mail servers to go through. They're (hopefully) deprecated and rejected by most servers nowadays, though.
- snakeanus 9y ago> hopefully Why?
- contras1970 9y ago> By default, this feature is turned off. This closes a nasty open relay loophole where a backup MX host can be tricked into forwarding junk mail to a primary MX host which then spams it out to the world. http://www.postfix.org/postconf.5.html#allow_untrusted_routing http://www.postfix.org/postconf.5.html#allow_untrusted_routi...
- benchaney 9y agoStrictly speaking, the dot in the latter space isn't actually necessary. It needs to be a resolvable domain, but if you bought a TLD you could be "name@tld"
- TremendousJudge 9y ago...is there someone out there who did this?
- benchaney 9y agoNot that I'm aware of. Although I wouldn't be surprised if google did it for their employees. They already own the google TLD, they could very easily make it point to the google.com emails.
- OJFord 9y agoHow many HN-reading googlers have you just made to send 'Test' emails to themselves, I wonder!
- bitJericho 9y agoI don't think an @domain is required if it's an email address on the same mail server.
- deleted 9y ago[deleted]
- OJFord 9y agoThat certainly used to work on Gmail; I haven't tried recently. (Obvious caveat being that any provider can trivially append @provid.er if you don't specify, so this isn't really proof that email is specified that way.)
- eximius 9y agoWow, that is literally the only reason I would want a TLD
- vlunkr 9y agoI know lots of developers (myself included) who thought they could write a functional email regex. Eventually you learn that in the end, the way to validate an email address is to send an email.
- OJFord 9y ago> Eventually you learn that in the end, the way to validate an email address is to send an email. In my experience as a user, most people in the end also validate the email address by sending an email, but do no learning.
- xroche 9y agoAllowing + in an email/password field, but failing to properly encode/decode it, is even more infuriating.
- tonmoy 9y agowell, string+{whatever1}@gmail.com mails are redirected to string@gmail.com. So a user can just open account for string@gmail.com and then use that to open thousands of user accounts on the site that allows "+" on the email field. (I used to do this on sites that allowed limited number of free downloads after which you had to pay)
- eridius 9y agoBut that's not a feature of email in general. That's a feature of gmail, and a few other email providers that have followed suit. For email in general, foo@bar.com and foo+baz@bar.com are distinct emails that may go to different users.
- NoGravitas 9y agoI wouldn't say "a few other email providers that have followed suit". As far as I know, that's always been a feature of Postfix, and common with Sendmail before that. And qmail offered "-" for the same purpose (as well as providing a facility for filtering/redirecting mail based on -extensions).
- eridius 9y agoThe point is that foo+bar is a convention that many providers follow and not an actual rule of email, and therefore blocking that doesn't make sense because you'll block legitimate addresses too. Similarly, mail providers can come up with all sorts of different conventions if they want. For example, when setting up a new domain in FastMail, it offers the ability to accept anything@user.dom.ain and turn that into user+anything@dom.ain, and it offers user@anything.dom.ain which it will deliver to user@dom.ain. So here we already have two new conventions that sites can't possibly detect as alternatives to the normal foo+bar@dom.ain.
- e12e 9y agoThe standard (as in most common setup) for djb's qmail, was to accept/forward mail for <prefix>@user.example.com to user@example.com, as in: debian-list@e12e.example.com rather than debian-list+e12e@example.com. While I believe the + was common for postfix, exim and sendmail? There even was a spam-fighting scheme that used this - it took a key, and optional date, and a sender address - and generated a unique address you could give out, that was only valid for a certain time, for a certain set of senders. If the system received a mail with a from address that didn't match the cryptologically signed to-address (e12e-xjjgff65477fc@example.com) - the mail was held back, and the system generated a reply, with a signed reply-to address. A sort of manual grey-listing.