Carnegie Mellon University Website Home Page
 

Error Handling in distribution lists

Error messages sent back to the sender Any email messages which cannot be delivered will be returned to the email address in the Distribution-errors to: line. If you wish to have error notices go back to the sender of a piece of mail rather than to you (the owner of the distribution list), you can do so with the following line:

Distribution-errors-to-originator: yes

Due to a protocol limitation (not specific to Andrew), there is no way to send error notices both to the sender and to a list maintainer.

Error Messages to more than one email address You can only specify one address in the "Distribution-errors-to:" line. However, if you wish to route error notices to more than one address (because, for example, there are multiple maintainers for the dlist in question), you can give a distribution list in the "Distribution-errors-to:" line, like this:

Distribution-errors-to: +dist+~ju33/dlists/spec-ed-errors

Please be careful with this feature; unless you use it carefully, you may find yourself routing returned messages back and forth from one distribution list to another.

Ignoring error notices

If you do not want to know about errors in the distribution list, you can choose to have error notices ignored altogether instead of having them sent to yourself or to the originator of the mail by giving two angle brackets as the "errors" address as shown below:

Distribution-errors-to: <>

Note: There is no space between the two angle brackets. You might choose to ignore error notices in a particular dlist file if that dlist is used in the "Distribution-errors-to:" line of another dlist file. Suppose, for example, that you and three friends are maintaining a large published distribution list. You want error notices from the large dlist to go to all four of you, not to any one individual, so you create a maintainer's dlist containing each maintainer's address and put the maintainer's dlist into the "Distribution-errors-to:" line of the large dlist. You might then choose to ignore error notices in the maintainer's dlist. First, because it may help prevent error notices from bouncing from the large dlist to the maintainer's dlist and back again, and second, because even if there is an error in one of the four maintainer addresses, the other three will get the error notice so the large dlist can still be maintained.

An example illustrating many dlist features. Suppose you are the manager of the BOFORO project at Carnegie Mellon. You expect the BOFORO project to go on indefinitely, so you do not want to route errors to any particular person, but rather to a dlist that would ostensibly contain the names of maintainers who work for you. You also want to lay out the dlist so that you can make any needed changes to subgroups in the list quickly and easily. Here, using a combination of blank lines and comments, is what you might do:

; Distribution list for the BOFORO project
; Distribution errors to the boforo-errors mailbox
Distribution-errors-to:
+dist+/afs/andrew.cmu.edu/usr8/ju33/dlists/boforo-errors
Distribution-content:
;Members working in Building C
edFl+@andrew.cmu.edu,
canteloupe@veggie.cmu.edu,
; Members working Hall Atwater building
joe.boss@psy.cmu.edu,
ryEr+@andrew.cmu.edu,
; Member(s) at a remote site
honeydew@melon.cs.dod.edu,
; Members at a remote site who are part of an Internet dlist
boforo-remote-dist@berries.li.ukent.edu
Last Updated: 9/20/06