Subject: [ietf-smtp] Email address maximum length

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sat, 23 Nov 2019 13:02:10 +0530

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.

sssssssssklmnabcsssbcsssdefghijklmnabcdefghabcdefghijklmnabcsssabcdefefgabcdefghijsssssssklmnabcsssabcdefghijklmnabcdefghabcdefghijklmnabcsssabcdefghisjklmnabcdefghijhjhjhjhjhjhjhjjjklmnaabcdefghijklmnabcabcdefghijklmnabcdefghijhjhjhjssssshjhjhjhjjjklmnabcdefghijklmnabcdefghijklmnababcdefghijklmnabcdefghijhjhjhjhjhjhjhjjjklmnabcdefghijklmnabcdefghijklmnabcdefghjjjhjhjhjssshjhjhjhjhjhjhjhjhjjjhjhjhjhjhjhjhjhjhjhjhjhjhjjjssssshsssssssssjhjabcdefghijklmnabcsssabcdefghijklmnabcdefghijhjhjhjhjhjhjhjjjklmnaabcdefghijklmnabcabcdefghijklmnabcdefghijhjhjhjhjhjhjhjjjklmnabcdefghijklmnabcdefghijklmnababcdefghijklmnabcdefghijhjhjhjhjhjhjhjjjklmnabcdefghijklmnabcdefghijklmnabcdefghjjjhjhjhjhjhjhjhjhjhjhjhjhjjjhjhjhjhjhjhjhjhjhjhjhjhjhjjjssssshssssssssssssssssjhjefgabcdefghijsssssssklmnabcsssabcdefghijklmnabcdefghabcdefghijklm[email-masked]

==================

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.

naaabcsdefghijklmnabcsssabcdefghijklmnabcdefghijhjhjhjhjhjhjhjjjklmnaabcdefghijklmnabcabcdefghijklmnabcdefghijhjhjhjhjhjhjhjjjklmnabcdefghijklmnabcdefghijklmnababcdefghijklmnabcdefghijhjhjhjhjhjhjhjjjklmnabcdefghijklmnabcdefghijklmnabcdefghjjjhjhjhjhj[email-masked]

==================

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=[email-masked]

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-rewriting-scheme-srs-in-office-365>
SRS in their office 365 product.

SRS0=HHH=TT=example.org=[email-masked]

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=[email-masked]

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.

---

From: John C Klensin <[email-masked]>
Date: Sat, 23 Nov 2019 07:35:00 -0500

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 <[email-masked]> 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.
> 
> 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
> [email-masked]
> 
> ==================
> 
> 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
> [email-masked]
> 
> ==================
> 
> The maximum total length of a user name or other local-part is
> 64 characters.
> 
> 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:
> 
> 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.
> 
> Where HHH is "hash-based message authentication code",
> computed against a local secret, but only a part of it is used.
> 
> 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?
>

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sat, 23 Nov 2019 19:08:18 +0530

Thanks for the clarification Dr. Klensin.

Very helpful.

I'll work on the Internet Draft today.

Thanks.

-- 
Best Regards,

---

From: Hector Santos <[email-masked]>
Date: Sat, 23 Nov 2019 13:37:36 -0500

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:
> On Sat, Nov 23, 2019 at 6:05 PM John C Klensin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Thirumavalavan <[email-masked] <mailto:[email-masked]>> wrote:
>
>     <mailto:[email-masked]>
>     >
>     > ==================
>     >
>     > Outlook:
>     >
>     > 327 characters.
>     >
>     >[email-masked] <mailto:[email-masked]>
>     >
>     > ==================
>     >
>     > unique-identifier+john=[email-masked] <mailto:[email-masked]>
>     >
>     > 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
>     > SRS0=HHH=TT=example.org <http://example.org>=[email-masked]
>     <mailto:[email-masked]>
>     >
>     > SRS1=HHH=example.com <http://example.com>==HHH=TT=example.org
>     <http://example.org>=[email-masked] <mailto:[email-masked]>
>     >
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Sat, 23 Nov 2019 21:19:54 -0500

On Sat, 23 Nov 2019 07:35:00 -0500, John C Klensin said:

> or would not offer or request the extension.

Figuring out what to do with an email that contains a 158 character username
when you attempt delivery to a server that doesn't support the extension is
left as an exercise for the reader. :)

(HInt: The proper action is probably different for sender and recipient fields...)

---

From: John C Klensin <[email-masked]>
Date: Sat, 23 Nov 2019 23:51:48 -0500

--On Saturday, November 23, 2019 21:19 -0500 Valdis Klētnieks
<[email-masked]> wrote:

>> (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.
> 
> Figuring out what to do with an email that contains a 158
> character username when you attempt delivery to a server that
> doesn't support the extension is left as an exercise for the
> reader. :)
> 

Well, actually, if that were done as an SMTP extension, it is
quite clear... or better be if the extension proposal is going
to have any hope of getting IETF consensus.  First, unless the
server advertises that it supports the extension, the language
of 5321 essentially says that the client is not allowed to send
those longer local-parts.  If it did, I assume that the server
would respond with a 501 syntax error (although the way
821/2821/5321 are written and the robustness principle says it
doesn't have to).  If the server announces support for the
extension, it is required to do whatever the extension says it
should do, presumably supporting the long local-part.

So I don't see much ambiguity or reader exercise there at all.  

With regard to the difference between backward-pointing and
forward-pointing addresses (i.e., sender and recipient fields),
one thing I think we've learned from the SMTPUTF8 ("EAI", RFC
6530ff) efforts is that systems that are more permissive about
the first than the second eventually get themselves into
trouble, if only because of the potential to need to generate
response messages or, if those envelope addresses pass through
into the message body (e.g., by having the same address in the
"From:" header fields that appears in the address argument to
the MAIL command) or user-level replies.

There is another lesson from the SMTPUTF8 work that should
inform any proposal that is written.  While the delivery MTA has
to know whether to advertise the extension or not, it generally
has no way to know what MUAs or other interfaces are going to be
used to retrieve and process messages from the mailstore.   If
some of those are capable of handling the extended addresses
(extended in terms of characters present or extended in length
if this turns into a proposal) and others are not, the result is
a fairly complicated situation.   For UTF-8 material, some of
the issues are addressed in RFCs 6533, 6855, and 6856 (and maybe
6857 and/or 6858) but any proposal to make a different exception
to the rules in 5831 would have to examine and address similar
issues.

I still think such an extension proposal would be easier, much
easier, to get through the system than one to simply remove the
64 octet limit on local-parts.

   john

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 24 Nov 2019 12:35:45 +0100

On Sat 23/Nov/2019 13:35:00 +0100 John C Klensin wrote:
> there is an effort afoot to get revisions to 5321 and 5322 out there.

Where?

> [... guidelines for extension publishing omitted ...] because there is
> about zero chance that anything would be included in a 5321bis that
> would force it back to Proposed Standard.

Yet, I think something will have to be said about the now common habit of From:
rewriting.  Section 3.9, Mailing Lists and Aliases, still considers only
rewriting of the envelope from.  Reality now differs.

I don't think such changes would imply going back to PS, given the loosely
normative content of that section.

Best
Ale
--

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 24 Nov 2019 17:05:40 +0530

I have a query regarding the error code "501 Syntax error in parameters or
arguments"

RFC 821 says,

MAIL
               S: 250
               F: 552, 451, 452
               E: 500, 501, 421

RFC 2821 says,

MAIL
               S: 250
               E: 552, 451, 452, 550, 553, 503

RFC 5321 says,

MAIL

               S: 250
               E: 552, 451, 452, 550, 553, 503, 455, 555

It seem like error code 501 accidentally got removed in 2821.

5321 seem like fixed that issue by introducing two new error codes.

   455  Server unable to accommodate parameters
   555  MAIL FROM/RCPT TO parameters not recognized or not implemented

How exactly 2821 based servers responds when the parameters are not
recognized by MAIL command?

-- 
Best Regards,

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Nov 2019 09:10:07 -0500

On 11/24/2019 6:35 AM, Viruthagiri Thirumavalavan wrote:
> I have a query regarding the error code "501 Syntax error in
> parameters or arguments"
>
> RFC 821 says,
>
> MAIL
>                 S: 250
>                 F: 552, 451, 452
>                 E: 500, 501, 421
>
>
> RFC 2821 says,
>
> MAIL
>                 S: 250

Odds are very good, it was not accidentally removed.

501 was most likely codified as a common practice reply code as used 
with among similar client/server protocol engines, such as FTP and 
NNTP. These protocols also use 501, so as a common practice, if you 
were going to write a text-based client/server command/response 
protocol engine, you would most likely consider using 501 for syntax 
errors.  Repeating it in the documentation for each command may have 
been viewed as redundant.  Also 501 is not guaranteed.  Just consider 
this example:

C: MAIL FROM: <[email-masked]>
C: MAIL FROM:<[email-masked]>

One has the extra space. Some strict servers COULD issue an error for 
the first one. Against some strict SMTP servers that exist, client 
could see a 500, 501 or even a 504 or even 555 syntax error response.

While the 500 reply code is generally reserved for an "unknown 
command" response, it is always a possible response for all commands 
from an protocol engine standpoint. Yet, it is not shown in any of the 
updated docs except for commands that could are optional.

> recognized by MAIL command?

As it is described RFC5321 section 4.1.1.11, this will depend on the 
MAIL command ESMTP extension (RFC).

The protocol extension provides specifics describing how the client 
should implements the extension. If parameters are incorrect, the 
protocol COULD use the 5321 guideline for x5z and the compliant SMTP 
client COULD be ready to use the y5z response.  Maybe the protocol 
will say MUST or SHOULD, but it needs to be ready that a RFC2821 
compliant client could support an extension but be also ignorant of 
the 5321 x5z information. So the extension author needs to consider 
this -- not all clients are uptopar with RFC5321.  It could issue a 
500, 501, 502 or even 504 as is described in RFC281 section 4.2.1 for 
the value of the 3rd digit:

    A refinement of that is the 504 reply for
    a command that is implemented, but that requests an unimplemented
    parameter.

