Re: [ietf-smtp] parsing SMTP replies (was: Proposed ESMTP keyword RCPTLIMIT}

Ned Freed <ned.freed@mrochek.com> Fri, 19 March 2021 14:55 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 CABD53A1746 for <ietf-smtp@ietfa.amsl.com>; Fri, 19 Mar 2021 07:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 jQVkGFqmH1no for <ietf-smtp@ietfa.amsl.com>; Fri, 19 Mar 2021 07:55:19 -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 68D193A1748 for <ietf-smtp@ietf.org>; Fri, 19 Mar 2021 07:55:19 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWUF81NJ8W00BPRL@mauve.mrochek.com> for ietf-smtp@ietf.org; Fri, 19 Mar 2021 07:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1616165415; bh=06bfTuno9igQmsamK77RdCk/+UQfRlRN2ksX0aVgiFA=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=S1V0ZpY58URl+7jLVmLsruBi76TbG0G+l04YOG3HDk0kyhre5XknGSyVbUSJMVgnG QNJAAnn04jQdiNq+nR6I1nfM4e3q6cgdt46Y65w+3hkl64glABWbkeCP77X+WZNzfe h2HEmrgt7JmbDyqvNGTGj3bFE7fLnITNIS2ml4tw=
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=utf-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWJORF3ZF4005PTU@mauve.mrochek.com>; Fri, 19 Mar 2021 07:50:12 -0700 (PDT)
Cc: Alessandro Vesely <vesely@tana.it>, Ned Freed <ned.freed@mrochek.com>, ietf-smtp@ietf.org
Message-id: <01RWUF7ZFI5S005PTU@mauve.mrochek.com>
Date: Fri, 19 Mar 2021 07:43:37 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 18 Mar 2021 09:58:39 -0400" <0BEE6B0072CA657CBBD724E8@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> <01RWP85B98S4005PTU@mauve.mrochek.com> <20210316061139.GA26514@kiel.esmtp.org> <0d5912b5-6aba-728b-00de-a75397ad8ad8@tana.it> <01RWRTQUWB8Q005PTU@mauve.mrochek.com> <23c8a0fb-408e-3756-83bf-233c7e40197a@tana.it> <0BEE6B0072CA657CBBD724E8@PSB>
To: John C Klensin <john-ietf@jck.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/rrltIHYqtRoYybA7QEWUnraBDWo>
Subject: Re: [ietf-smtp] parsing SMTP replies (was: 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: Fri, 19 Mar 2021 14:55:21 -0000


> --On Thursday, March 18, 2021 11:37 +0100 Alessandro Vesely
> <vesely@tana.it> wrote:

> >...
> >> That said, I don't see why this limit necessarily has
> >> anything to do  with greylisting. It's about how to long to
> >> wait before retying after a transient failure, irrespective
> >> of why the delay occurred. If could be greylisting, it could
> >> be exceeding a rate or connection limit, it could be one of
> >> the sources for validating recipients is down, it could be
> >> the spam filtering system is down, etc. RETRYDELAY would be a
> >> much better name for it.

> > Good point.  By observing RCPTLIMIT, a client can avoid
> > re-queuing delays.  It stops just before reaching the limit
> > and then starts a new transaction right away.  However, this
> > won't work if 452 was issued to split recipients according to
> > a different criterion than the local max number.

> "Avoid" and "stops"?  Only maybe.  If some variation on
> greylisting is applied because the server doesn't approve of,
> e.g., the IP address of the sender or the combination of the
> reverse-path and one or more of the recipients, a published
> maximum on the number of RCPT commands doesn't have anything to
> do with it.   And, for a variety of reasons, that might result
> in a 4yz code after DATA, not anything but 250 codes after the
> RCTP commands.

Nothing prevents a server from advertising a limit at the
beginning of session based on the sender's reputation at that
point.

And yes, nothing prevents a limit from subsequently being adjusted during the
session, based on whatever, so that the originally advertised limit no longer
applies. This happens all the time with the SIZE extension on limited-resource
servers; it doesn't mean that SIZE isn't useful.

> I see this feature as useful, but we should not over-sell it,
> even to each other.

Agreed. There's already a paragraph in the document saying that it doesn't
attempt to deal with in-session limit changes. I think that's sufficient.

				Ned