string(258) ""xxxx"."xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxx.com"
string(260) ""xxxx"."xx"."xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxx.com"

etc etc etc also all validate as valid emails (take one local character away for every dot separated quoted group you add

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.

including the very article cited in the php source code ("The regex below is based on a regex by Michael Rushton" IE http://squiloople.com/2009/12/20/email-address-validation/)
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

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."

https://tools.ietf.org/html/rfc5321

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

it does however say this (direct copy-paste)

"4.5.3.1.1.  Local-part

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

4.5.3.1.2.  Domain

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

4.5.3.1.3.  Path

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


256 = path <email@email.email> remove the <> that leaves 254 characters allowed in an address in smtp

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.