Re: [ietf-smtp] parsing SMTP replies

Ned Freed <ned.freed@mrochek.com> Thu, 18 March 2021 22:04 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 084983A0B1F for <ietf-smtp@ietfa.amsl.com>; Thu, 18 Mar 2021 15:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.1
X-Spam-Level:
X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, 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 ewLhzLsLHAUz for <ietf-smtp@ietfa.amsl.com>; Thu, 18 Mar 2021 15:04:14 -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 4DDD83A0B1C for <ietf-smtp@ietf.org>; Thu, 18 Mar 2021 15:04:14 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWTFWHKBQ800BP69@mauve.mrochek.com> for ietf-smtp@ietf.org; Thu, 18 Mar 2021 14:59:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1616104749; bh=PRvnSVTOoL1pOjtpDFf1qAWYF0oVzFT1p5EKe6jzybc=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=kp8XcuW6fKp1dX7iDvHyhqSDTIxy+c9z/LNkxyo1xPFHRP6iuBG39QZD7EJI6664r 1D5CxxhYQsKi6bpn3YM9B5A6C+mooP5Yyzf0ayK+Zb4Kta4YtAylUBenCDgo+M2xUI 6sPF9r4mQhr9cRC+UubRH2WdFoYeMrExVWrYYImk=
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWJORF3ZF4005PTU@mauve.mrochek.com>; Thu, 18 Mar 2021 14:59:07 -0700 (PDT)
Cc: ietf-smtp@ietf.org
Message-id: <01RWTFWG4LQ6005PTU@mauve.mrochek.com>
Date: Thu, 18 Mar 2021 14:58:38 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 18 Mar 2021 07:18:21 -0400" <812d0945-d636-872c-5beb-52606f949943@network-heretics.com>
References: <CF0247A810AF9482CBB155E8@PSB> <01RWP85B98S4005PTU@mauve.mrochek.com> <20210316061139.GA26514@kiel.esmtp.org> <0d5912b5-6aba-728b-00de-a75397ad8ad8@tana.it> <01RWRTQUWB8Q005PTU@mauve.mrochek.com> <4EC92B6CFDD4220E0F692CF0@PSB> <cone.1616031446.909688.90196.1004@monster.email-scan.com> <7d448367-d5a0-7baf-3df4-dcafe1859437@network-heretics.com> <1B7BC0D7-5D34-4688-9D8A-BEA925D0ACCD@dukhovni.org> <812d0945-d636-872c-5beb-52606f949943@network-heretics.com>
To: Keith Moore <moore@network-heretics.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/SN3PPs-YoDje7Mb3nfAIapu5A24>
Subject: Re: [ietf-smtp] parsing SMTP replies
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: Thu, 18 Mar 2021 22:04:16 -0000

> On 3/17/21 10:54 PM, Viktor Dukhovni wrote:

> >> On Mar 17, 2021, at 10:39 PM, Keith Moore <moore@network-heretics.com> wrote:
> >>
> >> It's been a long time but I'm pretty sure I've seen situations in which it made sense for the recipient limit to be 1.   For example: a special-purpose device (e.g. email to fax, email to printer) or a gateway to a dissimilar mail system, or anything for which it makes sense to insist that per-recipient errors get immediately reported to the client.
> > That's really the realm of LMTP, final delivery, not relaying.

> No, it's not.   I didn't say anything about this being used for final
> delivery.   The point is that there are legitimately SMTP servers that
> potentially accept traffic from the public Internet, that aren't
> full-blown MTAs.

All true, but nothing prevents this extension from being used with LMTP.
I will adjust the document accordingly.

				Ned