Email Validator... again #21531
Comments
|
(sorry, miss click on my mobile phone) |
|
That was my first "contrib" to SF ever ;) See also #18177 |
|
I'd say is a duplicate of #18177 😊 |
|
Basically you want the most bogus and obvious mistakes filtered, values that possibly can't ever be an email address or are common typos. Sure you can have fancy quoted values in your email, but that is more often a typo than a real email. |
|
@iltar I disagree. Over restricting is more of a concern than under restricting. Under restricting may cause bad input, but it never impacts users. Over restricting may remove bad input, but it always impacts users. For example, my name is "Robert Frawley 2nd". I can't count the number of times, even on government websites where I am legally required to provide my full legal name, that no suffix field is provided and it doesn't accept "Frawley 2nd" as my last name. Or, a suffix field is provided and it only accepts "||", "III", or other roman numerals, and not "2nd". This is an example of programmers over restricting fields. |
|
@robfrawley "Under restricting may cause bad input, but it never impacts users" Until someone changes his email to |
|
If they think that's their e-mail they have other problems. ;-) Our responsibility should be to accept valid e-mails. Over restricting caused my new primary e-mail to not be accepted by 25% of websites for a few months, because it used a new TLD. |
|
@robfrawley They don't think that's their email, it's simply a typo. You can call them "dumb" and what not for making those mistakes, but that's because nothing is telling them it's wrong. I see this come by quite often and is a real issue in our customer portal. We use a background queue system to send out emails so it's not truly validated till seconds or minutes later (depending on queue size) till we get an error in our system. That's why I need a validator that tells the customer "you made a typo, fix it" one way or another. |
|
I was making a light-hearted joke, not calling anyone "dumb". The issue is, typos don't always translate to invalid input. The default metric for e-mail "validation" should be "validity" and not "did someone make a typo", IMHO. |
|
And what I'm pointing at, is that often enough a user fills in |
|
@iltar anyway Just see there: http://sandbox.onlinephpfunctions.com/code/fba5c99b28216f43dfc854d238c510684e9ee377 I know it would be pretty hard to make a regex perfectly match only valid mail but there we just accept wrong mails so we should do something to improve it imo. |
|
I think the best validation would be the one that doesn't make your e-mail sender throw an exception (or crash). The only thing you don't want is your server returning 500 because of bad input. If you want stricter validation, this become business logic linked to you application. So ideally, the validation should depend on the library that actually send the e-mails. For example, if the project use SwiftMailer, then the validator should use the validation function of SwiftMailer; idem for PHPMailer, etc. I don't know if this can be done anyway. It would imply that e-mail libraries implement a standard interface for that purpose... It doesn't matter if |
This PR was merged into the 4.1-dev branch. Discussion ---------- [Validator] Html5 Email Validation Currently we only support a very loose validation. There is now a standard HTML5 element with matching regex. This will add the ability to set a `mode` on the email validator. The mode will change the validation that is applied to the field as a whole. These modes are: * loose: The pattern from previous Symfony versions (default) * strict: Strictly matching the RFC * html5: The regex used for the HTML5 Element Deprecates the `strict=true` parameter in favour of `mode='strict'` | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | #21531 | License | MIT | Doc PR | symfony/symfony-docs#8487 <!-- - Bug fixes must be submitted against the lowest branch where they apply (lowest branches are regularly merged to upper ones so they get the fixes too). - Features and deprecations must be submitted against the 3.4, legacy code removals go to the master branch. - Please fill in this template according to the PR you're about to submit. - Replace this comment by a description of what your PR is solving. --> Commits ------- cf04108 [Validator] Html5 Email Validation
Recently, I stumbled upon this article about validating emails:
https://davidcel.is/posts/stop-validating-email-addresses-with-regex/
We know that validating emails is a complex topic and depending on a lot of factors, people want something stricter than just checking for
@or something simpler than an email being "right".Lots of issues have being creating along the years here about this issue (I wanted to list them all here for reference, but there are just too many of them :)).
What's interesting I think (and I don't remember it being mentioned before but I might be wrong), is how HTML5 actually validates emails:
https://www.w3.org/TR/html5/forms.html#valid-e-mail-address
Would it be a good middle ground that we could offer as a third alternative to our users?
The text was updated successfully, but these errors were encountered: