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

[Barry Leiba <[e-mail]>]

> That wording works for me.

Yeh.

b

> 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
>>
>>
>