Re: [Last-Call] Opsdir last call review of draft-freed-smtp-limits-06

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

--On Tuesday, September 26, 2023 15:36 -0700 Linda Dunbar via
Datatracker <[e-mail]> wrote:

> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I have reviewed this document as part of the Ops area
> directorate's ongoing effort to review all IETF documents
> being processed by the IESG.  These comments were written
> primarily for the benefit of the Ops area directors. Document
> editors and WG chairs should treat these comments just like
> any other last-call comments.
> 
> Summary:
> This document defines a "Limits" extension for the Simple Mail
> Transfer Protocol (SMTP).
> 
> The document specifies several limits to be registered with
> IANA. However, I don't see the Limit value being specified.
> Does it mean that the document simply proposes a new KEYWORD
> (LIMITS)?
> 
> I am not an expert at SMTP, I have some questions:
> - The security consideration says that "a malicious server can
> use limits to overly constrain clients". Q1: how to prevent
> clients access malicious server? Q2: how does setting the
> KEYWORD LIMIT can help this problem

There has been some discussion about that statement.  So far, we
haven't been able to do much better and, as thee document
explains, I'm very reluctant to alter Ned Freed's text except
when absolutely necessary.  So

Q1: Barring some sort of "good guy" or "bad guy" list maintained
by responsible parties (an option far outside the scope of
either SMTP or this spec), if an SMTP  client receives a message
for transmission from a user (or Submission Server or another
SMTP system) containing and address whose associated DNS records
points toward a malicious server, there is no way to know, nor
is there any way to know that the server is malicious.

Q2: As that paragraph more or less says, evil/malicious SMTP
servers can misbehave and the rather complicated (IMO) misuse of
LIMITS can be one of many ways for them to do so.  Among parties
where both client and server has good intentions, LIMITS can be
used to avoid extra negotiation and turnarounds by having the
server tell the client what is acceptable.   In that regard, it
is a generalization  of the specific limit-setting of the SIZE
extension, which has been around since RFC 1497 in February 1993.

> - Introduction section 6th paragraph says "makes it possible
> for clients to avoid server errors and the problems they
> cause. Q: How can setting the LIMITE helps Client avoid Server
> Errors?

Let's use RCPTMAX (Section 4.2) as an example.  Suppose a server
is not willing to accept more than one RCPT command in a mail
transaction.  Without the LIMTIS extension, a typical client
wanting to send a message with, say, four recipients at the same
domain, would open a mail transaction and try to send four RCPT
commands, one for each recipient address, then the message body.
The server would presumably accept the first one, returning an
"ok" (2xy) code.  But, when it received the second, it would
reject it (with a 5yz code).   That would effectively be the end
of the mail transaction -- the client would need to send QUIT
(or possibly RSET). then start a new session or possibly a new
transaction with only a single RCPT command, using additional
transactions for each of the other three.   On the other hand,
if the server announced LIMITS RCPTMZX with a value of 1, the
client would know to break the transactions up without that
false start.

Of your questions, this was the one that probably would have
been most obvious to someone more familiar with SMTP but we all
do the best we can.  I hope the above explanation(s) help.

best,
   john