Subject: [ietf-smtp] A note on the maximum length restrictions of RFC 5321

From: John C Klensin <[email-masked]>
Date: Tue, 26 Nov 2019 14:07:29 -0500

Hi.

In the process of writing a note to myself to be sure this issue
didn't get lost if and when we address a revision to RFC 5321, I
actually looked at the relevant text.  I would encourage
everyone following the discussion of maximum lengths of mailbox
fields, and especially those who have contributed to it, to
carefully reread the introductory paragraphs of Section 4.5.3.1
of RFC 5321.  FWIW, a first paragraph that is (at least) very
similar appears in RFC 2821, so the rigid requirement on
local-part length (or on lengths connected to it) has been gone
for more than 18 years.

Now, if we open 5321 for a revision, we can and should discuss
whether the  numbers in the subsequent subsections should be
changed and/or whether those paragraphs in 4.5.3.1 could be
improved (and how), but I think this demonstrates several things:

(1) None of us, especially including me, should make assumptions
or rely on memory about what RFC 5321 (or, probably, any other
long and complex standards-track document) says, and then
propose changes to it, without taking the time to go back and
carefully read that specification.

(2) To at least some extent the fact that several people with a
great deal of email experience obviously did make such
assumptions without checking the text reinforces my concern
about getting adequate review for any significant revision to
RFC 5321 (or, for that matter, 5322).

(3) Viruthagiri is off the hook here because he is relatively
new, but, when we propose to make changes to a standard, we
should be sure we are looking at the right document, not an old
informational summary of part of it, especially one based on
earlier specifications.

(4) Finding that text does not necessarily change the need for
an SMTP extension in this area.   Just as SMTPUTF8 was needed to
be sure that an SMTP server could accept addresses (and other
material) containing non-ASCII characters (and the work on it
exposed a large number of issues that an MTA that was "eight bit
clear" would not need to make handling such addresses trivial),
it might be perfectly reasonable to ask a server if it accepts
longer mailbox names.  For the record, I'm not arguing for or
against draft-viruthagiri-email-address-length-00 or its future
revisions, just that discovery of the text cited above does not
make it irrelevant.

(5) If anyone wants to make the case that enough people are
paying attention to RFC 3696 to justify working on it, that it
is enough out of touch with the times that it should be revised,
_and_ who wants to volunteer to be co-author, probably lead
co-author, on a revision, let me know.  Of course, a careful
reading of 5321 and 5322 is prerequisite to any effort to start
such a revision.

Your friendly harried editor of a document he has never really
liked,
  john