[Top] [All Lists]

Re: [ietf-smtp] Email address maximum length

2019-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:


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


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.


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,
    (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 <> sets
    > the maximum email address length to 256 characters.
    > This errara <> 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
    > ==================
    > 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.
    > <>
    > RCF 5321 says:
    >  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 
    > <> sticks to the RFC limit 64 characters
    and a user
    > <> 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
    > <
    > ting-scheme-srs-in-office-365> SRS in their office 365 product.
    > <>=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
    > <>
    > 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 mailing list