The "Global list exchange" is a new feature of LISTSERV which requires LMail version 1.1d with a modified LSMPLIB, which will be standard in 1.1e. This message is being sent to both lists but discussions should take place on LSTSRV-L as LMail's role is purely mechanical. When activated (by adding GLOBAL_LIST_EXCHANGE = 1 to LMail's LOCAL SYSVARS), this feature turns your system into a global list exchange to which your users can address mail for any public LISTSERV list, without having to know where it is located. When LMail fails to deliver a message to a local user, it passes it to LISTSERV rather than generating a delivery error right away. LISTSERV looks up GLOBLIST FILE for a list by that name, and either forwards the message to the list or passes it back to LMail, which will then generate a delivery error. The delivery error format is the same, the message just has to go through LISTSERV for verification. If LISTSERV fails to find a list by the requested name, there is virtually no difference to the end user (just an extra 'Received:' field in the returned message). The purpose of this feature is to make it possible for users without much knowledge of computers to write to "the XYZ list" without knowing where it is located or having to remember that, while subscription requests and the like can be sent to any LISTSERV, this just doesn't work with postings. About half of the erroneously addressed mail I get at SEARN is mail for valid lists which people just assumed to be located at SEARN, since that is where they sent their SUBSCRIBE command, which was accepted. "Yes, system said something about forwarding something, but I put in basket, I am sorry, also then system sent me a FAX to confirm: SUBSCRIBE ok. You are right: FAX says CEARN, not SEARN, but I thought it was the same, well it SOUNDS the same anyway, so I send FAX to SEARN for list, and system say: error" :-) Anyway the purpose is NOT to encourage users to always send mail to a global exchange host rather than to the actual address, but only to make it possible for mail sent to an exchange host to get there anyway - and to tell the user where the list is actually located. Anyway, when looking for a suitable list, LISTSERV gives precedence to peered lists (to avoid sending the message to a local redistribution inadvertently configured as a public list). It does not attempt to select any particular peer (should it be the one closest to the user, or to LISTSERV? What if the user is routed via INTERBIT and the closest peer is in the wrong country?). When there are several lists by that name and none is a peered list, it forwards to one of the list and suggests a "LIST GLOBAL /listname" command for more information. This may seem inappropriate, but in practice this happens when you have several local redistribution of the same list. If you have a magic formula that a network-ignorant user can use to determine that XYZ-L@UIUCVMD is the local redistribution while XYZ-L@CEARN is the main list, other than "because Phil Howard used to make local redistributions of everything whereas CEARN has mostly master lists", I am willing to consider changing the behaviour :-) Fortunately this is a rare occurrence. The global exchange requires LMail 1.1d with a modified LSMPLIB (available from me) and LISTSERV 1.7f (rev 4 for the beta-test sites, to be distributed monday or tuesday). There is nothing to configure in LISTSERV, but you have to be a backbone site or nothing will happen (only backbone sites have the LIST GLOBAL information). And, obviously, if LMail is told to pass all local recipients to another mailer (MUSIC, XMAILER with local directory lookup mods, etc), it cannot act as a global exchange because it cannot know which recipients the other mailer will know about and which will be rejected. Finally, before deciding to become a global exchange host you should carefully review the names of any local redistribution list you might have - especially the ones that are not public. If you run local redistributions of popular mailing lists under the same name, you will not be able to act as a reliable global exchange because you users will expect (say) LMAIL-L@hostname to be the "real" LMAIL-L list, and not your local redistributor. Before activating this feature, you may have to change the names of such redistribution lists to something which doesn't conflict with the original name - for instance, LMAIL-R. There will always be a handful of conflicts with existing local usernames, but as long as the proportion is not higher than the amount of obsolete entries in GLOBLIST FILE this shouldn't be a problem. Eric