[ietf-smtp] Semantics of 554 greeting? (Clarify in 5321bis?)

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 17 December 2019 20:07 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 32CDB120077 for <ietf-smtp@ietfa.amsl.com>; Tue, 17 Dec 2019 12:07:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 towZgNyUtgEJ for <ietf-smtp@ietfa.amsl.com>; Tue, 17 Dec 2019 12:07:23 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FD4120048 for <ietf-smtp@ietf.org>; Tue, 17 Dec 2019 12:07:23 -0800 (PST)
Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id C2D2F54788 for <ietf-smtp@ietf.org>; Tue, 17 Dec 2019 15:07:21 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <20191216054527.GF11489@straasha.imrryr.org>
Date: Tue, 17 Dec 2019 15:07:20 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: ietf-smtp@ietf.org
Message-Id: <E990D48B-E0BB-48B6-A584-A0BBBEA1F7EE@dukhovni.org>
References: <20191215222928.9DE5A1164C5A@ary.qy> <754203.1576450681@turing-police> <alpine.OSX.2.21.99999.374.1912151831300.63353@ary.qy> <18926580F5114CCCADABE398@PSB> <20191216054527.GF11489@straasha.imrryr.org>
To: ietf-smtp@ietf.org
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/NeHzVodzZX6kJFJ7lQhuP6gOpWA>
Subject: [ietf-smtp] Semantics of 554 greeting? (Clarify in 5321bis?)
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: Tue, 17 Dec 2019 20:07:27 -0000

When describing why Postfix defers most policy controls to "RCPT TO",
I wrote:

> On Dec 16, 2019, at 12:45 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> When an SMTP server returns 5XX in either the greeting or in response to
> EHLO, some clients treat that as a connection setup failure, not a
> permanent message delivery failure, and move on to the next MX host, and
> perhaps ultimately defer and retry the message:
> 
>    smtp_skip_5xx_greeting (default: yes)
> 
>        Skip remote SMTP servers that greet with a 5XX status code.
> 
>        By default, the Postfix SMTP client moves on the next mail
>        exchanger. Specify "smtp_skip_5xx_greeting = no" if Postfix
>        should bounce the mail immediately.
> 
> The reason for that was that at least at the time, various Microsoft
> SMTP servers woul return 5XX greetings under transient high load.
> Consequently, Postfix itself is one of the clients that treats
> 5XX as temporary failures in greetings (though not in EHLO).

Which brings me to the question of this new thread, what is the
meaning of a 554 greeting with respect to the sender's envelope?

* Is a 554 greeting semantically equivalent to TCP RST?  With the
  client moving on to the next MX host or deferring the message?

* Or, is the client expected to conclude that the recipient domain
  does not accept email and bounce all the envelope recipients?

The text is unclear.  Postfix assumes the former, and perhaps that's
actually the intent of the RFC?  Rereading this text recently, I am
not sure what it means.

-- 
	Viktor.