From: HENRY::IN%"cmcl2!uiucdcs!stargate!mark%rutgers.edu%csnet-relay.CSNET%relay.cs.net@RCA.COM" 3-JUN-1987 05:10 To: dovich@helios.dab.ge.com Subj: recent newsletter UUCP Zone News 5/23/87 ---- ---- ---- ------- The topic for this issue is forwarders. Most of you have a forwarder, but several domains don't have one. Some of you have a forwarder, but might wish to change to another. Some of you don't need one. This Newsletter. ---- ----------- This is the first issue of the UUCP Zone News, a newsletter for members of the UUCP Zone. It is being sent out in electronic form, rather than hard copy, as a cost-saving and time-saving measure. We are currently unsure how often it will be sent out; we'll start on an "as-needed" basis and see how things go. Your feedback is requested. Do you like the idea of an electronic newsletter? What would you like to see in it? Would you rather see it done differently? Would you like to see articles by UUCP Zone members, in addition to news from the UUCP Project? What is a Forwarder? ---- -- - ---------- A forwarder is a kind of mail bridge host between DDN (formerly called the ARPANET) and UUCP. The DDN nameserver structure directs all DDN mail for your domain to the forwarder, and the forwarder passes the mail from DDN into UUCP. Forwarders can also forward your mail from UUCP to DDN, but it is not strictly necessary to use your forwarder for this, since mail to any of the published UUCP->DDN gateways can do this. Why do we need a Forwarder? --- -- -- ---- - ---------- Not every domain needs a forwarder. Since forwarders exist entirely to get mail from DDN to your domain, if you already have some way to do this, you may not need one. For example, if your domain is already on DDN or CSNET, and you expect to continue to get mail from DDN using that method, you don't need a forwarder. If you are joining a "domain park" with a 3rd level domain name, you don't need a forwarder because you'll be using the park's forwarder. We require that all UUCP domains get a forwarder, unless they don't need one for a reason listed above. Lack of a forwarder means that mail from DDN to your domain address will not work. Since many UUCP hosts are also on DDN and use the DDN nameservers to deliver domain mail, or forward their mail through hosts that do, even mail originating on UUCP sometimes cannot be delivered without a forwarder. Sites without forwarders also cause problems when consistency checks are run on DDN. If you do not have a forwarder, your alternatives include temporarily using a subdomain of UUCP (some forwarders translate this into a domain.UUCP!user@forwarder notation on the ARPANET), not using your domain name, using a 3rd level domain under an existing "domain park", or restricting your mail to the subset of UUCP that uses the UUCP map. Who are the Forwarders? --- --- --- ----------- This is a list of current DDN->UUCP mail forwarders. Only these sites are currently set up to forward mail to UUCP COM/EDU/GOV domains. If you prefer to use a different forwarder, please contact the postmaster on that forwarder and inquire. If they are interested, have them contact us (registry@stargate.com or stargate!registry) and we'll put them in touch with a source of forwarding software. If your host is on UUCP and DDN and you are interested in helping us out by forwarding some traffic between UUCP and DDN, please contact us; you would be doing the UUCP community a great service. There are currently several forwarders available. We expect to continue to add forwarders. Forwarders in the western and southern USA are especially needed. Once you select a forwarder, you should contact the forwarder directly and inquire if they would be willing to forward for you. Please remember that they are under no obligation to do so. Once a forwarder has agreed to forward for your domain, contact us and let us know who is forwarding for you. What if my forwarder is SEISMO? ---- -- -- --------- -- ------- If your forwarder is seismo, you may wish to consider choosing another forwarder, especially if you are not in the Washington DC area. While no sudden action is anticipated, there are indicatations that someday in the future seismo may become unable to be a forwarder. There is no emergency, and no immediate action is required. In addition to the forwarders listed below, it is expected that UUNET (at the same location as seismo) may be able to forward. Who needs a forwarder? --- ----- - ---------- The following domains, according to our records, do not have a forwarder and need one. If you are on this list, we urge you to make arrangements with a forwarder soon. Please let us know so we can update our records. We ask that you have a forwarder by June 30, 1987. AIT.COM AlphaCDC.COM BRS.COM CIDNET.COM Cooper.EDU DATACUBE.COM Decision.COM HARRIS.COM HAWAII.EDU Howtek.COM INMET.COM Kesmai.COM Retix.COM Tandy.COM TTI.COM USMA.EDU VORTEX.COM Who should we Contact? --- ------ -- -------- If you are not sure who to contact, we currently recommend as follows: (1) If you are a country, or otherwise already have an excellent link to seismo, consider them. (2) If you are near Silicon Valley, consider Sun. (3) If you are in the Central USA, consider Illinois (either one). (4) If you are in Eastern USA, consider MIT, Rutgers, or Harvard. (5) If none of the above applies to you, it may be worthwhile to inquire at a local ARPA/UUCP gateway. It is unlikely they will be able to immediately set up the forwarding capability, but they may be able to begin the process, allowing you to switch to them at a later date. (6) If all else fails, consider Illinois (CSO) or Rutgers and plan to move to another forwarder when one becomes available. (It is fairly easy to change forwarders.) (7) Normally domains should set up a direct UUCP connection to their forwarder, with the phone bill paid by the domain. If for some reason a direct link is impossible, consider Rutgers or MIT. In the descriptions that follow, note that HOURLY*4 means that you poll the forwarder every four hours to check for pending mail. ------------------------------------------------- Sun Microsystems (sun.com, sun.uucp) Contact: Bill Nowicki (nowicki@sun.com, sun!nowicki) 1. Limited number with prior arangement. A limit of about 20 UUCP sites per relay is reasonable to prevent overloading. The UUCP sites should ask our permission before registering us as their mail exchanger. If the UUCP project (e.g. Mark Horton) gets a request to register us as the relay, they should verify it with us before informing the NIC. We reserve the right to terminate the relay service at any time, if, for example, the traffic becomes too heavy. 2. Local calls only. This limits the service to sites that are in the Palo Alto, Mountain View, or Sunnyvale areas. Some exceptions may be granted if the site polls us regularly instead of having us call them. 3. Preference to non-competitors. This is purely subjective. We do our best to cooperate in a spirit of open communication; however, we would like to avoid the awkward situation of providing a service to our competition. 4. Preference to current direct UUCP neighbors. We prefer to just unify the name format on our current UUCP partners rather than add new UUCP load. Eventually we should also provide this service for all Sun's world-wide field offices and subsidiaries. ------------------------------------------------------------ University of Illinois, Computing Services Office (uxc.cso.uiuc.edu, uiucuxc.uucp) Contact: Paul Pomes (postmaster@uxc.cso.uiuc.edu, uiucuxc!postmaster) 1. Limited number with prior arangement. A limited number of UUCP sites per relay is reasonable to prevent overloading. The UUCP sites should ask our permission before registering us as their mail exchanger. If the UUCP project (e.g. Mark Horton) gets a request to register us as the relay, they should verify it with us before informing the NIC. We reserve the right to terminate the relay service at any time, if, for example, the traffic becomes too heavy. [Requesting permission can be simultaneous with sending your L.sys information to uiucuxc!postmaster] 2. Direct UUCP connection with uiucuxc. Any prospective MX clients should set up a bidirectional UUCP connection with uiucuxc. Send your L.sys information to uiucuxc!postmaster or postmaster@uxc.cso.uiuc.edu. We will install, test the connection, and then fire a letter down the direct link with our L.sys information. For "L.sys Information", we want something along the lines of the following. In particular, we want contact information. This must include the full company or agency name, mailing address, and phone number. Please use the format below. # UIUC Computing Services Office (CSO), Gateway Machine, Urbana, IL # UNIX Postmaster, UofI, CSO, 1304 W Springfield Ave, Urbana, IL 61801 # This machine is uiucuxc.uucp and "uxc.cso.uiuc.edu" on the DARPA Internet. # Contact: uiucuxc!postmaster, postmaster@uxc.cso.uiuc.edu # Paul Pomes, +1 217 333 6262 uiucuxc Any TCP 540 uxc.cso.uiuc.edu login: SIGNON Password: PASSWORD uiucuxc Any ACU 2400 1-2172446290 "" \r ogin:--ogin: SIGNON word: PASSWORD uiucuxc Any ACU 1200 1-2173334007 "" \r ogin:--ogin: SIGNON word: PASSWORD uiucuxc Any ACU 300 1-2173334007 "" \r ogin:--ogin: SIGNON word: PASSWORD N.B. The "" \r sequence (expect nothing, send CR) is needed to for auto-bauding. 3. Clients may be required to poll uiucuxc Depending on traffic levels, clients may be asked to poll uiucuxc to pick up their mail. At first, we will deliver pending traffic several times during the night. 4. We will route other traffic through your site. If pathalias decides that going through your site is cheaper, we will do it. This will defer any decisions, on an individual basis, about requiring clients to poll uiucuxc. ------------------------------------------------------------ University of Illinois (a.cs.uiuc.edu, uiucdcs.uucp) Contact: Ray Essick (postmaster@a.cs.uiuc.edu, uiucdcs!postmaster) 1. Limited number with prior arangement. A limited number of UUCP sites per relay is reasonable to prevent overloading. The UUCP sites should ask our permission before registering us as their mail exchanger. If the UUCP project (e.g. Mark Horton) gets a request to register us as the relay, they should verify it with us before informing the NIC. We reserve the right to terminate the relay service at any time, if, for example, the traffic becomes too heavy. [requesting permission can be simultaneous with sending your L.sys information to uiucdcs!postmaster] 2. Direct UUCP connection with uiucdcs Any prospective MX clients should set up a bidirectional UUCP connection with uiucdcs. send your L.sys information to uiucdcs!postmaster or postmaster@a.cs.uiuc.edu. we will install & test the connection and then fire a letter down the direct link with our L.sys information. For "L.sys Information", we want something along the lines of the following. in particular, we want contact information. # UIUC CS Department, Gateway Machine, Urbana, IL # this machine is "a.cs.uiuc.edu" on the DARPA Internet # uiucdcs!postmaster, postmaster@a.cs.uiuc.edu # Ruth Aydt, (217) 333-8924 uiucdcs Any TCP 540 a.cs.uiuc.edu login SIGNON password PASSWORD uiucdcs Any ACU 2400 1-2173337866 ogin:--ogin: SIGNON word PASSWORD uiucdcs Any ACU 1200 1-2173338267 ogin:--ogin: SIGNON word PASSWORD uiucdcs Any ACU 300 1-2173338267 ogin:--ogin: SIGNON word PASSWORD 3. Clients may be required to poll uiucdcs Depending on traffic levels, clients may be asked to poll uiucdcs to pick up their mail. At first, we will deliver pending traffic several times during the night. 4. We will route other traffic through your site. If pathalias decides that going through your site is cheaper, we will do it. This will defer any decisions, on an individiual basis, about requiring clients to poll uiucdcs. -------------------------------------------------------- Center for Seismic Studies (seismo.css.gov, seismo.uucp) Contact: Rick Adams (rick@seismo.css.gov, seismo!rick) Except in very special cases (i.e. a top level country domain) seismo is not acting as mail forwarder for any additional sites. If you feel you really must use seismo, contact registry@stargate.com and explain why another forwarder is inappropriate. Seismo is currently forwarding at capacity. -------------------------------------------------------- Massachusetts Institute of Technology, EECS Dept. (EDDIE.MIT.EDU, mit-eddie.uucp) Contact: Jeff Siegal (jbs@EDDIE.MIT.EDU, mit-eddie!jbs) 1. Limited number with prior arangement. A limited number of UUCP sites per relay is reasonable to prevent overloading. The UUCP sites are to ask our permission before registering us as their mail forwarder. If the UUCP project gets a request to register us as the relay, they should verify it with us first. 2. Preference to direct UUCP neighbors. We would prefer to talk directly to sites we forward for. If you cannot arrange direct UUCP, but have a reliable path, we may agree to forward temporarily (i.e. until more forwarders are available). 3. Other sites are welcome to inquire about a UUCP connection. Please be aware of the following limitations: 1) You will be required to poll eddie at least HOURLY*4 2) Volume must be kept reasonable. 3) We will route other mail through your site as indicated by pathalias. 4. No guarantee of service is implied or intended. We reserve the right to interrupt or terminate service at any time. We do not guarantee any of the following: 1) That messages will not be damaged, delayed, or lost. 2) That messages will not be delivered erroneously to any number of third parties. 3) That the contents of messages will not be disclosed due to software trouble or security flaws. 4) Any level of reliability, continuity, service or support. -------------------------------------------------------- Harvard University (harvard.harvard.edu, harvard.uucp) No official policy in effect, not completely set up. Contact postmaster@harvard.harvard.edu -------------------------------------------------------- Rutgers - The State University of New Jersey, CCIS (rutgers.edu, rutgers.uucp) Contact: Mel Pleasant (postmaster@rutgers.edu, rutgers!postmaster) +1 201 932 2023 1. Limited number with prior arangement. A limited number of UUCP sites per relay is reasonable to prevent overloading. The UUCP sites must ask our permission before registering us as their mail exchanger. If the UUCP project receives a request to register us as the relay, they must verify it with us before informing the NIC. [Requesting permission can be simultaneous with sending your L.sys information to rutgers!postmaster] 2. Perference to direct UUCP neighbors. We would prefer to talk directly to sites we forward for. If you cannot arrange a direct UUCP connection, but a reliable path exists between your site and ours, we may agree to forward. The existence of a reliable path will be determined solely by the rutgers postmaster. When possible, prospective MX clients should set up a bidirectional UUCP connection with us. Send your L.sys information to rutgers!postmaster or postmaster@rutgers.edu. If accepted, we will install, test the connection, and then fire a letter down the direct link with our L.sys information. For "L.sys Information", we want something along the lines of the following. In particular, we want contact information. This must include the full company or agency name, mailing address, and phone number. Please use the format below. # ABC Corporation, 1234 Any Avenue, Mytown, NJ # This machine is uiucuxc.uucp and "uxc.cso.uiuc.edu" on the DARPA Internet. # Contact: abcvax1!postmaster, postmaster@vax1.abc.com # John Doe, +1 201 449 1631 abcvax1 Any TCP 540 vax1.abc.com login: SIGNON Password: PASSWORD abcvax1 Any ACU 2400 1-2014491100 "" \r ogin:--ogin: SIGNON word: PASSWORD abcvax1 Any ACU 1200 1-2014491133 "" \r ogin:--ogin: SIGNON word: PASSWORD abcvax1 Any ACU 300 1-2014491166 "" \r ogin:--ogin: SIGNON word: PASSWORD N.B. The "" \r sequence (expect nothing, send CR) is needed for auto-bauding. 3. Clients may be required to poll rutgers. In general, clients will be asked to poll rutgers at least HOURLY*4 to pick up mail. Under certain conditions, arrangements can be made to have rutgers call your system. Ask postmaster for details. 4. We will route other traffic through your site. If pathalias decides that going through your site is cheaper, we will do it. 5. No guarantee of service is implied or intended. We reserve the right to interrupt or terminate service at any time. We do not guarantee any of the following: 1) That messages will not be damaged, delayed, or lost. 2) That messages will not be delivered erroneously to any number of third parties. 3) That the contents of messages will not be disclosed due to software trouble or security flaws. 4) Any level of reliability, continuity, service or support.