User email column too short (only 64 chars, should be 255)

Confirmed.

We should attempt to comply to the RFC. At the same time, text fields are slow compared to varchars, so perhaps just increasing this to 255 is a good start.

It makes complete sense to bump that to 255 characters.

Attached is a patch to bump the email field to 255 characters.

Are we not too concerned about complying to the RFC? It would make the DB slower sorting TEXT fields, but at the same time, standards-compliance is a good thing.

There is a big difference between a "standard compliant email address" and a "email that a website should accept as valid". For example, "Damien Tournoud"@[2001:0db8:85a3:08d3:1319:8a2e:0370:7334] is a standard compliant email address, but probably one any decent website should not accept as valid.

In the current case, I don't see any real person having an email address longer then 255 characters (not even 64 characters for that matter). So yes we can bump to 255 characters, because the 64 character limit seems arbitrary low, but going over 255 characters does no make a lot of sense.

There is no upgrade path needed - the old, short email addresses will work fine in the new, longer field.

Also, if varchars longer than 255 are only available in MySQL 5.0.3, then they still violate the posted minimum requirements of MySQL 5.0. Either we would have to bump the minimum requirements, or just stick with 255.

Ah, for some reason, I thought the database was already set to use 255 chars.

Patch attached with a schema update.

You need change also user_schema() in user.install :

-        'length' => 64,
+        'length' => 255,

http://dev.mysql.com/doc/refman/5.0/en/char.html :

Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions. The effective maximum length of a VARCHAR in MySQL 5.0.3 and later is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used.

In contrast to CHAR, VARCHAR values are stored as a one-byte or two-byte length prefix plus data. The length prefix indicates the number of bytes in the value. A column uses one length byte if values require no more than 255 bytes, two length bytes if values may require more than 255 bytes.

Oops, my bad! Fixed...

@lilou, that change won't work with the current minimum requirements of MySQL 5.0, since a user may have a version < 5.0.3, so we would have to change the system requirements, which would be difficult to justify for such a trivia feature.

Also, can you guarantee that Postgres and sqlite support this feature as well?

Patch looks good, and RTBC when testbot is repair.

Actually, spec is that the email address can be at most 254 characters long, not 320.

RFC5321 (SMTP) section 4.5.3.1.3 restricts the path element to 256 chars, including opening and closing angled brackets.

See also:
http://www.eph.co.uk/resources/email-address-length-faq/

Who cares? Let's bump that to 255.

Note that the article (See also: http://www.eph.co.uk/resources/email-address-length-faq/) actually references this bug, and makes a solid argued case that '254' is the correct value to support.

Who cares? Let's bump that to 255.

Although I have little doubt that most SMTP implementations are resilient enough to handle overlong forward-path entries, it is still bad form for Drupal to overflow it. If 254 is the standard, why not simply go with 254? It fits the older (MySQL pre 5.0.3) varchar implementation, and is sure not to overflow SMTP.

I feel inclined to support the 254-character argument supported by the article posted before:

The actual maximum email length is currently 254 characters:

"The original version of RFC 3696 did indeed say 320 was the maximum length, but John Klensin (ICANN) subsequently accepted this was wrong."

"This arises from the simple arithmetic of maximum length of a domain (255 characters) + maximum length of a mailbox (64 characters) + the @ symbol = 320 characters. Wrong. This canard is actually documented in the original version of RFC3696. It was corrected in the errata. There's actually a restriction from RFC5321 on the path element of an SMTP transaction of 256 characters. But this includes angled brackets around the email address, so the maximum length of an email address is 254 characters." - Dominic Sayers

I've checked, and the errata for RFC3696 indeed specifies that the maximum length of an email address that can be sent is 256 characters, including the brackets:

Section 3 says:

In addition to restrictions on syntax, there is a length limit on
email addresses. That limit is a maximum of 64 characters (octets)
in the "local part" (before the "@") and a maximum of 255 characters
(octets) in the domain part (after the "@") for a total length of 320
characters. Systems that handle email should be prepared to process
addresses which are that long, even though they are rarely
encountered.

It should say:

In addition to restrictions on syntax, there is a length limit on
email addresses. That limit is a maximum of 64 characters (octets)
in the "local part" (before the "@") and a maximum of 255 characters
(octets) in the domain part (after the "@") for a total length of 320
characters. However, there is a restriction in RFC 2821 on the length of an
address in MAIL and RCPT commands of 256 characters. Since addresses
that do not fit in those fields are not normally useful, the upper
limit on address lengths should normally be considered to be 256.

Unless there are other well-reasoned objections, I intend to adjust my patch above to 254 chars, as it both matches the specified minimum requirements for D7 (MySQL 5.0) and, via reasonable argument, complies with the RFC.

New patch attached with 254-character email column.

Follow here : #502968: Increase maximum allowable length of email addresses

My apologies.. mine was actually a duplicate of yours.