Re: [ietf-smtp] Email address maximum length2019-11-23 12:37:56
As Dr. Klensin alluded to, there are many legacy reasons why short limits exists.
In my technical view, an important consideration is that the transport system itself, including the SMTP state machine field inputs and also the RFC 822/2822/8322 header field data is still acceptable to 1000, 998+EOL, where EOL in the SMTP protocol are the control codes, <CR><LF>, carriage return, linefeed. An important consideration given the fact, OSes like *nix and Mac systems have different EOL delimiters for text lines/files.
From there, any limits would be with integrated mail systems or add-ons, i.e. filters, translators - not SMTP. For example, for our Wildcat! system which originated in the 80s using text-based console/terminal interfaces, these were legacy mail systems designed around the 80x25 terminal displays, so for input, the field could be less than 80 like maybe 70-72 to allow for a field prompt:
123_123456789012345678901234567890123456789012345678901234567890123456789012 TO:_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxUI-wise, coupled with the other important Mail header fields to be shown on a 80 columns console; From, To, Subject and Date, it was a common UI design consideration to have a "nice" display, or even print. Of course, as GUI came alone, these considerations changed to allow for longer fields.
But realistically, using such a long email address, Long user-id and/or long domain name is not common. Unless there is some non-human system behind it, not many folks will use very long addresses.
Any proposal to clarify limits with the codification of existing guidelines, we will always have the UI device limit issues to consider. For compatibility reasons, our mail system, the original storage format is still limited at 72. Since this predated RFC822 mail format, it is also the User Name limit. We still need to consider Smart Watches and smaller display devices. Even with GUI displays, we will naturally want a "clean display", not wrapped around, etc.
-- HLS On 11/23/2019 8:38 AM, Viruthagiri Thirumavalavan wrote:
Thanks for the clarification Dr. Klensin. Very helpful. I'll work on the Internet Draft today. Thanks. On Sat, Nov 23, 2019 at 6:05 PM John C Klensin <john-ietf(_at_)jck(_dot_)com <mailto:john-ietf(_at_)jck(_dot_)com>> wrote: Just to clarify a few things.... (1) Errata, even if addressed to standards track documents and "verified", are effectively advisory because they do not represent formal IETF consensus for changing anything. The only way to actually change a substantive requirement of a standards track is another standards track RFC. (2) That said, RFC 3696 is not a standards track document. It is informational piece that was not processed by the IETF. Nor was it intended to even offer advice about what SMTP senders or receivers should do: its audience was applications that intended to read email addresses from forms or the like and put them into databases or similar arrangements. If that isn't sufficiently clear, I invite you to file an erratum against that document with proposed text. However, I have it on good authority that the author of 3696 has seen sufficiently little recognition and adoption of that document (e.g., I've noticed that the practice of claiming that local-parts with character like "+" in them is widespread despite clearly being valid in 821/2821/5321 and called out in 3696) that the odds of its being updated to reflect any errata, or even any changes from RFC 2821 and 2822 (on which it was based) to 5321 and 5322 are extremely small. Maybe the author's mind could be changed by strong statements of support and need from the community, but I wouldn't give even that great odds (and see below). (3) The main impediment to changing the restrictions imposed by RFC 821 (or 2821 or 5321) is that there are SMTP clients embedded into countless devices were the code cannot be upgraded. I note that RFC 1425 was published in 1993 but we still see SMTP sessions opened with HELO. The number of SMTP servers embedded in devices is much smaller, but almost certainly still a significant number. One implication of the embedded application problem is that, even if the limit were somehow changed in the core specification (again, that has nothing to do with 3696), the longer local parts would fail in a lot of places. My guess is that, if you posted an Internet-Draft to make that change, you'd get little or no traction, both because of those imbedded systems and because there is a better way to do it (see (4)), but you are welcome to try. If you want to go down that path, I'd recommend you do so _really_ quickly because there is an effort afoot to get revisions to 5321 and 5322 out there. If you want such a change, you'd need to get an I-D posted, approved (with IETF [rough] consensus and published as a Proposed Standard. You would then need to demonstrate implementation experience and widespread deployment and then convince the IESG to issue another Last Call to move the document to Internet Standard, and do all of that quickly, because there is about zero chance that anything would be included in a 5321bis that would force it back to Proposed Standard. (4) Now, assume that you were confident you could really gather community consensus that a change would be a good idea for use in specific contexts. The way to do that would be to define an SMTP extension for longer local parts in the kinds of applications you cite, imposing whatever new restrictions you thought appropriate. By contrast to (3), that would be easy. No modification to 5321 would be needed and legacy embedded applications would either not recognize the extension mechanism or would not offer or request the extension. 3696 would not change, but applications that wanted to support those generated addresses would have to understand them anyway. There are probably some interactions with SMTPUTF8 (RFC 6530 and friends), but I don't imagine they would be too hard to sort out, if necessary by prohibiting use of both extensions at the same time. I look forward to a specific proposal in an Internet Draft. Good luck, john (for identification: editor or author of standards track RFCs 2821, 5321, and 6530; author of Informational RFC 3696) --On Saturday, November 23, 2019 13:02 +0530 Viruthagiri Thirumavalavan <giri(_at_)dombox(_dot_)org <mailto:giri(_at_)dombox(_dot_)org>> wrote: > This errata <https://www.rfc-editor.org/errata/eid1003> sets > the maximum email address length to 256 characters. > > This errara <https://www.rfc-editor.org/errata/eid1690> seem > like corrected that part and now the maximum email address > length is 254 characters. > > I have tested major mail services like Gmail, Outlook and > YahooMail for RFC email address length compatibility. > > interestingly, they are all going like > > ¯\_(ツ)_/¯ > > ================== > > Gmail: > > Gmail seem like it accepts mail when the email address length > is up to 900 characters. > > I was able to successfully deliver mail using the following > 900 character address. > > sssssssssklmnabcsssbcsssdefghijklmnabcdefghabcdefghijklmnabcss > sabcdefefgabcdefghijsssssssklmnabcsssabcdefghijklmnabcdefghabc > defghijklmnabcsssabcdefghisjklmnabcdefghijhjhjhjhjhjhjhjjjklmn > aabcdefghijklmnabcabcdefghijklmnabcdefghijhjhjhjssssshjhjhjhjj > jklmnabcdefghijklmnabcdefghijklmnababcdefghijklmnabcdefghijhjh > jhjhjhjhjhjjjklmnabcdefghijklmnabcdefghijklmnabcdefghjjjhjhjhj > ssshjhjhjhjhjhjhjhjhjjjhjhjhjhjhjhjhjhjhjhjhjhjhjjjssssshsssss > ssssjhjabcdefghijklmnabcsssabcdefghijklmnabcdefghijhjhjhjhjhjh > jhjjjklmnaabcdefghijklmnabcabcdefghijklmnabcdefghijhjhjhjhjhjh > jhjjjklmnabcdefghijklmnabcdefghijklmnababcdefghijklmnabcdefghi > jhjhjhjhjhjhjhjjjklmnabcdefghijklmnabcdefghijklmnabcdefghjjjhj > hjhjhjhjhjhjhjhjhjhjhjjjhjhjhjhjhjhjhjhjhjhjhjhjhjjjssssshssss > ssssssssssssjhjefgabcdefghijsssssssklmnabcsssabcdefghijklmnabc > defghabcdefghijklmnabcsssabcdefghijklmnabcdefghijhjhjhjhjhjhjh >jjjklmnaabcdefghijkl(_at_)hghghgh(_dot_)com <mailto:jjjklmnaabcdefghijkl(_at_)hghghgh(_dot_)com> > > ================== > > Outlook: > > 327 characters. > > I have no idea how they came to that number. I hope that's > not an arbitrary number. > > I was able to successfully deliver mail using the following > 327 character address. > > naaabcsdefghijklmnabcsssabcdefghijklmnabcdefghijhjhjhjhjhjhjhj > jjklmnaabcdefghijklmnabcabcdefghijklmnabcdefghijhjhjhjhjhjhjhj > jjklmnabcdefghijklmnabcdefghijklmnababcdefghijklmnabcdefghijhj > hjhjhjhjhjhjjjklmnabcdefghijklmnabcdefghijklmnabcdefghjjjhjhjh > jhjhjhjhjhjhjhjhjhjjjhjhjhjhjhjhjhjhjhjhjhjhjhjjjssssshsssssss >ssjhj(_at_)hghghgh(_dot_)com <mailto:ssjhj(_at_)hghghgh(_dot_)com> > > ================== > > I'm more concerned about the local-part limitation set by RFC. > > RFC 821 says: > > user > The maximum total length of a user name is 64 characters. > > RFC 2821 says: > > local-part > The maximum total length of a user name or other local-part is > 64 characters. > > <https://www.rfc-editor.org/rfc/rfc5321#section-220.127.116.11.1> > RCF 5321 says: > 18.104.22.168.1. Local-part > The maximum total length of a user name or other local-part is > 64 octets. > > It's been almost 4 decades since RFC 821. The world has > changed so much since. So It doesn't make any sense to stick > to that 64 character limit. > > Variable Envelope Return Path (VERP) and Sender Rewriting > Scheme (SRS) are 2 perfect examples where 64 character limit > actually causes issues. > > VERP: > > unique-identifier+john=acme(_dot_)com(_at_)example(_dot_)org <mailto:acme(_dot_)com(_at_)example(_dot_)org> > > Ifacme.com <http://acme.com> sticks to the RFC limit 64 characters and a user > fromacme.com <http://acme.com> picked a 64 character username, then the above > VERP address structure won't work. > > SRS: > > SRS uses similar structure to avoid SPF failures. Microsoft > seem like recently adopted > <https://support.microsoft.com/en-in/help/4490129/sender-rewri > ting-scheme-srs-in-office-365> SRS in their office 365 product. > > SRS0=HHH=TT=example.org <http://example.org>=alice(_at_)example(_dot_)com <mailto:alice(_at_)example(_dot_)com> > > Where HHH is "hash-based message authentication code", > computed against a local secret, but only a part of it is used. > > SRS1 rewriting an already rewritten address, in a multi-hop > scenario. > > So the address would look like > > SRS1=HHH=example.com <http://example.com>==HHH=TT=example.org <http://example.org>=alice(_at_)example(_dot_)net <mailto:alice(_at_)example(_dot_)net> > > since SRS1 incorporates 2 domains in the local-part, 64 > characters are not enough. > > ================== > > I think we are still sticking to that number 64 because it was > defined in RFC 821. > > Is there any valid reason why we still need that limitation? > If not, Can we remove that limitation? > > Look forward to hearing your thoughts. > > Thanks very much. -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. _______________________________________________ ietf-smtp mailing list ietf-smtp(_at_)ietf(_dot_)org https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________ ietf-smtp mailing list ietf-smtp(_at_)ietf(_dot_)org https://www.ietf.org/mailman/listinfo/ietf-smtp