Bug->Doc #78958 [Nab->Opn]: FILTER_VALIDATE_EMAIL fails on a long email address

From: Date: Fri, 13 Dec 2019 19:49:23 +0000
Subject: Bug->Doc #78958 [Nab->Opn]: FILTER_VALIDATE_EMAIL fails on a long email address
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-17114@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=78958&edit=1

 ID:                 78958
 Updated by:         requinix@php.net
 Reported by:        kaulkwappe dot php-bugs at prvy dot eu
-Summary:            FILTER_VALIDATE_EMAIL fails on a valid email address
+Summary:            FILTER_VALIDATE_EMAIL fails on a long email address
-Status:             Not a bug
+Status:             Open
-Type:               Bug
+Type:               Documentation Problem
 Package:            Filter related
 Operating System:   Debian Buster 10.2
 PHP Version:        7.3.11
 Block user comment: N
 Private report:     N

 New Comment:

Maybe NAB is a bit too aggressive a reaction.

The thing with SMTP is that servers do whatever they want. The standards themselves even acknowledge
this in a few places. So while 64 octets is supposed to be the maximum, the actual emailing industry
will kinda just do whatever it wants.

Some documentation about exactly what rules PHP uses to validate emails (and maybe URLs too?) would
be nice. More than just a link to an RFC. A summary of the rules enforced.
But I think the real bug here is with PHP's listserv. exim, I believe.


Previous Comments:
------------------------------------------------------------------------
[2019-12-13 18:46:14] kaulkwappe dot php-bugs at prvy dot eu

I think a strict mode would make sense since developers may want to

a) prevent users from entering a new, not RFC valid email address, but
b) also prevent pseudo false positives from foreign email addresses.

E.g. when an user answers an email the system would check if the recipient email address you entered
is valid; however, the replying user cannot influence its RFC validness because it is an foreign
email address. Not RFC conform, but still valid. But the same user may not choose a RFC invalid
email address if he wants to create an email alias for himself.

------------------------------------------------------------------------
[2019-12-13 17:52:58] cmb@php.net

While the documentation of FILTER_VALIDATE_EMAIL claims it would
validate against the syntax in RFC 822, that has obviously been
changed with the fix for bug #49576.

------------------------------------------------------------------------
[2019-12-13 15:48:26] kaulkwappe dot php-bugs at prvy dot eu

Seems then to be a bug of the PHP mailing lists (https://www.php.net/mailing-lists.php) since they
return such invalid email addresses.

------------------------------------------------------------------------
[2019-12-13 15:42:22] requinix@php.net

According to RFC 5321, the local part of an email address (before the @) is limited to 64
characters.
https://tools.ietf.org/html/rfc5321#section-4.5.3.1.1

------------------------------------------------------------------------
[2019-12-13 15:15:48] cmb@php.net

Confirmed: <https://3v4l.org/eikec>.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=78958


--
Edit this bug report at https://bugs.php.net/bug.php?id=78958&edit=1


Thread (8 messages)

« previous php.doc.bugs (#17114) next »