--On Monday, March 15, 2021 08:58 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> 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.
Assuming this is the sort
of announcement you and Dave have in mind, suppose the client
sends
MAIL FROM:<foo(_at_)example(_dot_)com>
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
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.
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.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp