[Top] [All Lists]

mechanism vs. policy for email (and RFC2821bis)

2007-03-31 06:08:04


One of the unfortunate realities that distinguish applications-level protocols from the lower layers seems to be a consistent requirement that implementations tolerate a much wide range of conformance to specifications -- or, rather, non-conformance.

That means that all sorts of discretionary behavior develops and is not really documented.

The computer science distinction between defining basic mechanism, versus defining policies for using the mechanism, can help us out here quite a lot, I think.

Due to the scale and dynamics of email abuse, receiving implementations have created an impressive array of changing rules for deciding whether to deliver a piece of mail. The basic Internet Mail specifications cannot cover this territory. It is too broad and too variable.

The best they can hope to do is provide mechanisms for how to do what is essential to email and for reporting results, with an extensible capability for defining new results.

     Anything in rfc2821bis that attempts to deal with
     message rejection on the basis of rules that are not
     absolutely required, for core functioning of the service,
     should be dropped from the spec, since they already fail
     to represent consensus behaviors.

     Attempting to write new rules will be difficult, if not
     impossible, will take a long time, and probably would
     require moving the draft back to Proposed.  Dropping text,
     however, is simple and let's the draft proceed to Draft.


ps. A side-benefit of this will be simplifying the spec.

  Dave Crocker
  Brandenburg InternetWorking

<Prev in Thread] Current Thread [Next in Thread>