As to the ERROR-IS codes, they don't have to be complicated.  When an
error condition is detected, they would be an OPTIONAL way to further
describe the error.  The only requirement would be that no fales
descriptions be sent.  The coding can be structured with varying amounts
of information.  Whatever follows the number can be text taken as a
comment.
 
000 mail cannot be processed - unspecified reason
100 mail cannot be delivered to the userid - unspecified reason
110 mail cannot be delivered to the userid - no such user
120 mail cannot be delivered to the userid - inactive user
130 mail cannot be delivered to the userid - user space quota full
140 mail cannot be delivered to the userid - user refuses mail
200 mail cannot be delivered here (any userid) - unspecified reason
230 mail cannot be delivered here (any userid) - system file space full
300 mail cannot be forwarded from here - unspecified reason
310 mail cannot be forwarded from here - unknown destination
320 mail cannot be forwarded from here - gateway unavailable
330 mail cannot be forwarded from here - gateway queue full
340 mail cannot be forwarded from here - restricted gateway
900 mail cannot be processed because:
 
As you can see, the more digits supplied, the more useful and detailed the
information.  Many mailers cannot get that detailed, so they would use the
more generic code, even 000 if they cannot figure out what is going on.
Code 900-999 would be always reserved for any mailer implementation to
define as it needs.
 
Another field, ERROR-TO: should have the SAME number, but instead of a
comment, have the address of the failing destination.  When there are
multiple addresses and some are deliverable and some are not, this will
identify which were not.
 
The mere EXISTANCE of an ERROR-IS: field in the header should make programs
like LISTSERV stand up and take notice, e.g. send it to the post master or
list owner.  If the number codes are used right, we can even have it
remove users automatically and notify the list owner that it was done.
 
One other possibility in establishing a standard is to simply define an
extension to RFC822 by having SUBJECT: say a very specific text if the mail
is a rejection notice, and require that the TEXT describe precisely, by
a another STANDARD, what the error(s) was/were in similar ways as
described above.  There would be a SECOND blank line and the Original
mail's header, a THIRD blank line and the Original TEXT.  This method
would be the simplest way to establishing a standard since it would
impose the least complexity on exosting standards.  The SUBJECT: field
would contain the string "REJECTION NOTICE" in any case.
 
I hope LISTSERV doesn't see that up there :-)