php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69581 filter_var() FILTER_VALIDATE_EMAIL, E-Mail length
Submitted: 2015-05-06 06:04 UTC Modified: 2015-05-08 07:23 UTC
From: sebastian at dmwd dot de Assigned:
Status: Not a bug Package: Filter related
PHP Version: 5.6.8 OS: Linux
Private report: No CVE-ID: None
 [2015-05-06 06:04 UTC] sebastian at dmwd dot de
Description:
------------
Validation of long e-mail addresses with filter_var and FILTER_VALIDATE_EMAIL fails.

Test script:
---------------
var_dump(filter_var('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@foo.com', FILTER_VALIDATE_EMAIL));


Expected result:
----------------
string(78) "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@foo.com"


Actual result:
--------------
bool(false)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-05-06 11:50 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2015-05-06 11:50 UTC] cmb@php.net
Apparently, the behavior has changed as of PHP 5.2.14/5.3.3: <http://3v4l.org/7iHni>
 [2015-05-08 06:12 UTC] rasmus@php.net
-Status: Verified +Status: Not a bug
 [2015-05-08 06:12 UTC] rasmus@php.net
RFC 5322 section 4.5.3.1.1 states:

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

This address is therefore invalid according to the strict interpretation of the RFC
 [2015-05-08 06:30 UTC] yohgaki@php.net
I agree to have RFC compliance in general.
However, most mail system allows "username part == max file name length". It's 255 bytes or so usually. 64 octets limit seems a bit too severe to me. Perhaps, double the limit for user names? There may be system generated long user names for some purposes. 64 bytes would be long enough for almost all user names, though.
 [2015-05-08 07:23 UTC] rasmus@php.net
The 64 octets limit for the local part is pretty well-known and it is implemented in many smtp servers. I think it would be a really bad idea for us to state that an address with a local part larger than 64 is perfectly valid and then have it not actually work when people try to send mail with it.

A quick web search reveals:

https://kc.mcafee.com/corporate/index?page=content&id=KB56459

That is some random McAfee email server appliance which clearly has a default limit of 64 for the local part. You have to manually go in and override it to make it accept longer addresses.

And another one:

http://esupport.trendmicro.com/Pages/Syntax-error-SMTP-Error-Code-501-occurs-when-receiving-mails-with-very.aspx

And another:

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu001/smtpcommands.htm
 [2015-05-14 09:50 UTC] a at b dot c dot de
The "maximum" values given in RFC5321 are the _smallest_ maxima that a server can support and still claim compliance. It says that a server that rejects a local-part of sixty-four-octet-local-partdefg4abcdefg5abcdefg6abcdefg7abcdefg8 on the grounds that it's "too long" is noncompliant. The logical converse is *not* that sixty-five-octet-local-partdefg4abcdefg5abcdefg6abcdefg7abcdefg8X is too long, but only that a compliant server will not reject sixty-four-octet-local-partdefg4abcdefg5abcdefg6abcdefg7abcdefg8 on the grounds of length.

ยง4.5.3.1 notes that longer address components SHOULD be avoided, but may sometimes be necessary, and concludes "To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used."
 [2019-10-11 06:18 UTC] ated2019 at gmail dot com
RFC 5322 section 4.5.3.1.1 states:

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

This address is therefore invalid according to the strict interpretation of the RFC
https://sushkom.com/antivirus-software/windows
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun Jan 23 07:03:33 2022 UTC