Hi,
As the boilerplate sez….I have reviewed this document as part of the
Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the
IETF drafts. Comments that are not addressed in last call may be included in AD
reviews
during the IESG review. Document editors and WG chairs should treat these
comments
just like any other last call comments.
(With apologies to the author and my ADs that it's late; I read the draft and
then spaced actually shipping the review after Dallas.)
This is ready to go, with some editorial nits (below).
The IETF Last Call had a few comments, mostly on a specific clarification; they
were supportive of publication. There is a fairly lengthy and substantial
comment from Murray Kucherawy that it appears John agreed to incorporate in the
next rev, explaining a little more closely the relationship between what this
draft suggests and RFC 5321 regarding dropped connections. I thought Murray's
explanation of his suggestion was compelling enough that I'd like to see the
change incorporated.
(I was also surprised that "This document updates RFC 5321 to add descriptions
and text for two reply codes, but there is no registry for those codes." The
workaround looks OK to me from an operational perspective but I'm not an SMTP
implementer.)
This document is a useful update to the standard to support some elements of
current practice and at least one expected separate update also reflecting
practice in the field (nullMX).
Nits:
Sec. 3:
"It SHOULD
NOT be used for situations in which the server rejects mail from
particular hosts or addresses or in which mail for a particular
destination host is not accepted;."
might be clearer as "….hosts or addresses, or situations in which mail for a
particular destination host is not accepted."
The next sentence:
"As discussed in SMTP, reply code
554 is more appropriate for most of those conditions; an additional
case, in which the determination that mail is not accepted is
determined outside the mail system, is covered in the next section
(Section 4)."
might be clearer as "…more appropriate for most of those conditions. An
additional case, in which the determination that mail is not accepted is made
outside the mail system, is covered…."
Best,
Suzanne
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp