Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452?

Jeremy Harris <jgh@wizmail.org> Fri, 12 March 2021 15:33 UTC

Return-Path: <jgh@wizmail.org>
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 53DE73A1321 for <emailcore@ietfa.amsl.com>; Fri, 12 Mar 2021 07:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=71Y2Xk9V; dkim=pass (2048-bit key) header.d=wizmail.org header.b=iHvkA/2m
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 5mIsbBYJVZXa for <emailcore@ietfa.amsl.com>; Fri, 12 Mar 2021 07:33:16 -0800 (PST)
Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 3984E3A1327 for <emailcore@ietf.org>; Fri, 12 Mar 2021 07:33:15 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:To:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=C5RW9ptPyQEvxkCJtfcbSWkXpE+pTuaf1Bfnf4hDE0k=; b=71Y2Xk9VPmd0vFDv5yq3egcfrl YmZSFJ/4YxMQgW1zeK1VUqQ20SG6tVG3fJGLWMYBGFx0+brwkNbVBGOR7kDQ==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:To:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=C5RW9ptPyQEvxkCJtfcbSWkXpE+pTuaf1Bfnf4hDE0k=; b=iHvkA/2mIWuUbFHQQqRvOq/8dR 8jfQadgkxWkp+bekAmfaS1UsymFn9S30FNWxIgJSPA5mWgg+j9HjJ9JN6NJJUggo0vsni0Y6YfF8V wVK/mR3aDBUU/WsM9U3bSu/JLziq9x8wPnIacH8uBczBV36KuSijj3SOTaybs1c9LqQ9EMDehPqIE lWDuvEMi59mj7OJlcjPlIpfzGUS1F9BJDwQE1a2KUCwJR10PF58b+BRZjpng+N7TG0vnjsrKe3JOI dVdWlSl44YIlenCZ60mYjozXPpVymbPvFcFwkbSg9+aa75nR4rJ+6OdBLsPjRb5bw/UZ4YhfBanYD qpm89kyg==;
Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org
Received: from [46.33.133.68] (helo=lap.dom.ain) (from_AS 51561) by wizmail.org (Exim 4.94.116) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1lKjmq-002OG9-CU for emailcore@ietf.org (return-path <jgh@wizmail.org>); Fri, 12 Mar 2021 15:33:12 +0000
To: emailcore@ietf.org
References: <ca851fda-63ac-8739-c3eb-bde725aa25f3@isode.com> <c188413b-9337-40d8-8062-9c0f58f6cd98@www.fastmail.com> <CAHej_8kHwEOmq5bf49=Tt6ZEVkuidMhy5s4XPu7JC+k22qraZg@mail.gmail.com> <CAHej_8ma-kDkVh3Oj11R5Fn6BbwJsWfFpx0Zqv61fPL35CJNUA@mail.gmail.c om> <0F2370D0-D04C-45A1-A5A1-8FF1F174FFE5@dukhovni.org> <CAHej_8=deJU1CW2AzDBu5ji3Uir+_zF6Gp59Z-hHRmRipz8Osw@mail.gmail.com> <9A7BDB22F3A0396EF24BF91D@PSB> <397cc52c-5533-12a2-6ca2-e46f5987105c@wizmail.org> <F57F0BCCE67A6D1CE8BC3157@PSB>
From: Jeremy Harris <jgh@wizmail.org>
Message-ID: <47f870f5-494c-b8d4-b724-8fb2b2c545c9@wizmail.org>
Date: Fri, 12 Mar 2021 15:33:11 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <F57F0BCCE67A6D1CE8BC3157@PSB>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/bY-miyL4mX0k_aqFXlsEVS-z89U>
Subject: Re: [Emailcore] Ticket #5: G.5. Remove or deprecate the work-around from code 552 to 452?
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 12 Mar 2021 15:33:18 -0000

On 12/03/2021 01:13, John C Klensin wrote:
> 
> 
> --On Thursday, March 11, 2021 22:07 +0000 Jeremy Harris
> <jgh@wizmail.org> wrote:
> 
>> On 11/03/2021 21:18, John C Klensin wrote:
>>> If it
>>> is in need to changing, it would be to change the SHOULD to a
>>> MUST since that appears to be what everyone is doing anyway.
>>
>>
>> No, it is not.  Exim does not treat a received 5xx as a 4xx.

> I'm happy staying with MUST --up to the WG-- but would, on
> principle, like to understand what EXIM is doing and why.  In
> particular, a mail transaction, with EXIM as client, looks like:
> 
>    [...]
>    MAIL FROM:<foo@example.net>
>    250 ...
>    RCPT TO:<bar1@example.com>
>    250 ...
>    RCPT TO:<bar2@example.com>
>    250 ...
>    RCPT TO:<bar3@example.com>
>    250 ...
>    [...]
>    RCPT TO:<bar101@example.com>
>    552 ...
> 
> Now, upon getting that first 552, does EXIM
> 
> (1) Assume it is really like a 550, i.e., that
> <bar101@example.com> is, at least for traffic coming from
> <foo@example.net>, a more or less permanently unavailable or
> non-existent address, continue with other addresses, but never
> retry <bar101@example.com> and basically tell whomever or
> whatever you got the message from that it is undeliverable for
> that address.

Up to here, this is what Exim does.

>  If so, continue that "no retry" behavior for
> <bar102@example.com> and the (potentially) hundreds of addresses
> that follow.

Contingent on 552 responses also for these following RCPT commands
(you didn't specify the response code, so I'm assuming here)
any such further 5xx responses to RCPTs would be dealt with
in the same way as the first one above.

> 
> (2) Take the first one of those (the one with
> <bar101@example.com>) as a fatal error for more RCPT commands as
> a class, skip any other target addresses you have queued up, and
> move immediately to DATA (or, in principle, some
> extension-enabled command).

No, Exim does not do this.

> (3) Assume it really is a fatal error (based on the "first
> digit" rule, treating it more like 554, or assuming that the
> server is really out of memory and would not be able to accept
> DATA or the content that follows)  and send either RSET or QUIT
> as the next command.

No, Exim does not do this.  It proceeds to send further RCPTs (if
available for the message) and to send DATA (or equivalent).
-- 
Cheers,
   Jeremy