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

[Ned Freed <[e-mail]>]

> On Tue 13/Jul/2021 17:32:50 +0200 Dave Crocker wrote:
> > On 7/13/2021 5:52 AM, Ned Freed wrote:
> >> I also note that X.400 has changed from "the mail system we'll all be using
> >> someday" to "only used in limited government/military cases, and even those are
> >> disappearing". Is it really worth mentioning at this point?


> Where do those quotes come from?

They came from me. I'm paraphrasing what many people said back in the 80s when
X.400 was the new hotness and now when it's old and busted.

It's hard to believe now, but at the time the expectation really was that a
mostly government-run email service based on a universal directory was the
future.

> Do you have a reference?  When did the change occur?

These sorts of transitions rarely involve an abrupt change, but as it happens,
in the case of X.400 I did have an "aha" moment. It was back in the early 90s
at the Electronic Mail Association's Message Attachment Working Group (MAWG)
meeting on profiling the File Transfer Body Part and aligning it with MIME. As
the EMA equivalent of the blue sheet started circulating, Nick Shelness stood
up and (more or less) said, "Please include your Internet address on the sheet,
most of the X.400 ones you've provided in the past don't work."

Since then I've wondered if Nick - among other things, the main author of
Softswitch - knew the significance of what he was saying. Knowing Nick, he
probably did.

> > It is not.


> +1,


> >> 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.


> You mean "should be used"?  ("should support" doesn't appear in that
> paragraph).

Correct.

> I'm not clear what is the security risk.  Clearly, no implementation can be
> truly limitless, since the Universe itself appears to be limited.  Perhaps:

>                                                             To the
>     maximum extent possible, implementation techniques that impose no
>     *predefined* limits on the length of these objects should be used.

That's still a recipe for disaster because people won't know to set them
correctly. Anything without a reasonable limit can  be found by a hacker and
exploited to exhaust resources.

And if you don't believe this happens, I have a couple of very nice bridges to
sell you.

It also does nothing to enhance interoperability. Requiring the minimums but
encouraging everyone to implement more opens the door to implementators coding
stuff that assumes larger limits - because what they had in the lab suppported
more - but then fails badly when faced with a wider range of implementations on
the Internet.

IMO at this point interoperability trumps being able to get away with stuff 
sometimes.

				Ned