If you format your delivery errors like LMail, PMDF, MX and a few others
do, signoff will be automatic.
 
-------------------------------------------------------------------------
Here is a brief description of the LMail error message format. I will use
an example to save a thousand words:
 
-------------------------------------------------------------------------
Date:     Fri, 8 Jan 1993 20:04:50 +0100
Reply-To: [log in to unmask]
From:     RFC822 mailer (LMail release 1.1a/1.7e) <[log in to unmask]>
Subject:  Undelivered mail
To:       [log in to unmask]
cc:       [log in to unmask]
X-Report-Type: Nondelivery; boundary="> Error description:"
 
An error was detected while processing the enclosed message. A list of
the affected recipients follows. This list is in a special format that
allows software like LISTSERV to automatically take action on incorrect
addresses; you can safely ignore the numeric codes.
 
--> Error description:
Error-For:  [log in to unmask]
Alias:      [log in to unmask]
Error-Code: 3
Error-Text: No such local user.
 
Error-For:  [log in to unmask]
Alias:      [log in to unmask]
Error-Code: 3
Error-Text: No such local user.
 
Error-End:  Two errors reported.
 
------------------------- Rejected message (5 lines) --------------------------
Date:        Fri, 8 Jan 1993 20:04:47 +0100
From:        Eric Thomas <[log in to unmask]>
To:          [log in to unmask], [log in to unmask]
 
klºdfg
-------------------------------------------------------------------------
 
The only important line in the header is "X-Report-Type:", which says the
error report is  in the special format  used by LMail. Then  you have the
blurb of your choice, followed by the boundary defined by the report type
field, a series of individual  error reports, and an "Error-End:" keyword
(whose value is immaterial), and then whatever you want. The error report
tags must  be in  the order  shown, except "Alias:"  is optional.  I will
include a list of codes and more can  be added. The text is for the human
reader, only  the code is  parsed by programs.  These fields fold  in the
same way as  RFC822 header fields if they  don't fit on a line.  If it is
more convenient to issue a separate  mail message for each error, this is
not a problem; the format just lets  you batch several errors in a single
message if desired.
 
The codes: 0 is what you use  for all the weird errors you can't classify
too well, LISTSERV takes no action  on these codes by definition. 1 means
"don't know that/don't  know how to get there" (as  opposed to "can't get
there right now"), you'd use that if  a BITNET or DECNET node is unknown,
or if a domain is unknown  (like .ZZ). 2 means "configuration error", you
have detected an error in your tables which prevents you from delivering,
but that doesn't mean the address is bad. 3 is "no such local user". 4 is
"not allowed  to mail to  this user". The difference  between 3 and  4 is
that a 3 indicates there is no way to successfully send mail to the user,
whereas 4  indicates the user cannot  receive mail from the  address your
message came from. LMail uses code 4 when a user directs it to reject all
mail coming from mailing lists, but  to let private mail through. 5 means
"mailbox full", "quota exceeded", and so on.
 
For now LISTSERV takes  action on 1, 3 and 4,  and forwards anything else
to the list owner. But it is  important to assign new codes to categories
which would  have meaning to  a human list owner,  as I expect  people to
start  writing procedures  to  pre-process the  error  messages in  their
mailbox. Something like  "cannot deliver for N days,  will keep retrying"
is meaningful to a list owner and may help him decide what to do with the
subscription,  so it  should get  another  code. Obscure  errors such  as
"invalid device name" can use the catch-all code, 0.