php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: sebastian at dmwd dot de
New email:
PHP Version: OS:

 

 [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

Pull Requests

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-2024 The PHP Group
All rights reserved. 		Last updated: Mon Dec 30 14:01:28 2024 UTC