Not a laravel issue. that is technically a valid email address. Check the rfc for mailbox and address.

Notice that if you tell the browser to validate the email address, it will also pass.

I posted about this 4 days ago - laravel/ideas#1555

I suspect this to come up more frequently as developers begin to adopt 5.8

Mailgun, SES etc would all reject these emails. I'm sure the audience thats running their own mail server is also quite slim. Just seemed more sense to me to actually extend the validator and use this library if you need it without it being default functionality.

A quick search around about valid email addresses and almost in all cases this crops up: "ICANN highly discourages dotless email addresses"

Try signing up to any major SaaS application with hello@something and see if it lets you...

As said in my post in ideas, yes it's valid.. but highly unusual, surely a practicality element has to be considered here, not just because the RFC's say so.

The validation is "is this a valid email". Laravel shouldn't make the decision to block valid emails because they're in a format that is rarely used, or only used in certain cases. This is the perfect case for a custom validation if this is important in your app.

Possibly there could be a second email validation added to Laravel for the "common" email case, but the default email validation should remain as-is, IMO.

Unless you're actually pinging the email during validation, there's nothing ensuring a legitimate email address anyway, although there are several packages available that do this exact thing.

As others have pointed already, although unusual, something@something is technically valid, so it's not a bug.

Unfortunately this GitHub area is not for ideas, suggestions etc. This is only for issues/bugs with the framework code itself. I will be closing your ticket here. You are able to open a ticket at https://github.com/laravel/ideas if you would like to propose alternatives.

Ultimately, even if they put a more traditional syntax like something@something.fake - that's not more/less likely to be true than the other example. Unless you do email validation, there is no way to be sure.

Must stop the delirium!
It's not because the standard doesn't require the .TLD, that you must apply it. It is a matter of common sense.
Please, put the validation as under 5.7 and stop messing !!!

@cotiga just create a custom rule. It's so easy to do 😕

Why do you always expect "the framework to do stuff" jeez

the answer here imo is to add your own validation rule which has the rules you want.

other than sending a verification link to the given email there is no real way of knowing that an email address is valid and correct.

me@unregistered-domain is no less valid than me@unregistered-domain.com

I completely understand what you are saying.
But here, I do not think about what the RFC says, I think validation of the visitors emails address.
The validation must verify the syntax of the email address, this is what has been done for 20 years by a "normal" email address validation scripts.
Today I am told that an address is valid without TLD! OK, I must be too old to understand this kind of nonsense.
Claudio, if I use a framework, it is precisely for not to have to "overecode" this kind of nonsense (which worked well until v5.7)

Today I am told that an address is valid without TLD

email addresses dont have to have a tld to be valid.

maybe they do for whatever mail provider your choosing to use, but that is because they are adding tighter restrictions, which you are also able to do

By the way, this case also does not fail, while this is an invalid address:

$validator = Validator::make(['email' => 'invalid @gmail.com'], [
    'email' => 'required|email',
]);

dd($validator->fails()); // returns false, which is incorrect

So if you place a space right before the @, if does not fail, while space is not allowed in email adresses.

But if I test with

$validator = Validator::make(['email' => 'invalid email@gmail.com'], [
    'email' => 'required|email',
]);

dd($validator->fails()); // returns true, which is correct

the validation fails. so as long as the space is anywhere in the text but not right before the @, the validation is correct.

Again, spaces are allowed in the local part of the address. Most providers don't allow it but it is a valid email.

Maybe a flag can be added requiring the email to be a "common" valid email.
I agree with the fact that if the email is strictly valid, then it's valid.

I hate the fact that I just added a regexp rule to my email field validation... That's not very DRY. Is there a good way to override the existing validation rules?

The RFC is clear, but also probably not a common real-world use-case. In the meantime, tagging myself to this ticket so that I will get updates.

@mattrabe you can use the filter type validation for the pre-5.8 behavior: https://laravel.com/docs/6.x/validation#rule-email

@driesvints Thanks! Somehow I hadn't spotted that before

the answer here imo is to add your own validation rule which has the rules you want.

other than sending a verification link to the given email there is no real way of knowing that an email address is valid and correct.

me@unregistered-domain is no less valid than me@unregistered-domain.com

I ran into this issue today, and respectfully disagree here.

This is what is built into Laravel's default auth/register controller:

https://github.com/laravel/laravel/blob/master/app/Http/Controllers/Auth/RegisterController.php#L53

When a user registers with an email that passes that validation ('valid' per your point), there is no way to actually 'verify' if it's correct because the mail system blows up when trying to send the email validation.

Client error: `POST https://api.mailgun.net/v3/xxxxx` resulted in a `400 BAD REQUEST` response:
{
  "message": "'to' parameter is not a valid address. please check documentation"
}

Note: I came across this for the missing TLD in email, so when MustVerifyEmail trait is set having to alter the default register controller that ships with laravel just doesn't feel right

--

To resolve this everywhere to check for both the tld and no white space.

email:rfc,dns,filter

@ryanpaulfyfe - isnt that MailGun not adhering to the RFC?

@laurencei Could be (which I think says enough in and of itself...)!

I think what's evident in this thread and the several others that are out there all around this same topic is that "the 80%" here does not adhere strictly to that, and the fact that laravel is and the default/recommended path breaks in these clear use cases I believe is against the 'laravel way'.

I've personally never seen a domain without a tld and as a quick sample here is both g-suite and gmail disallowing blank spaces in emails:

--

I think the suggestion would be that the 'default' laravel for 'email' would include the dns/filter, and that when people want they specify that vs. the other way around. This will solve the the 80% (more like the 99.9%), and allow normal use cases like the common path from laravel suggest auth -> laravel suggest mail driver to work without everyone having to stumble upon this 'gotcha', to then manually solve.

ref: https://laravel.com/docs/5.8/mail#driver-prerequisites

or as a back-up to note this in the docs more clearly, as IMO everyone that sets things up in the recommended way will eventually run into this.

My 0.02 anyways

For those still having issues with this, use this 'email' => 'email:filter' which uses the filter_var() method under the hood to check if the email is valid. Refer to https://laravel.com/docs/5.8/validation#rule-email for other email validation types .

$this->validate($request, [
'email' => 'required|regex:/(.+)@(.+).(.+)/i',
]);

@ArsalanSiddique if you use regex, you loose some extra validation, like dns validation to confirm that the email's domain actually exists.
Best way IMO is to use email validation as proposed above.
Regards