From: dboyes@is.rice.edu (David E Boyes)
Subject: Re: I asked the wrong question (Why no MX for .BITNET)
Organization: Rice University
Date: Tue, 29 Dec 1992 09:36:04 GMT

In article <725602589snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
>The question that I *really*
>meant to ask was "How can a site that currently receives all its mail
>over BITNET convert to receiving mail over the Internet"? 

It takes planning and at least 2-3 months advance notice. Here's
how I've done it:

1) Install and configure TCP and SMTP on the host.
2) Send updates to UPDATE@BITNIC to add a :internet. and
   :newnode. tag containing the FQDN to the node entry for that
   node. This has the effect of mapping the BITNET node name to
   the Internet FQDN and disallowing any new mailing list
   subscriptions from the BITNET node name on mailing lists that
   use Eric Thomas' Revised LISTSERV, forcing users to subscribe
   to new lists using mail.
3) Configure your mail program to ONLY generate the FQDN. If this
   is a CMS host running RiceMAIL, set the LOCAL.DOMAIN variable
   in MAILSYS XEDIT.
4) If this is a CMS host, write a small program to process NAMES
   files, replacing :node. entries with the BITNET node name with
   the equivalent FQDN for the host. BITNET hosts that are not the local
   host or known to be in the local domain should be routed via
   the closest official BITNET/Internet gateway via percent
   hacks. I have written such a beast, but never got to deploy
   it. You may want to run this as part of the login process in
   SYSPROF for CMS machines. VMS users will have more trouble
   with this as there's no standard place for this info.
5) Wait one month until the new BITEARN NODES is distributed.
   This is so the :internet/:newnode tags are propagated to the
   LISTSERVs, which will see the :newnode tags and automagically
   replace user@oldBITnethost with user@FQDN when the new tables
   are installed.
6) Monitor your console logs from your BITNET mailer process or
   NJE support utility and write a widget that scans/analyzes
   them and sends mail back to originators warning them of the
   address change. I have such tools for the Crosswell/Princeton
   MAILER if anyone wants them. Be sure to avoid LISTSERV@* and
   MAILER@* as origins to prevent loops.
7) Do this for as long as you want to provide as a transition
   period. When you're ready, submit a DELETE NODE xxxx request
   to UPDATE@BITNIC.
8) Wait for the tables to be distributed again. 
9) Pull the plug.

The critical part is waiting for the tables to be distributed so
that the entire net is aware of the changes and mailing list
subscriptions get updated properly. 

This doesn't catch everything, of course, but it gets a majority
of the traffic. Users at sites without domain-capable mailers may
complain, but I see that as incentive to get with the program and
install the necessary software.

>-russ <nelson@crynwr.com> What canst *thou* say?

David Boyes, postmaster, ricevm1.rice.edu
-- 
David Boyes      In the event I am captured or killed, Rice University
dboyes@rice.edu  and the Office of Networking and Computing Systems
                 will deny any knowledge of my opinions.