As long as the information is present, those, too, are aesthetic
decisions about syntax as long as one can ignore the failure cases. If
one considers the possibility of failure cases, then, those decisions,
too, are part of the system and don't exist in isolation.
Having non-orthogonal headers (i.e. the existence or values of one
header are dependent on the existence or values of another) may increase
the likelihood of illegal messages, but whether we have them or not
we still need to think, as John says, about failure cases.
A small relevant point: When the "standard format for error returns" is
defined it will probably be a multipart message with the returned
message (if present) in a bodypart of Content-type message. It seems
obvious that if the reason (or one of the reasons) why the message is
bouncing is because it has illegal syntax then the returned message
should instead be put in a bodypart of type text (or even binary or
application/illegal-message). This will be important because if the
message was to have gone forward on a 7-bit path and it can't be re-encoded
in 7-bit (because it is illegal) and it is now returning on a 7-bit path
(not impossible see Ned's message on bounces) then we won't have any
problem about down-grading it to 7-bit on its return path (because we
won't face the restriction on re-encoding message body-parts).
Bob Smart