egulias/EmailValidator allows addresses without TLDs

Addresses without dots are allowed, with some exceptions:

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.

http://tools.ietf.org/html/rfc5321#section-2.3.5

The full RFC section should be read by anyone interested in this issue http://tools.ietf.org/html/rfc5321#section-2.3.5.

As an example, username@localhost should be considered valid (#1478656: Unable to use @localhost in email address for site information)

This still blocks international adoption

My team and I discovered this issue today and were digging in. I made a comment over on https://www.drupal.org/node/2997196#comment-13475788

TL;DR: Why can we not specify the validator we want to use for email? The library provides a number of them and it would allow for more use cases without additional modules being implemented.

This same question came from a client today.

I think this should be considered won't fix, as the RFC explicitly allows this as stated in #2.

https://serverfault.com/questions/721927/can-you-have-an-email-address-w... is the same question.

As an example, the .tt TLD has MX records so example@tt is a perfectly valid email address and we should not stop whoever owns these email addresses from using them in Drupal.

According to #1 and #15, and my own reading of RFC5321 there seems to be nothing to do here.

#12 asks how to specify a custom validator which is suitable for a separate issue, a Support request.

Agreeing with @longwave and @quietone about the fact that there's nothing to do here.

If someone wants to implement a custom validator, the Change Record here: https://www.drupal.org/node/2997196 mentions:

In order to change core's email validation you can swap out the existing email.validator with a service that implements \Drupal\Component\Utility\EmailValidatorInterface. See https://www.drupal.org/docs/8/api/services-and-dependency-injection/alte... for more. To stay compatible with existing Drupal 8 code, it is recommended that the new class extends from \Egulias\EmailValidator\EmailValidator.

@Spokje, thank you for answering the question in #12. I completely forgot to look at the change record.

I concur, so that makes four of us, so going to mark this as works as designed

Thanks everyone

Here's a new-ish module for greater control over email validation:

https://www.drupal.org/project/advanced_email_validation