|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68659 VALIDATE_EMAIL max length
Submitted: 2014-12-27 00:14 UTC Modified: 2014-12-30 02:17 UTC
From: support at camolist dot com Assigned:
Status: Not a bug Package: Filter related
PHP Version: 5.6.4 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: support at camolist dot com
New email:
PHP Version: OS:


 [2014-12-27 00:14 UTC] support at camolist dot com
following along with (php uses this syntax for the filter) 

"limiting the entire length to 254 characters"
254 is brought up several times yet the following code validates and is 256 characters 

caused trouble for mysql setting a column to 254 expecting that to be the max size

Test script:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-12-27 00:32 UTC] support at camolist dot com
string(258) ""xxxx"."xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx""
string(260) ""xxxx"."xx"."xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx""

etc etc etc also all validate as valid emails (take one local character away for every dot separated quoted group you add
 [2014-12-30 02:17 UTC]
-Status: Open +Status: Not a bug
 [2014-12-30 02:17 UTC]
We don't document that limit, so the idea that e-mail addresses >254 characters may be validated seems to be expected behaviour to me.

Closing not a bug.
 [2014-12-31 09:44 UTC] support at camolist dot com
including the very article cited in the php source code ("The regex below is based on a regex by Michael Rushton" IE
there are many documented reasons behind the 254 limit available all over the internet

what is the point of the filter validate email if it lets addresses clearly outside of the standard validate?

and while on that topic filter_validate email completely ignores the standards behind allowing unicode in email addresses
 [2015-01-16 04:21 UTC] a at b dot c dot de
For what it's worth, the RFC covering this is RFC5321, "Simple Mail Transfer Protocol", which states that for "local-part@domain" (ยง4.5.3.1):

   The maximum total length of a user name or other local-part is 64 octets [bytes].
   The maximum total length of a domain name or number is 255 octets.

Together with the '@' character itself, the maximum length that MUST be acceptable for an email address is therefore 320 octets.

In other words, addresses that are less than 320 bytes long cannot be rejected as being "too long".

They may even be longer, at the server's discretion:
  "Every implementation MUST be able to receive objects of at least
   these sizes.  Objects larger than these sizes SHOULD be avoided when
   possible.  However, some Internet mail constructs such as encoded
   X.400 addresses (RFC 2156 [35]) will often require larger objects.
   Clients MAY attempt to transmit these, but MUST be prepared for a
   server to reject them if they cannot be handled by it.  To the
   maximum extent possible, implementation techniques that impose no
   limits on the length of these objects should be used."
 [2015-01-16 21:05 UTC] support at camolist dot com

has no mention of 320 at all (ctrl f 320 - not found)

it does however say this (direct copy-paste)

"  Local-part

   The maximum total length of a user name or other local-part is 64
   octets.  Domain

   The maximum total length of a domain name or number is 255 octets.  Path

   The maximum total length of a reverse-path or forward-path is 256
   octets (including the punctuation and element separators).

256 = path <> remove the <> that leaves 254 characters allowed in an address in smtp
 [2015-01-17 01:03 UTC] a at b dot c dot de
Just because a server MUST be able to handle addresses/paths up to 254 octets long for it to meet the standard, that doesn't mean it MUST reject anything longer. It may do, but that's up to the server implementation; the explicit recommendation is to avoid imposing a limit if it can be avoided.

And the derivation of 320 has already been given; the minimax length of a Mailbox string. You know, 320=64+1+255, like this page's CAPTCHA.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Wed Sep 27 21:01:24 2023 UTC