Re: [ietf-smtp] [Emailcore] Proposed ESMTP keyword RCPTLIMIT

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

--On Tuesday, March 16, 2021 07:27 -0700 Ned Freed
<[e-mail]> wrote:

>> --On Monday, March 15, 2021 14:26 -0700 Ned Freed
>> <[e-mail]> wrote:
>  
>> >> --On Monday, March 15, 2021 08:58 -0700 Ned Freed
>> >> <[e-mail]> wrote:
>> > 
>> >> >>       SMTP servers have always been able to announce a
>> >> >>       limit, in a reply, which means that the client
>> >> >>       first needed to issue a command.  The mechanism
>> >> >>       specified here avoids the overhead of that
>> >> >> interactions, by announcing limits prior to any
>> >> >> substantive interaction.
>> >> > 
>> >> > Nice. Added.
>> > 
>> >> I wonder.  Along with the "first digit" rule, SMTP has been
>> >> fairly clear that SMTP clients should not depend on trying
>> >> to parse or interpret reply text except for VRFY and EXPN
>> >> for which syntax is actually given for replies.
>> > 
>> > Which establishes the precedent for parsing replies given a
>> > signal to do so.
> 
>> Except that I thought (although I can't find it right now)
>> that 5321 called  that out as an explicit exception.
> 
> Even if it did, unless it also said "no subsequent standard
> can create similar exceptions", I don't see why it would
> matter. RFC 2034 created the the exception for including
> enhanced status code on top of RFC 821. And  it's been pointed
> out that there's a draft that would create another exception.

No problem as long as we are clear about what we are doing.
And, if the exceptions _require_ enhanced status codes, I have
no concern at all.

>> Certainly they
>> and the forwarding and "try instead" replies are the only ones
>> for which an exact syntax is discussed.    But I think the key
>> phrase above is "signal to do so", with which I agree.  See
>> below.
> 
> Enhanced status codes provide a pretty powerful signalling
> mechanism.

Agreed.  See above.
 
>> >> Assuming this is the sort
>> >> of announcement you and Dave have in mind, suppose the
>> >> client sends
>> >>    MAIL FROM:<[e-mail]>
>> >> and the server responds
>> >>    250 OK.  No more than 20 recipients
>> >> would we seriously expect the client to interpret and use
>> >> that information?
>> > 
>> > Of course not, but how about:
>> > 
>> > 250 2.5.314159 RCPTMAX=n
> 
>> And that gets into a bit of tension between the "first digit"
>> rule in 5321 and extended codes, perhaps particularly in the
>> case of MAIL, where the fourth paragraph of Section 3.3 ("This
>> command tells...") says, apparently very specifically 'If
>> accepted, the SMTP server returns a "250 OK" reply", not "250
>> <whatever it feels like> which the client is expected to read
>> and understand".  But if that needs to be addressed at all, it
>> should be addressed in 5321bis, not in your draft... as long
>> as the draft does not increase the confusion.  See below.

> I'm afraid that's actually a bug in RFC 5321, irrespective of
> what emerges from this discussion: It's a bug because any
> server supporting the ENHANCEDSTATUSCODES extension isn't
> going to send that response. And that includes a *lot* of
> servers.

Understood.  However, there appears to be no requirement in RFC
3463 or anywhere else, including RFC 2034, that a server
advertise ENHANCEDSTATUSCODES before sending them.  3463 (and
1893) seem to imply that such codes can simply be added at the
server's discretion and, fwiw, 3463 does not even reference 2034.

While I think the language about the three-digit code structure
needs work (see prior note to Alessandr on the ietf-smtp list
today), I'm not sure how to address the bug you see in 5321bis
without getting into the "scope" territory that has been under
discussion in conjunction with verification of return paths and
removing the SPF and DKIM references.   Perhaps the right
solution would be to put a section into the A/S discussing
extended codes and, in the process, strongly recommending that
servers that intend to send such codes advertise the extension.
Other suggestions welcome.

> As for the "first digit" rule being in tension, I don't think
> it is. The first digit rule doesn't say "never ever attach
> semantics to the rest of the reply". Rather, it's about the
> immediate effect of a reply on the SMTP client's behavior not
> being based on anything more than the first digit.

Right.  See above about trying to clarify that.

> The obvious example of deep analysis of SMTP replies is
> mailing list managers, which have to decide whether or not a
> failure should cause the address to be removed from the list.
> This "hard" or "soft" bounce determination can be quite
> sophisticated - take a look at Sisimai sometime.

Ack.
 
>...
>> The server could equally respond to a MAIL command with "250
>> Is it not a lovely day?".  That would constitute an
>> announcement of sorts, but the expectation that it would be
>> acted on would be the same: in the absence of some spec that
>> goes beyond 5321, both are really comments, not
>> announcements.   Now, if the paragraph had said, e.g.,
>> "...limit, in a reply with an enhanced status code,..." I
>> probably would not have batted an eyelash because, at that
>> point, it would be clear that the server was asking the
>> client to do something different than "get as far as 250 and
>> then move on".    But...
>  
> I think this can be addressed by making it clear that a special
> syntax would have had to have been defined.

Yes.  That would work.  Does that text need to be in 5321bis?
Perhaps as part of clarifying the first digit rule and code
structure?

>> > I guess I could write all these reasons down, but at some
>> > point text about design choices becomes a hindrance to
>> > understanding the acutal protocol. I think all this cross
>> > that line, whereas Dave's text did not.
> 
>> We are in complete agreement with your first sentence.  All
>> I've suggesting is that, absent some additional words, Dave's
>> text could add confusion and become a hindrance.   I am
>> agnostic as to whether it would be better to add the words
>> (few of them and perhaps using the example above) or to drop
>> the text.  The key design choice, IMO, is to have a facility
>> for announcing these limits that is precisely defined (which
>> you have, IMO, done) and that a client that is aware of and
>> interested in that particular extension keyword will know,
>> rather exactly, now to interpret it.  That is what the
>> extension mechanism is all about.
>...
> The way RFC 2034 made the appearance of ENHANCEDSTATUSCODES
> reliable was to announce it in EHLO. There was a
> counterproposal at the time, from Dan Bernstein, to just
> "sprinkle the codes in replies using a # prefix", but we went
> with the EHLO announcement approach. Which admittedly does
> make this a bit circular...

Right.   And, again, there is no requirement that the extension
be advertised in order to use the codes.  If a server returns an
extended code for anything but a three-digit code with an
established syntax [1], a client that responded by dumping the
message back on wherever it got it from because it had no idea
what those digits were doing there would be in clear violation
of the intent, and probably the letter, of 5321.

 
> Even so, it seems to me that calls to explain design choices
> over and over are on the rise. This seems to me like one where
> a little text helps more than it hurts.

Agreed.

   john

[1] That may point to another twitch (or bug) or two in 5321.
Suppose we have a command for which a normal reply has a
specific syntax identified in 5321.  Is a server that stuffs an
enhanced reply code after the normal reply code but before the
specified text in conformance?  Good sense and RFCs 2034 and
3463 certainly suggest a "yes" answer, but that doesn't seem to
be the answer in 5321.  That is further complicated by 5321
apparently not containing any ABNF for those defined/structured
responses.   See, for example, the way in which the VRFY
response is defined in Section 3.5.1.   Anyone who sees these as
issues should request that tickets be opened.  ... And think
about the scope issue mentioned above.