Why email like "toto@k.__c" is valid?

[ebuildy]

A small script:

<?php
// composer require egulias/email-validator "~2.1"
include("vendor/autoload.php");
use Egulias\EmailValidator\EmailValidator;
use Egulias\EmailValidator\Validation\RFCValidation;

$validator = new EmailValidator();

foreach(['toto@toto.com', 'toto@lsdkjfkldsjf.__com'] as $email)
{
$rfc = $validator->isValid($email, new RFCValidation()); //true
$filtervar = filter_var($email, FILTER_VALIDATE_EMAIL);

echo $email . ' -> RFCValidation=' . ($rfc ? ' OK ' : ' nop ') . ' / filter_var=' . ($filtervar ? ' OK ' : ' nop ')  . PHP_EOL;

}

Gives

toto@toto.com -> RFCValidation= OK  / filter_var= OK
toto@lsdkjfkldsjf.__com -> RFCValidation= OK  / filter_var= nop

HTML5 validator is saying also that toto@lsdkjfkldsjf.__com is wrong.

[egulias]

Hi @ebuildy
Thanks for reporting. toto@lsdkjfkldsjf.__com is RFC 5322 compliant however it contains domain characters that are not allowed by DNS.
So basically it is "valid" because of the specification but it is not valid according to DNS specification.

Would you consider this a bug or a feature :) ?

[ebuildy]

Ho I see.

Any way, I used a regexp validator in top of your to handle this situation.

As a suggestion, I would recommend to have a mode that act like the HTML 5 validator, so front and back have the same behavior.

[egulias]

Hi,
You could also use something similar to https://github.com/egulias/EmailValidator#available-validations and implement an "OR" validation, with one of them being your implementation of the HTML5 regex.

[ampaze]

Would you consider this a bug or a feature :) ?

I would say the real question is:
What is the real world usage of an email address validator?
Is it to have unusable email addresses be flagged as valid or is it to catch unusable email addresses as early as possible?

What about a RealWorldValidation class? With saner domain checks?
Doing DNS lookups as a fallback is not always possible.

[fdelapena]

For the record, another couple of real cases found while sending passed the check (called from Swift Mailer) then making postfix complaining:

example@example.-org
example@example.org||

[egulias]

Hi,
@fdelapena can you please check againts the latest version in v2 (2.1.25), it should be solved?
In v3 this is addressed by being RFC1030 compliant and by allowing PR for additional validations, like the HTML5 regex.

[fdelapena]

Hi @egulias,
If checked with the RFC validator with latest 2.1.x, it still considers the above valid, which seems fine according to the RFC spec, as discussed, so it didn't seem to change in the recent update.

Tested with both SwiftMailer, which uses the RFCvalidator internally throwing RFC exceptions and with the snippet and they didn't change so far, unless you have implemented it in another different validator (DNS based?) implementation I could test if needed. It seems fine to me making it "default" in the validator somehow for v3 due to the behavior change.

By the way, example@example.__com from the first example is valid email for postfix and sends it (it obviously bounces due to non-existent DNS, but that's another thing). However, -com and com|| suffixes are not valid for the postfix validator, so the smtp server has some beyond RFC validations somehow.

I'm catching invalid recipients returned by postfix, so this issue does not affect to me, it's just slightly slower as I need to reconnect the postfix transport in SwiftMailer when this happens.

[egulias]

Hi @fdelapena , thanks for sharing. There's an additional validation possible with #183 .
You can upgrade to v3 (swiftmailer still needs some adaptations to be able to use it) or add the postfix validator with a custom validator implementing the interface a using "MultipleValidationWithAnd" to have both validate the email. This way you could avoid having to reconect.