Message-ID: <55083977.7080004@joelhalpern.com>
Date: Tue, 17 Mar 2015 10:25:59 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
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 <john-ietf@jck.com>, Barry Leiba <barryleiba@computer.org>
References: <550212BD.6070506@nostrum.com> <550229E7.3080304@joelhalpern.com>
 <CALaySJ+3UWJGz_MjSZt=KqBnV+az4mVsKmnWi06q6kYCkO7Q7g@mail.gmail.com>
 <7C57505DBD1E7EB8518C2694@JcK-HP8200.jck.com>
In-Reply-To: <7C57505DBD1E7EB8518C2694@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/ZRKWeyuupQ_lpq1nL-L6_LTkgI4>
Cc: General Area Review Team <gen-art@ietf.org>, Tony Hansen <tony@att.com>
Subject: Re: [Gen-art] Review: draft-klensin-smtp-521code-05.txt
Precedence: list

That wording works for me.
Yours,
Joel

On 3/17/15 10:21 AM, John C Klensin wrote:
>
>
> --On Monday, March 16, 2015 23:06 -0400 Barry Leiba
> <barryleiba@computer.org> 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
>
>