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
|
