--On Tuesday, September 26, 2023 15:36 -0700 Linda Dunbar via Datatracker <noreply@xxxxxxxx> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
