Can't fix Email validation

[Lukas W.]

Affected version

2.0.4

It appears that the custom field e-mail (and probably all e-mail) validation fails to correctly identify some e-mail address schemes.

Following RFC2822:
"email"@domain.com should be valid, but passes neither browser-check nor XF check.
wa'sd@test.com should be valid, passes browser-check but does not pass XF check.
"()<>[]:,;@\\\"!#$%&'-/=?^_`{}| ~.a"@example.org should be valid, but passes neither browser-check, nor XF check
very.unusual.“@”.unusual.com@example.com should be valid, but passes neither browser-check, nor XF check
email@111.222.333.44444 should be invalid, but passes browser-check and XF check
email@-domain.com should be invalid, does not pass browser-check, but does pass XF check
email@domain should be invalid, but passes browser and XF check

All browser checks have been performed in Google Chrome.

Theoretically, e-mails with invalid top level domains should also fail, but with all the new top level domains, this is agreeably a quite useless or expensive thing to verify.

I'm aware that I've chosen some pretty extreme edge cases here, but they keep the number of examples down, so that's why I chose them.

It might also be worth noting that this error isn't exactly helpful for an end-user:

Maybe it could be a little more specified, if possible.

 

[Xon]

RFC2822 (for email address validation) is fairly useless as most email providers don't follow it, rightfully since it is a complete mess. Making XF attempt to resolve to TLD domain would solve most of the fails in browser but passes XF check bits but would cause the server potentially leaking it's IP via DNS. Since the domain could easily have a hostile DNS infrastructure.

 

[Chris D]

Unfortunately, there's not a lot we can do here.

The browser checks are obviously part of the browser so if they're wrong, we can't do anything about it, though generally it's a good thing if we're both wrong, for consistency

As for our checks, they are performed in the SwiftMailer library and so there's nothing there we can directly impact. You could report the issues to them directly, but bear in mind that SwiftMailer 6.x is now available so it's possible some of the issues could have been resolved there. We can't use that for the foreseeable future, though, because it requires PHP 7.x.

https://github.com/swiftmailer/swiftmailer/issues

As for the error, that's not exactly intended to be viewed by the end user. It's an error key which can be used to identify a more specific failure reason, if needed, but generally the phrase please_enter_valid_email is what you should return if the validator returns false.