Folks,
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.
d/
ps. A side-benefit of this will be simplifying the spec.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net