Re: [Gen-art] Review: draft-klensin-smtp-521code-05.txt

"Joel M. Halpern" <> Tue, 17 March 2015 14:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9D6831A1A94 for <>; Tue, 17 Mar 2015 07:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 440aON4P5Gqb for <>; Tue, 17 Mar 2015 07:26:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B11D71A1A87 for <>; Tue, 17 Mar 2015 07:26:12 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AA5C24ECE5; Tue, 17 Mar 2015 07:26:12 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E41FD2400AE; Tue, 17 Mar 2015 07:26:11 -0700 (PDT)
Message-ID: <>
Date: Tue, 17 Mar 2015 10:25:59 -0400
From: "Joel M. Halpern" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: John C Klensin <>, Barry Leiba <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: General Area Review Team <>, Tony Hansen <>
Subject: Re: [Gen-art] Review: draft-klensin-smtp-521code-05.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Mar 2015 14:26:14 -0000

That wording works for me.

On 3/17/15 10:21 AM, John C Klensin wrote:
> --On Monday, March 16, 2015 23:06 -0400 Barry Leiba
> <> wrote:
>> Joel, thanks for the review.
>>> Minor issues:
>>>      The description of the 556 reply code in section 4 seems
>>>      to switch between refering to the generating entity as a
>>> client and as a sesrver.  I presume this is because the
>>> actual sitaution is an SMTP server is trying to pass
>>> information onwards, and in that onwards direction it is a
>>> client which.  But it is still confusing for an SMTP client
>>> to make a determination and then an SMTP server which is
>>> apparently the same entity to generate the rror code to some
>>> other SMPT client.
>> You're right about why, and you're right that it's confusing.
>> I think the reader and the text would be better served by
>> changing the first instance of the word "client" (in the
>> second sentence) to "server". Even though the server is acting
>> as a client when it makes the determination that sentence is
>> talking about, it's acting as a server in the sense that it
>> will be returning a 556 to the client that it's serving.
>> Calling it a "client" here only confuses things.
> Hi.  While I agree that the existing text is confusing (although
> correct), the suggested fix just substitutes one confusing
> arrangement for another, with "server" used twice in the same
> sentence to refer to two different hosts that serve two
> different roles.  See if the following rather more complete
> rewrite for that second sentence works better:
> 	When an intermediate SMTP system (typically a relay)
> 	that would normally attempt to open a mail connection to
> 	a host referred to in a forward-pointing address can
> 	determine that the host does not accept mail
> 	connections, and do so without attempting to open a
> 	connection to that target host, it is appropriate for it
> 	to return a reply with a 556 code to the system that
> 	sent it the message for outbound transmission.
> The eliminates the "client" and "server" terminology entirely
> and talks instead about actual functions.  I'm tired and there
> are probably better ways to stay that, but I think it is an
> improvement over both the existing text and the client -> server
> patch.
> There is a case that the above doesn't cover, but neither does
> the original paragraph, and that is when a submission server
> (sic) encounters a nullMX record or equivalent on initial
> lookup.  When the submission server tries to do that, it is
> acting as an SMTP client, but the status of messages it returns
> to the submitting MUA is deliberately very flexible in the spec
> (see Section 3.2 of RFC 6409).
>       john