John C Klensin wrote:
--On Sunday, 29 April, 2007 23:24 -0400 Tony Hansen
<tony(_at_)att(_dot_)com> wrote:
The consensus on the basic issue of changing the wording of
this paragraph to include the word MUST:
The responsibility of an SMTP client is to transfer mail
messages to one or more SMTP servers, or report its
failure to do so.
In either case, a formal handoff of responsibility for
the message occurs: the protocol requires that a server
MUST accept responsibility for either delivering a
message or properly reporting the failure to do so.
is positive.
However, several people raised issues with some ambiguities in
the text. I found Dave Crocker's description of the
ambiguities to be the most succinct. These ambiguities do
exist whether the MUST is there or not, so they pass my "chair
filter", so should probably be dealt with.
Text would be welcome.
john
I'll take a stab at it.
First, I think the first paragraph is fine.
The second needs to be reworded to separate the protocol and policy
consideration. The 2nd paragraph is within the description of the Basic
SMTP design structure which implies the automation, the expected flow
and programmability of this model. So you have a technical description
of the expected flow and that is how I believe the paragraph should be
restructured:
This is just a stab at it, changes, mods are more than welcome:
In other words, message transfer can occur in a single connection
between the original SMTP-sender and the final SMTP-recipient, or can
occur in a series of hops through intermediary systems.
At any point in the transport topology, the SMTP server may
issue 4yx/5yz response based on site policy decisions. In such
a case, the SMTP-client MUST follow the requirements as
stated in section 4.2.1. "Reply Code Severities and Theory."
When a successful transaction occurs at a SMTP-server (a message is
accepted by the server), the protocol requires that a server MUST
begin the process of delivering the message or begin the process
of sending a failure notification as described in section 6.1
"Reliable Delivery and Replies by Email."
Please keep in mind that local site policies is the exception
to the SMTP protocol technical server requirement for mail
delivery/failure notification. Please refer to section 7.9
regarding the scope of operation of SMTP Servers.
Think in terms of the "new developer" when reads this new standard and
begins to code his SMTP program, you want him to design the model based
on this technical Delivery/Notification principle that is essentially
burned into our society.
But he also needs to be aware that he SHOULD offer operations the policy
driven options to define his local site policies - a concept that is
also burned into our society.
So its a separation of the technical protocol vs local policy
considerations. Both acceptable practices.
Finally, I would personally also consider the possible rewording of 7.9
where we inject the concept of "responsibility" into the 1st or 2nd
sentence of "Scope of Operations." I personally would not begin this
section with a theme that it is a "normal consideration" to reject mail.
I would flip it around like so, again, just winging it, 250, 450 and 550
responses are welcome :-)
7.9. Scope of Operation of SMTP Servers
Cooperation among sites and installations makes the
Internet electronic mail framework possible.
When accepting a message, one of the important site operational
responsibilities is to properly deliver messages to its
intended target recipients or to properly report the
non-delivery failures to the reverse-path sender.
However, it should be noted, it is a well-established principle
that an SMTP server may refuse to accept mail for any operational
or technical reason that makes sense to the site providing
the server. The responsibility lies with the site for the decision
to refuse mail. If sites take excessive advantage of the right
to reject traffic, the ubiquity of email availability (one of
the strengths of the Internet) will be threatened; considerable
care should be taken and balance maintained if a site decides
to be selective about the traffic it will accept and process.
--
HLS