> > 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.
>
> What will programs do with this information about the cause of the
> error?  It seems to me that the only reason for putting such
> information into a header is that a program might process it in some
> way.  A person can see what the error was by reading the text of the
> rejection notice.
 
Exactly!
 
If the error code describes a relatively permanent condition of
undeliverability to that user at that address, then LISTSERV can
actually go ahead and delete the user from that list and maybe
others, and provide notification that it has done so, instead of
making me have to do it AND THEN READ THE SAME REJECTION NOTICE
TWENTY MORE TIMES because the user was in the list all day.
 
One example I left out is a forwarding address.  If the mailer knows
that the user has left a permanent forwarding address, LISTSERV could
be made to react to that by updating the users entry in the list.
Such standard needs to also indicate if the mailer also passed on a
copy of the mail or not.