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> 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
==================
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
==================
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
If acme.com sticks to the RFC limit 64 characters and a user
from 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=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==HHH=TT=example.org=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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp