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

["Joel M. Halpern" <[e-mail]>]

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
> <[e-mail]> 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
>
>