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:
123_123456789012345678901234567890123456789012345678901234567890123456789012
TO:_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.
--
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-4.5.3.1.1>
> RCF 5321 says:
> 4.5.3.1.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
|
|