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

Ned Freed <ned.freed@mrochek.com> Mon, 15 March 2021 21:38 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E8D3A0FD1 for <ietf-smtp@ietfa.amsl.com>; Mon, 15 Mar 2021 14:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYdAi9JLDxFA for <ietf-smtp@ietfa.amsl.com>; Mon, 15 Mar 2021 14:38:28 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA8C3A0FCE for <ietf-smtp@ietf.org>; Mon, 15 Mar 2021 14:38:28 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWP85DF5U800FYBT@mauve.mrochek.com> for ietf-smtp@ietf.org; Mon, 15 Mar 2021 14:33:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1615843999; bh=pw2z0Xg1CNeuI9kpq2l9QXMwvnrUa6JT3rE1A7utMrI=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=o2YR7VjB4mqgJphdr2HP1RsqyoYq/KFX6+D3iWFDcdkI5pFIvmHgFRsgL42AsgnHI j7t+i6cqM8XwyIq10bzdzTLiEPwrTjbqxfILWYMmvW7svU4iH8dFdAhrZnmUACYLXq 10ZHrZh4p1uMJ0UByppERO3nVxeKS9VgiDwHXD2c=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWJORF3ZF4005PTU@mauve.mrochek.com>; Mon, 15 Mar 2021 14:33:16 -0700 (PDT)
Cc: Ned Freed <ned.freed@mrochek.com>, Dave Crocker <dhc@dcrocker.net>, ietf-smtp@ietf.org
Message-id: <01RWP85B98S4005PTU@mauve.mrochek.com>
Date: Mon, 15 Mar 2021 14:26:51 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 15 Mar 2021 16:28:36 -0400" <CF0247A810AF9482CBB155E8@PSB>
References: <77B21231-47EA-4CA6-A665-5880B6A54D4D@wordtothewise.com> <20210312203224.F3739701E4C5@ary.qy> <01RWOUM3HK0Q005PTU@mauve.mrochek.com> <e6e5d166-ded5-b6c0-db9a-57c44e8bd92a@dcrocker.net> <01RWOX4A2CZG005PTU@mauve.mrochek.com> <CF0247A810AF9482CBB155E8@PSB>
To: John C Klensin <john-ietf@jck.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/guEcLCDN9VmtXB5XtIKm_LPocp0>
Subject: Re: [ietf-smtp] [Emailcore] Proposed ESMTP keyword RCPTLIMIT
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Mar 2021 21:38:29 -0000


> --On Monday, March 15, 2021 08:58 -0700 Ned Freed
> <ned.freed@mrochek.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@example.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