No matter what the 5yz value is, it is a very important concept in a 
SMTP client design that the 5yz is followed properly.  The SMTP XYZ 
reply codes are designed to drive (direct) the SMTP client state 
machine. The last thing a server wants is to confuse an automated SMTP 
client with Y and Z reply code details that keeps it from completing 
the transaction.  So the first digit is the most important:

1yz Positive Preliminary reply, CONTINUE
2yz Positive Completion reply, CONTINUE
3yz Positive Intermediate reply, CONTINUE
4yz Temporary Negative Completion reply, SHOULD|MAY TRY AGAIN LATER
5yz Permanent Negative Completion reply, MUST NOT TRY AGAIN

So it doesn't matter if it is 501 or 555. All RFC821/2821/5321 SMTP 
compliant SMTP clients are expected to work the same as far as what it 
does with the transaction when it sees a 5yz response.  Issuing any 
5yz is going drive the client to do the expected thing - don't try it 
again.   This can drive the SMTP client to begin the DSN (Bounce) 
process, if necessary, where the specific Y and Z details along with 
extended reply codes and responses are reported for human consumption, 
i.e, Tech Support, to help zoom in on fixable issues.

-- 
HLS

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 25 Nov 2019 22:49:09 +0530

Very informative.
Thanks Hector.

-- 
Best Regards,

---

From: Brandon Long <[email-masked]>
Date: Mon, 25 Nov 2019 13:10:57 -0800

> normative content of that section.

In the same sense, given how common flaunting of the maximum length is
(and for how long that has been going on,
well before 2008), it seems odd to keep promulgating that that's the
standard.  I'll bow to John's knowledge of these procedures,
though... I guess sometimes the standard has to say one thing even if
most systems ignore it... so instead of a more realistic
length that we can move to, we get random interop issues... and keep
having to tell folks to disable overly pedantic SMTP firewalls.

The argument that no one is going to want to enter a 500 character
email address is certainly true... but I've also struggled to
understand how one expects folks to enter correctly escaped
local-parts anyways, or what parts of the UI should show
local-parts unescaped vs escaped.

Brandon

---

From: John C Klensin <[email-masked]>
Date: Mon, 25 Nov 2019 19:58:43 -0500

Brandon,

See Hector's note and, if you have the energy to read it, the
rather long one I'll post when I get through proofreading,
probably in the next hour or two.

However, as I read RFC 2026, _any_ substantive change from the
Draft Standard 5321 that has not gone through Proposed Standard
in a separate document first takes the 5321bis document.
AFAICT, there is no exception there that allows introducing a
substantive change that would cause some existing conforming
implementations to become non-conforming and still have the
document move to Internet Standard, even if that change has been
widely implemented by large email providers.

   john

--On Monday, November 25, 2019 13:10 -0800 Brandon Long
<[email-masked]> wrote:

>> > [... guidelines for extension publishing omitted ...]
>> > because there is about zero chance that anything would be
>> > included in a 5321bis that would force it back to Proposed
>> > Standard.
>> 
>> 
>> Yet, I think something will have to be said about the now
>> common habit of From: rewriting.  Section 3.9, Mailing Lists
>> and Aliases, still considers only rewriting of the envelope
>> from.  Reality now differs.
>> 
>> I don't think such changes would imply going back to PS,
>> given the loosely normative content of that section.
> 
> In the same sense, given how common flaunting of the maximum
> length is (and for how long that has been going on,
> well before 2008), it seems odd to keep promulgating that
> that's the standard.  I'll bow to John's knowledge of these
> procedures, though... I guess sometimes the standard has to
> say one thing even if most systems ignore it... so instead of
> a more realistic length that we can move to, we get random
> interop issues... and keep having to tell folks to disable
> overly pedantic SMTP firewalls.
> 
> The argument that no one is going to want to enter a 500
> character email address is certainly true... but I've also
> struggled to understand how one expects folks to enter
> correctly escaped local-parts anyways, or what parts of the UI
> should show local-parts unescaped vs escaped.
> 
> Brandon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 26 Nov 2019 14:43:39 +0100

> widely implemented by large email providers.

Hmm.

But doesn't a document also require implementations? I admit I may not have 
paid attention to that part of the lesson, but I vaguely remember a field 
on the shepherding document that said "list conformant implementations 
here", or words to that effect.

The current limits of the localpart (character set, case sensitivity and 
length) seem a little lacking in implementations, compared to other parts 
of the document. So it might be both permissible and sensible to have the 
next document give a brief overview of current practice, note that some 
receivers do enforce <description blah bla description> and suggest rather 
than specify that senders stay within these limits.

Arnt