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

[Alessandro Vesely <[e-mail]>]

On Tue 13/Jul/2021 20:16:35 +0200 Ned Freed wrote:
>> 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.


Thanks for sharing!
(https://en.wikipedia.org/wiki/X.400#cite_note-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.
>> [...]
>> 
>> 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.


That's a general safety rule, not an SMTP-specific provision.  Yet, the 
consideration meant by the sentence could be retained.  How about:

                          Up to the point where resource exhaustion
      would be at stake, implementation techniques that impose no
      predefined limits on the length of these objects should be used.


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


Agreed.  However, removing the sentence conveys a much stronger meaning to the 
size limits given in the spec.  It depends on whether we consider them to be 
hard limits or just reasonable indications given at the time when the spec is 
being published.  Just like X.400 fades out, some trend requiring more space 
might fade in in the future.

Consider the line length limit John mentioned.

Consider the overall message length limit, which the spec does not give, but 
whose range seems to be more or less agreed upon among the vast majority of 
servers.

RCPTLIMIT could impose local hard limits in a more flexible way.


Best
Ale
--