[Top] [All Lists]

Re: rfc2821bis-03 Issue 32: "MUST take responsibility"

2007-04-26 10:32:41

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.


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.