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 :-)