Re: [Emailcore] Ticket #14: G.7.8. Review different size limits

[Ned Freed <[e-mail]>]

> Greetings.

> I would like to start a discussion about ticket #14 -
> https://trac.ietf.org/trac/emailcore/ticket/14

> Section 4.5.3.1 of draft-ietf-emailcore-rfc5321bis reads:

> 4.5.3.1.  Size Limits and Minimums

>    There are several objects that have required minimum/maximum sizes.
>    Every implementation MUST be able to receive objects of at least
>    these sizes.  Objects larger than these sizes SHOULD be avoided when
>    possible.  However, some Internet mail constructs such as encoded
>    X.400 addresses (RFC 2156 [26]) will often require larger objects.
>    Clients MAY attempt to transmit these, but MUST be prepared for a
>    server to reject them if they cannot be handled by it.  To the
>    maximum extent possible, implementation techniques that impose no
>    limits on the length of these objects should be used.
>    Extensions to SMTP may involve the use of characters that occupy more
>    than a single octet each.  This section therefore specifies lengths
>    in octets where absolute lengths, rather than character counts, are
>    intended.


> and ticket 14 asks the question:

> Given the controversy on the SMTP mailing list between 20191123 and now
> about maximum lengths, is the above adequate or is further tuning of the
> limit text below needed?

The text, especially the part about X.400, is seriously dated at this point.
(For those of you who have never dealt with X.400, X.400 addresses consist of a
list of attributes and values, including but not limited to attributes for
postal address information, and theoretically can be thousands of octets in
length. The 1:1 mapping of this defined by RFC 2156 puts most of this in the
local part in /attr1=/value1/attr2=value2/... form.)

As a practical matter real world X.400 gateways never required longer lengths
on the SMTP/RFC822 side, for the simple reason that they never worked well
enough. (It didn't stop compliance suites from coding tests that required
them...) A combination of restraint on the part of X.400 implementations and
very complicated mappings were used to avoid the problem.

And if a client has a fallback, as the text requires, why not just use it
rather than sending something that may work locally but fail downstream,
where no fallback is possible?

I also note that X.400 has changed from "the mail system we'll all be using
somday" to "only used in limited government/military cases, and even those are
disappearing". Is it really worth mentioning at this point?

Finally, and most importantly, implementation techniques that impose no limits
on object size represent a serious security risk. I think this alone justifies
removing "should support" bit.

> draft-ietf-emailcore-rfc5321bis then goes on to specify length limits in
> octets, not characters, in each of the following sections:

> 4.5.3.1.1. Local-part
> 4.5.3.1.2. Domain
> 4.5.3.1.3. Path
> 4.5.3.1.4. Command Line
> 4.5.3.1.5. Reply Line
> 4.5.3.1.6. Text Line
> 4.5.3.1.7. Message Content
> 4.5.3.1.8. Recipient Buffer

Like it or not, the limits in existing implementations are octet, not
character, based. A change to make them character-based is therefore
wholly nonsensical.

				Ned

> Thoughts?

> --

> *Todd Herr* | Technical Director, Standards and Ecosystem
> *e:* [e-mail]
> *m:* 703.220.4153

> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.