Introduce a setting to make the top-level domain optional for email validation.

What about user@localhost?

According to 2.3.5. Domain Names of RFC 5321 (which is referenced from 3.4.1. Addr-Spec Specification of RFC 5322):

A domain name (or often just a "domain") consists of one or more components, separated by dots if more than one appears. In the case of a top-level domain used by itself in an email address, a single string is used without any dots.

It may not be valid on the Internet, but it might still be a valid domain on an intranet or localhost, and therefore, should not be disallowed.

This is the problem with validation of user inputs. Email validation is an age old classic. If we go 100% with the official specification, then it can be either too strict or too loose, depending on what we want.

In Oadaeh's case the email validator isn't useful. I wonder if we should allow some configuration of the built-in email validator? e.g. to allow intranet or not etc.

Here's an in-depth take on using regular expressions for email validation:
http://www.regular-expressions.info/email.html

Check out the PHP function:filter_var($email, FILTER_VALIDATE_EMAIL)
https://secure.php.net/manual/en/filter.filters.validate.php

Regarding "partial" addresses with no . in the domain part, a comment in the source code (in ext/filter/logical_filters.c) justifies this rejection thus:

     * The regex below is based on a regex by Michael Rushton.
     * However, it is not identical.  I changed it to only consider routeable
     * addresses as valid.  Michael's regex considers a@b a valid address
     * which conflicts with section 2.3.5 of RFC 5321 which states that:
     *
     *   Only resolvable, fully-qualified domain names (FQDNs) are permitted
     *   when domain names are used in SMTP.  In other words, names that can
     *   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
     *   in Section 5) are permitted, as are CNAME RRs whose targets can be
     *   resolved, in turn, to MX or address RRs.  Local nicknames or
     *   unqualified names MUST NOT be used.

FWIW Drupal 8 uses https://github.com/egulias/EmailValidator

Thanks @cilefen. That's good to know :)

I fixed with custom code like this:

/**
 * Implements hook_element_info_alter().
 */
function my_module_element_info_alter(array &$types) {
  if (isset($types['email'])) {
    // Add custom email validation for domains.
    $types['email']['#element_validate'][] = [Myclass::class, 'validateEmail'];
  }
}

  /**
namespace Drupal\my_module\Myclass;

use Drupal\Core\Form\FormStateInterface;

   * Custom element validation handler for #type 'email'.
   *
   * Note that #maxlength and #required is validated by _form_validate() already.
   */
  public static function validateEmail(&$element, FormStateInterface $form_state, &$complete_form) {
    $value = trim($element['#value']);
    $form_state->setValueForElement($element, $value);

    if (empty($value)) {
      return;
    }

    if ($value !== '' && !\Drupal::service('email.validator')->isValid($value) || !filter_var($value, FILTER_VALIDATE_EMAIL)) {
      $form_state->setError($element, t('The email address %mail is not valid.', ['%mail' => $value]));
    }
  }

If you want the option of rejecting non routable addresses (fred@localhost), you want the patch in https://www.drupal.org/project/webform/issues/3173490, which optionally does additional checking on top of what the core validator does.

Curious why the default email validation fails: "Tom Smith" even though this is valid and the Drupal mail system supports this.

A new module to make this configurable: https://www.drupal.org/project/evac

Thanks @dmezquia

@andreasderijcke great module, thanks for your work! 🎉

IMO this issue should be reopened. Apart from https://www.drupal.org/project/commerce_paypal, there are / will be a lot of contrib modules, which require an e-mail adress to have a top-level-domain. And I don't think the modules itself should add this validation.

We should introduce a setting, to make the top-level domain optional for email validation. I adjusted the issue summary accordingly.

From my opiniton this would be a perfect example for a settings.php setting in core which can be overridden... but let's see what the others think.