Re: [ietf-smtp] parsing SMTP replies (was: Proposed ESMTP keyword RCPTLIMIT}

[John C Klensin <[e-mail]>]

--On Wednesday, March 17, 2021 21:37 -0400 Sam Varshavchik
<[e-mail]> wrote:

> John C Klensin writes:
> 
>> Personally and wearing no hats, I like the idea of a new
>> "LIMITS" extension and EHLO keyword.   However, I think we
>> could
> 
> This reminded me of something that I wanted to mention. In
> whichever form the eventual specification of recipient limits
> takes place: I believe that the specification should set a
> minimum recipient limit. In other words: the minimum number of
> recipients that can be advertised.
> 
> I believe that the generally good track record of historical
> interoperability of SMTP implementations goes back to what's
> in section 4.5.3 of RFC 821, that gives the minimal limits of
> various things, like line lengths. And, incidentally, the
> minimum number of recipients that an SMTP server should accept
> is 100 recipients.
> 
> I don't remember if this was discussed, but this should be
> called out in any eventual recipient limit specification: the
> minimum value is 100, as per 2821 and 821.

Sam,

In principle, I agree with you.  There are two practical
problems and I don't know quite what to do about either.   

First, given the handwaving that I've called "operational
necessity" (and there will be more about the need to address
that in draft-ietf-emailcore-rfc5321bis-03) 5321 already allows
implementations and operators to pick a smaller number.  So,
strictly speaking, if a server returns 250 replies to the first
dozen recipients and then returns 452 for every RCPT command it
gets until the client either sends DATA (or equivalent) or gives
up (presumably with QUIT or RSET), it is conformant to 5321 even
if you, I, and (I hope) many others have to hold our noses while
saying that.  

In part because of that and given comments from others on this
and the emailcore list, if the specification for RCPTLIMIT says
"you MUST NOT provide a number smaller than 100", I'd expect an
implementation or configuration that intends to impose a smaller
limit would either just not advertise the parameter (or LIMITS
itself) or would ignore that requirement and put in a number it
considers appropriate.  Those are "lose either way" options, at
least AFAICT.

Again, I agree about the interoperability aspects of this.  If
nothing else and regardless of what we call it, I think we are
headed down the path in which practical interoperability
depends, not on the standard(s) but on implementations and
configurations selecting compatible profiles of features and
options -- precisely what many people associated with the
ARPANET and early Internet were complaining about in various ITU
protocols when 821 was new and explaining as one of the
important reasons why X.400 was failing or had failed already a
decade later.  Awareness of that problem was at least one of the
reasons for the 1425/5321 text I cited earlier.  But I don't
think the LIMITS extension makes things worse, only more
explicit, and I have no idea how to turn back the tide.

best,
   john