valid_email_address() accepts addresses with non-resolving domains

isn't foo@localhost a valid email address ... granted its a fringe case, but valid none-the-less

...in fact according to the list on page 2 of the link you supplied (http://www.linuxjournal.com/article/9585?page=0,1) foo@localhost is valid

Following are the requirements for an e-mail address, with relevant references:

1. An e-mail address consists of local part and domain separated by an at sign (@) character (RFC 2822 3.4.1).
2. The local part may consist of alphabetic and numeric characters, and the following characters: !, #, $, %, &, ', *, +, -, /, =, ?, ^, _, `, {, |, } and ~, possibly with dot separators (.), inside, but not at the start, end or next to another dot separator (RFC 2822 3.2.4).
3. The local part may consist of a quoted string—that is, anything within quotes ("), including spaces (RFC 2822 3.2.5).
4. Quoted pairs (such as \@) are valid components of a local part, though an obsolete form from RFC 822 (RFC 2822 4.4).
5. The maximum length of a local part is 64 characters (RFC 2821 4.5.3.1).
6. A domain consists of labels separated by dot separators (RFC1035 2.3.1).
7. Domain labels start with an alphabetic character followed by zero or more alphabetic characters, numeric characters or the hyphen (-), ending with an alphabetic or numeric character (RFC 1035 2.3.1).
8. The maximum length of a label is 63 characters (RFC 1035 2.3.1).
9. The maximum length of a domain is 255 characters (RFC 2821 4.5.3.1).
10. The domain must be fully qualified and resolvable to a type A or type MX DNS address record (RFC 2821 3.6).

Number 6 does not say "A domain consists of at least 2 labels separated by dot separators" ... in which case you would be right. I wont re-close this issue for a little while to give some others more of a chance to speak up, but I believe that foo@localhost is perfectly legitimate and therefore so is this validation.

foo@localhost is invalid on a live site. This is a great article on email validation: http://www.regular-expressions.info/email.html

You cannot validate 100% of the possible email addresses, only about 99% of them, the article says.

The question is what do you validate to. In our case we validate to the RFC 2822 (the spec for email addresses). What we actually do is use PHP's internal email validation. See http://api.drupal.org/api/drupal/includes--common.inc/function/valid_ema.... valid_email_address() is simply a wrapper around php internals.

If you are looking for an fake email address to use during development try example.com. That won't route anywhere and passes validation. localhost is not an internet routable address and therefore invalid.

...it would be very simple to create a module called "better email validation"

just a thought...

Same here, I don't care about the RFC, an email validation is required which is practical. Why not use this regex? http://www.regular-expressions.info/email.html
The author says that is the best email validation regex. It works 99% of the time in the REAL world, not in theory.

any possible way to alter/override common.inc function ?

As I see it:

• The list of rules posted in #2 is correct.
• "org", "blabla", "localhost" and so on are all valid under rules 1-9.
• However, on most systems only "localhost" and other locally-configured domains will resolve properly (rule 10).

Note that it would not be correct to automatically disqualify any e-mail address without a dot in the domain. Consider a closed company intranet with two servers, one called "drupalserver" and the other "emailserver". The user would navigate to "http://drupalserver" using their browser, and register an account as "me@emailserver". This is entirely valid usage and must be supported.

So, I believe what Nikdilis actually wants is a check in valid_email_address() that the domain part of the address resolves correctly. In most situations "blabla" etc. will not resolve.

I don't know if this is a bug or a D8 feature request; someone else can decide.

I think both angles of this discussion are valid.
It would be nice if the email validation could be configurable.
For example, by default email validation would use the 99% case (domain requires at least 2 parts, separated by a period), but there could be a configuration option to use a strict RFC validator, which would allow localhost etc.

re #12: I was not suggesting that everyone creates a "better email validation" module; I was suggesting that perhaps you would want to scratch your own itch here and create one and then contribute it back to the community so that no one ever needs to write that validation again. I was thinking exactly like a user.

valid_email_address() has been deprecated and replaced with egulias/email-validator. Please re-test.

Email validation will be completed only after checking the domain part is seperated by a dot.

A check in valid_email_address() that the domain part of the address resolves correctly should be there in the email address validation.

What you are asking for goes a bit farther than the others. You want an active network-based check? What if DNS is not responding at that moment, but the address is valid?

Please consider comment #19. Any feature requests like #21 must be opened in the email-validator project.

Know that you can implement your own form validation to do this.

Hi,
Is there any solution for validating email address.Can we handle it in custom validation?
I have posted a query regarding the same on the following link.
https://www.drupal.org/node/2819387
Any suggustions will be helpful.

Thanks.

Local domains should be supported

Doesn't RFC2822 say this is valid "My Name <me@example.com>"? And Drupal suggests and works with this as the site email address and core ->mail() function works with this format. Shouldn't these be included in some (maybe its not this) method to check if valid.

And then also include functions to break into just the mail portion for functions like user_load_by_mail()?

valid_email_address was deprecated in Drupal 8.3.x #2343043: valid_email_address() should use egulias/EmailValidator and become deprecated and replaced with egulias/EmailValidator. And there is an another issue discussing this problem for Drupal 9, #2492667: egulias/EmailValidator allows addresses without TLDs. Therefore, I think this can be moved to Drupal 7 leaving the other in Drupal 9.

Adding related issue for D7. If this will be committed, then everyone can modify the validation as wanted without hacking the core.

#2966195: valid_email_address() should be easily overridable is 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.