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

[Ned Freed <[e-mail]>]

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

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

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

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.

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.

> >> In addition, if the answer were "yes", what would prevent a
> >> connection-opening response of
> >>   220 SNAFU SMTP Server, v 666, no more than 25 recipients
> >>   allowed
> >
> >> which is no less an announcement and of course avoids having
> >> to wait for any commands to be issued, even EHLO.
 
> > You can't repeat the announcement so you need the ability to
> > include the response in EHLO, which is the obvious way to
> > revise the limits after AUTH or STARTTLS. And EHLO is required
> > in all three cases, so aside from not being soonest in one
> > case there's no downside I can see.

> Good reason, but I think I wasn't clear about the point I was
> trying to make, which was not about the design --with which I'm
> quite happy-- but with Dave's specific paragraph which, in its
> form as above, I think could add to the confusion.  Why?
> Because, as soon as you say "SMTP servers have always been able
> to announce a limit, in a reply...", it seems to me the
> immediate question is

> 	'Sure, they can "announce" whatever they like, but how
> 	would that work in practice? If, for example, the client
> 	sends a MAIL comment and gets back "250..." or even
> 	"2...", and moves on to the next command because _any_
> 	2yz response to the MAIL commend implies "ok, move on to
> 	the next command"'.

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

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

> To push that explanation a bit further, we could, in principle,
> define an extension of, e.g.,

>  MANDATORYEXTENDEDCODES
> or
>  YOUBETTERREADREPLYTEXT

> in such a way that the server would advertise it and, if the
> client did not include some sort of confirmation as part of the
> MAIL command or whatever command followed the EHLO response, the
> server might find it perfectly reasonable to respond

>   55z Then I don't want to talk with you, go away
>    (554 would be close, but not exact)

> IMO, that would be a fairly dumb idea, but those are the only
> way I can think of to make an "announcement" as part of a reply
> reliable.  That ultimately just demonstrates another reason why
> your proposal is a better idea, but also shows, IMO, how
> slippery the slope gets if you start discussing alternate
> strategies... and brings me back to the line you describe above
> and about which, again, I agree.

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

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.

				Ned