valid_email_address() rejects valid email addresses

Although I believe the root of this problem lies in php more generally, I think I could work around it to allow this kind of address - the code might be a bit a bit inelegant though...

Drupal's valid_email_address() internally uses PHP's FILTER_VALIDATE_EMAIL (see http://php.net/manual/filter.filters.validate.php), which is nice because we don't have to maintain it ourselves.

However, the PHP filter seems to be too strict in some cases. "admin@localhost" doesn't validate either, neither do IDNs.
Most certainly we won't switch to a homebrew regex just for a few cases on the edge of the specification. But it seems the range of unsupported cases is compelling enough to refrain from using FILTER_VALIDATE_EMAIL.

@pancho - if we refrain from using filter_validate_email, don't we kind of need our own regex?

What I was thinking was to keep using filter_validate_email, but to just add a little code to cover these edge cases, since there has to be a finite (and probably small) number of them.

After doing some research, it seems that an address like test.@aon.at does not comply with RFC specifications. Trailing dots are not allowed in the local part. That doesn't necessarily mean we shouldn't allow it, but it's debatable whether such an address is valid.

Correct me if I'm wrong, but I think recent versions of PHP support @localhost addresses. Also there has been some discussion about this previously: https://drupal.org/node/308138.

Solving the IDN issue would be more tricky, and I think that would require a homebrewed regex (which I'm happy to work on). Overall, I think we need to decide between pretty good, works-in-almost-all-cases, easy to maintain code, and "perfect" but harder to maintain code.

1.
Thanks for your research regarding trailing dots. If they aren't allowed, these edge cases certainly aren't a reason to switch back to a homebrew regex.

However we need to take another look at IDNs and test@localhost style addresses:

2.

Solving the IDN issue would be more tricky, and I think that would require a homebrewed regex

Actually, FILTER_VALIDATE_EMAIL is supposed to accept IDNs. However, while not being documented, it is necessary to convert the address to punycode first. So we simply need to wrap the address in idn_to_ascii() before doing the filter_var() check.

Closed #389278: Create IDN encoding and decoding functions because we already require PHP 5.3 now.

3.

Correct me if I'm wrong, but I think recent versions of PHP support @localhost addresses.

From the other issue it seemed to be so. However on bugs.php.net, the discussion went back and forth, and it seems, support has been silently removed again. For the current state, see Rasmus' comment from 2012-08-16 on https://bugs.php.net/bug.php?id=49576.
We could fix it by adding '.local' before doing the filter_var() check, if no TLD is given.

Question is, if we can agree on allowing these. Some argumented against it in #308138: Make valid_email_address() support IDNs, but in the end, our validity test is shallow anyway. Why would we want to disallow test@localhost, while allowing no@valid.mail?
At least we should explicitely allow 'localhost' because it is used by many admins for testing purposes.

I don't think you can call idn_to_ascii() on the whole address - it's just for the domain right? We'll see if this works...

That last one had a couple boneheaded errors.

Aha! The last patch adds an extra @ symbol to every email address. This should work.

After applying the patch email-validation-1427516-15.patch by jlindsey15 in #15 to a Drupal 8 fresh install 8/9, unfortunately all I received were server errors for creating new users like admin@localhost .

Please see screenshots.

Not a major bug.

Added IDN tag

Regarding IDN and IMA (see Wikipedia), this is not just an edge case. We're currently locking out all internatonalized mail addresses.

@Pancho - one thing that needs to be explictly clear that I think has been glossed over is that idn_to_ascii() and idn_to_utf8() are not always available in php 5.3 or php 5.4. They are part of an additional php extention, 'intl', that must be loaded in order for those extensions to function. Basically anywhere that you're going to use those idn functions probably should be wrapped with

if (extension_exists('intl')){
  $domain_ascii =  idn_to_ascii($domain_unicode);
}

Granted if somebody wants to support links to things like http://яндекс.рф , they probably will know that they need to have the intl module enabled. However, without it you will get a Fatal error: Call to undefined function idn_to_ascii().

#2343043: valid_email_address() should use egulias/EmailValidator and become deprecated and some related issues replaced filter_var(). Open a new issue if this is a problem with the new valid_email_address().

Still a problem in D7 ...

This issue is major and active because some people will not be able to create accounts with their valid email addresses. We could back-port #2343043: valid_email_address() should use egulias/EmailValidator and become deprecated. But, I do not know if the Drupal 7 maintainers have a policy of allowing third-party PHP libraries in Drupal core.

Sorry for the noise. @tim.plunkett, I see you had downgraded this to Normal a while ago. It would feel Major to me if I could not create an account. Do what you must if you disagree but can you please include your reasoning if you do?

This related issue seems like it's probably a duplicate.

Postponed on #2343043: valid_email_address() should use egulias/EmailValidator and become deprecated.

I just posted a Drupal 7 back-port on #2343043: valid_email_address() should use egulias/EmailValidator and become deprecated. If one of the affected admins could test it out, that would be great.

This is still open and clearly MAJOR! The functionality is UNUSABLE for international domain names!
Let's please review and fix #2343043: valid_email_address() should use egulias/EmailValidator and become deprecated.

This issue is possibly a critical because for the affected users the software is unusable.

Thanks everyone for reporting this and discussion. #2966195: valid_email_address() should be easily overridable is now committed, therefore closing this as Won't fix. Sites which require this are now able to do custom changes to the valid_email_address() validation via the new hook. It is unlikely that we would do changes to the behavior of the valid_email_address() itself in this D7 phase, as it is widely used function and such changes would affect majority of sites.