Dave Crocker wrote:
I see two issues with this text, suggesting the need for some added
text. It's not that there is anything "wrong" with the proposed text,
but that it is missing some detail, and certainly none of this would
change SMTP semantics:
1. A server is not "always" required to accept responsibility. Rather,
it is required to accept responsibility after issue a success response
to some part of the protocol. Until it issues that response, it is NOT
responsible for the message; the client is.
2. In other words, what is missing is reference to the state-change that
carries the formal transfer of responsibility from client to server --
and it needs to be stated in terms of both client and server I assume
that it is a 250 reply to DATA, but wouldn't stake my life on that.
+1.
In my view, the sticky point (both technical/functional and dare I say,
legal) is message acceptance and then failing to deliver and also
failing to notify the original sender.
Add to this sticky point the following statement in 821/2821 and 2821bis
for "Scope of Operation of SMTP Servers":
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.
which we often refer to as "Local Policy" decisions or reasons.
So we (server developers) have a small conflict between the technical
requirements to maintain mail flow and delivery status completion, and a
relaxation to provide policy requirements or features to operators.
So I think if we can express the "Must Take Responsibility" statement to
one that a technical functional requirement, then specs will cover both
specs, technical and policy (and dare I say, legal).
I think that will entail moving the term "responsibility" to the policy
portion of the specs. So how about this:
2. The SMTP Model
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. In either
case, a formal transaction handoff for the message occurs: the
protocol requires that a server MUST provide a mechanism to either
delivering a message or properly reporting the failure to do so.
7.9 Scope of Operation of SMTP Servers
It is a well-established principle that once a message is accepted
at the DATA state, the site MUST take responsibility to deliver
the message or to provide a non-delivery notification. However, it
is also an accepted principle, site local policies may refuse to
accept mail or deliver notifications for any operational
reason that makes sense to the site providing the server.
I think the above can be said better, but just trying to stress that
SMTP is a "mechanism" that is programmed and designed to follow an
automation concept. If the local policy wishes to change that
automation than IMO it is (the site) that is inheriting the responsibility.
--
HLS