Here is a copy of the file I sent to the developers of MX and PMDF /Eric 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". For now LISTSERV takes action on 1 and 3, 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 "disk quota exceeded" 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-call code, 0.