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.
|
