Re: [Emailcore] Retrying delivery on post-DATA permanent error status

John C Klensin <john-ietf@jck.com> Tue, 26 July 2022 05:15 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: emailcore@ietfa.amsl.com
Delivered-To: emailcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C87C16ECCB; Mon, 25 Jul 2022 22:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iu0NzrlMy-P; Mon, 25 Jul 2022 22:15:50 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2164DC16ECD3; Mon, 25 Jul 2022 22:15:46 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1oGCv3-000HLh-Dd; Tue, 26 Jul 2022 01:15:45 -0400
Date: Tue, 26 Jul 2022 01:15:39 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Luis E. Muñoz" <emailcore=40lem.click@dmarc.ietf.org>, emailcore@ietf.org
Message-ID: <B9BCF54B326B272B85C20D8B@PSB>
In-Reply-To: <C4B67480-45E0-4E08-93A3-05019D963B38@lem.click>
References: <C4B67480-45E0-4E08-93A3-05019D963B38@lem.click>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/_1LGDM911UqbTQ6gcDwfs927PZk>
Subject: Re: [Emailcore] Retrying delivery on post-DATA permanent error status
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emailcore>, <mailto:emailcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore/>
List-Post: <mailto:emailcore@ietf.org>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emailcore>, <mailto:emailcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2022 05:15:53 -0000


--On Monday, July 25, 2022 16:52 -0400 "Luis E. Muñoz"
<emailcore=40lem.click@dmarc.ietf.org> wrote:

> 
> RFC-5321 has this to say regarding status codes returned
> post-DATA
> 
>    When an SMTP server returns a permanent error status (5yz)
> code after    the DATA command is completed with
> <CRLF>.<CRLF>, it MUST NOT make    any subsequent attempt to
> deliver the message.  As with temporary    error status codes,
> the SMTP client retains responsibility for the    message, but
> SHOULD not again attempt delivery to the same server
> without user review of the message and response and appropriate
>    intervention.
> 
> I do not understand the reasoning behind the "SHOULD not", as
> I believe it should rather be a "MUST NOT" to maintain
> consistency. What am I missing?

(Personal opinion, not as editor or anything else because I
don't remember the original discussion any more). 

The key part of that text is the last part of the sentence:
"without user review of the message and response and appropriate
intervention".  Now the question for you is "are you sure those
are all of the cases".  If, for example, for some messages, and
automated review would be satisfactory, do you think whatever
robotic process was involved would constitute "user review".  If
the answer to either of those questions is "no", then SHOULD is
appropriate and the question becomes whether there should be an
explanation in the text about those other possible cases.  (Now
slipping my editor hat back on, for this case, I hope not.)

best,
   john