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

[John C Klensin <[e-mail]>]

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