HINTS FOR GETTING MAIL THROUGH VARIOUS GATEWAYS TO AND FROM JANET edited by Tim Clark, University of Warwick, UK Issue 7 - 23rd March 1990 CONTENTS Preface for Issue 7 1. INTRODUCTION AND WARNING 1.1 Who is the document aimed at? 1.2 A Note on Terminology 1.3 Upper or lower case for mail addresses? 1.4 JANET and Its Gateways 2. GETTING A COPY OF THIS DOCUMENT 2.1 Fetching Files Direct from Warwick University 2.2 Getting the Files via Electronic Mail 2.3 Obtaining a Paper Copy 2.4 Finding Out when new issues occur 3. EARN (BITNET NETNORTH) 3.1 Examples 3.2 Getting Mail Back 3.3 Contacts and Further Information 3.4 Tried and Tested? 4. INTERNET (DARPA, ARPANET, NSFNET) 4.1 Routing Problem 4.2 Examples 4.3 Getting Mail Back 4.4 Contacts and Further Information 4.5 Tried and Tested? 5. UUCP 5.1 Sending via UKC 5.1.1 Examples 5.1.2 Contacts 5.2 Sending Via EARN 5.2.1 Examples 5.2.2 Contacts 5.3 Sending Via the Internet 5.3.1 Examples 5.3.2 Contacts 5.4 Getting mail back 5.5 Tried and Tested? 6. CSNET Phonenet 6.1 Example 6.2 Getting Mail Back 6.3 Contacts 6.4 Tried and Tested? 7. EAN and X.400 MHS RELAYS 7.1 EAN 7.1.1 Examples 7.1.2 Getting Mail Back 7.1.3 Contacts and Information 7.1.4 Tried and Tested 7.2 X.400 MHS-RELAY 7.2.1 Examples 7.2.2 Gold-400 and Wider X.400 mailing 7.2.3 Getting Mail Back 7.2.4 Contacts and Information 7.2.5 Tried and Tested 8. JUNET (JAPAN) 8.1 Examples 8.2 Getting Mail back 8.3 Tried and Tested 8.4 Contact 9. MISCELLANEOUS OTHER NETWORKS 9.1 MAILNET 9.2 INFNET or IT.INFN - ITALY 9.3 TUAI - NEW ZEALAND 9.4 ACSNET and CSIRONET - AUSTRALIA 9.5 HEANET - EIRE 9.6 SDN - KOREA 9.7 SPAN - SPACE PHYSICS 9.8 Easynet - DEC 9.9 Xerox Grapevine 9.10 VNET - IBM 9.11 HARNET - HONG KONG 9.12 CANET - CHINA 9.13 BT Telecom Gold and Gold-400 9.13.1 Telecom Gold 9.14 TTNS - The Times Network for Schools 9.15 Commercial Mail Relay - Intermail 9.15.1 Direct Addressing 9.15.2 Addresses Embedded in The Mail 9.15.3 Getting Mail Back 9.15.4 Further Information 9.16 Telemail 9.17 MCIMAIL 9.18 FIDO NET 9.19 APPLE LINK 9.20 COMPUSERVE 9.21 INDIA 9.22 MICROLINK 9.23 Miscellaneous: ATT, BIX, BMUG, Connect, Geonet, Mfenet, NASAMail, Sinet 9.24 Elsewhere 10. GREY BOOK ABROAD 11. VARIOUS PROBLEMS 11.1 Case translation 11.2 Line truncation 11.3 Character translation 11.4 Alteration of the Contents 11.5 Characters trapped by the local mailer or Operating System 11.6 Mail Just Disappears 11.7 Indecipherable Mail Addressee 11.8 Mail gets Rejected 12. OTHER INFORMATION SOURCES 13. SUMMARY 14. DOMAINS 14.1 The Domain Problem 14.2 Partial Domain Routing 14.2 How to Use the Partial Domain Table 14.4 The Partial Domain Table 14.3 Examples 15. INDEX TO NETWORKS 16. SIGNATURES Preface for Issue 7 Over a year has passed since issue 6 and again there is a lot of new information in this issue. On the negative side: there has been very little information received to resolve some of the uncertainties mentioned in a number of the sections, so many of these still remain. My prediction in the previous issue, ``Now that the information is held in form which is easy to update, future issues are likely to appear more frequently,'' has been shown to be hopelessly wrong. Major changes include: + Changes in the JANET/DARPA-Internet gateway. + Many more networks mentioned. I am grateful for a number of contributions received, and this issue includes several sections of text, verbatim, from contributors. The individual authors are not identified, often because submissions from a variety of authors have been edited together. Some submissions I have not included, because they appear to have been obsoleted by later submissions. I have also shamelessly lifted text from various items in electronic discussion groups and other public information sources. For details of how to obtain a copy of this document, see section 2 below. This is the last version of this guide to be issued by me. Shirley Wood of the JANET Network Executive is taking over the editing of these hints in future. Further details in Section 1 below. USAGE You are free to copy, publish, or make whatever use you wish of this document with or without acknowledgment. I would be grateful if this `Usage' paragraph and the `Warning' paragraph in section 1 were incorporated in any substantial quotation from it. Tim Clark Computing Services, University of Warwick (my full `signature' is at the end of this document) 1. INTRODUCTION AND WARNING This document has grown way beyond its original function (a contribution to tips on mail gateways for circulation amongst the Midlands universities). I am grateful that the JANET Network Executive are taking over the task of collecting, editing and disseminating such information. As far as editing a document containing the ``hints'' is concerned, I unwittingly acquired the role which I am glad to be able to relinquish at last. I became a little worried about the widespread circulation of these hints, hence the following warning: WARNING I do not have time to thoroughly test everything out, follow up references etc. So this document should only be regarded as the basis for experiment, and by no means an authoritative document. I may be suggesting things that are inefficient, undesirable or just plain wrong. Many thanks to contributors near and far. If you wish to provide input, please do not mail me any longer, but instead mail: mail-hints@uk.ac.rutherford It would be particularly useful to provide verification that some of the routes that I have not tested, do in fact work. Also if there is a suggestion which you know just can not work - please provide this information. If you received this copy indirectly, and would like to receive future copies, refer to section 2 `Getting a Copy of this Document' below. 1.1 Who is the document aimed at? This document has been written in a form to be read more by people providing a computing service than the end users of the service. I.e. people who know something about electronic mail's technicalities, but have not got the time or inclination to unearth the hundreds of scraps of information required to work out how to get mail from A to B. If you have an `intelligent' mailer, then it may be possible to incorporate much of the information in the mailer itself, so the user merely has to use the simple address they've been given be their contact. E.g. the user just mails Fred@BITNET.UZYVM, Mary@comso.uzy.edu, Smith@oz.tivic or whatever, and the mailer translates it into one of the ghastly forms mentioned in this document. This document, when giving mail addresses, assumes basic mailers which can not handle such complexities. Many mailers do provide more than this basic function, for example those which recognize an `uk.ac.' name without the `uk.ac.' So the examples may need some tailoring if they are to be presented to users, rather than put them off with over complex addresses. 1.2 A Note on Terminology In discussions of mail addresses in a JANET context, the terms `NRS name' and `inverted NRS name' often crop up. To make this document simpler to read I usually adopt the convention uk.ac.place.machine, to imply use of an `NRS name' and machine.place.ac.uk to imply an `inverted NRS name'. It should be remembered that many addresses are not comprised of exactly four components. E.g. UK.AC.ESSEX and UK.AC.CAM.CL.TRPS. Similarly constructs like domain.place.machine and machine.place.domain are used instead of the more accurate (but also perhaps more obtuse) terms `big-endian' and `little-endian' respectively. For readers outside JANET, `NRS' is the Name Registration Scheme run by the JANET Network Executive which, amongst other things, acts as the naming authority for JANET. As the document was originally circulated only amongst a small group of people, I used the term `FTP' without explanation. By this I meant the UK NIFTP (or Blue Book FTP). To an Internet user FTP would more naturally mean Internet FTP. So I now stick to the term NIFTP instead. Hopefully this will not confuse JANET readers, to whom the term NIFTP may be more strange! Italics are used extensively for meaning, `Replace this with the actual name.' For example in the EARN section below, there is the suggestion that you mail `person%earn.sitename@uk.ac.earn-relay'. Faced with a person whose usercode/username/mail-id is `MARY' at an EARN site whose node name is `chmerv', this then becomes: MARY%earn.chmerv@uk.ac.earn-relay Unfortunately the use of italics will be lost on those who only have a plain ASCII version of this document. Fortunately this construct should be determinable from context alone. When chosing the examples, I've tried to use ficticous end sites and users. Similarly when giving an example of a hypothetical gateway, the name will normally be false. Real names of gateways are used where the example is suggesting that you use that gateway. 1.3 Upper or lower case for mail addresses? Most of the time it doesn't matter whether an address is in upper case or lower case - the two are often treated as equivalent. Some machines on UUCP do insist on their own name being in lower case and some machines (usually Unix) insist on the user's name being in the correct case (usually lower). This document uses rather a mixture. The best approach is to leave an address in the same case as it was supplied to you. So if someone tells you their address is `JBSmith%comsad@brucsim.uucp', you perhaps mail: JBSmith%comsad%uucp.brucsim@uk.ac.ukc or JBSmith%comsad%uucp.brucsim@UK.AC.UKC or JBSmith%comsad%brucsim.uucp%NET.uu.uunet@Uk.Ac.Earn- Relay leaving the components of the address that the user gave you in the same case as they were supplied. Note the problem with case conversion discussed in section 11.1 below. 1.4 JANET and Its Gateways First a very brief introduction to JANET and its mail. JANET is a network which connects the academic community in the UK: all universities, most polytechnics and a number of government research establishments (e.g. SERC, NERC, MRC). It is an X.25 based network which carries other traffic besides electronic mail, interactive and file transfer for example. On JANET the NIFTP protocol is used to convey mail, the mail itself conforms basically to RFC 822. This combination being defined in the `JNT Mail', or `Grey Book Mail' specification. Mail on JANET is generally point-to-point; that is the service sending the mail makes direct contact with the service which is to receive the mail. Sites which connect to JANET usually have their own local area networks. These may use the same protocols as JANET and so participate in end-to-end connection, or in some cases mail may be transferred across a site to a service which will deliver the mail over JANET. The mail gateways on JANET are attached to JANET just like all services on JANET. The difference is, of course, that these gateways are connected to other networks too. A diagram may be useful here, but is too difficult to include in the variety of formats that this document is available in. So imagine a `cloud' network, to which all services named UK.AC.something are connected. Amongst these are the following gateway sites with links off to the networks they are each connected to: UK.AC.EARN-RELAY A service at the SERC Rutherford Appleton Laboratory which is also node UKACRL in the EARN network. See section 3. UK.AC.EAN-RELAY A service at the University of London Computer Centre which also takes part in the EAN network by a connection to the Public Packet Switch Data Network (called PSS in the UK). See section 7. UK.AC.MHS-RELAY A service at the University of London Computer Centre for handling X.400 mail. The X.400 mail is sent and received over the Public Packet Switch Data Network (called PSS in the UK). See section 7. UK.AC.NSFNET-RELAY A service at the University of London Computer Centre which is also part of the Internet, being linked directly by transatlantic leased line. (Though PSS can also be used as a back-up.) See section 4. UK.AC.UKC The University of Kent at Canterbury. One of its services is a connection into the uucp network. It is the pricipal UK backbone site for uucp traffic, though some other sites on JANET handle local uucp traffic too. 2. GETTING A COPY OF THIS DOCUMENT The document exists in a number of different formats: file contents mail-gateways.7.txt A readable text file which can be displayed on dumb printers and VDUs mail-gateways.7.ms The format the document is maintained in, suitable for use on systems with tbl and ditroff (or troff) with the ms macros. mail-gateways.7.latex LaTeX input. Suitable for use on systems with LaTeX and TeX. Not available until 19th April 1990. mail-gateways.7.ps PostScript. Suitable for sending direct to a PostScript printer. 2.1 Fetching Files Direct from Warwick University To do this you need access to NIFTP and JANET. Do an NIFTP setting the FILENAME to the appropriate file chosen from the list above. Specify it in upper-case or lower-case, but don't used mixed-case. Set the USERNAME to anon (or ANON), and do not specify a USERNAME PASSWORD. The site is UK.AC.WARWICK.CU. If this name is not known to your NIFTP (it was registered in NIFTP context on 22 March 1990), UK.AC.WARWICK.SOL can be used until its expected departure in June 1990. 2.2 Getting the Files via Electronic Mail Nottingham University Computer Science Department have kindly agreed to hold the document and make it available with their `info-server'. Send electronic mail to info-server@uk.ac.nott.cs with the body of the message: Request: sources Topic: filename chosen from list above Request: end The topic line can be repeated for each file you wish to collect. E.g. Request: sources Topic: mail-gateways.7.txt Topic: mail-gateways.7.ps Request: end It will also supply a list of the files available in this category if sent the mail: Request: catalogue Topic: mail-gateways Request: end For additional information, like how to get the files in several chunks (if your mailer doesn't like receiving huge files), just send an empty message to it (or, if your mailer refuses to send an empty message, send something the info-server won't recognize, e.g. `boo!'). If all else fails, mail me (see my `signature' at the end), telling me what you want, what's gone wrong, and I'll mail you a copy. 2.3 Obtaining a Paper Copy If you really do want a paper copy from me, then write to me at the address shown at the end of this document, enclosing a cheque for 3.00 (sterling) made payable to `The University of Warwick'. If outside the UK, but within the EC, then it's 4.00 (sterling) or the equivalent of 6.00 (sterling) if the cheque is not made out in sterling. Outside the EC the corresponding amounts are 13.00 (sterling) and 15.00 (sterling). These prices are just the cost of copying, postage, and dealing with non-sterling cheques. 2.4 Finding Out when new issues occur If you want to be notified when a new issue is ready, please mail: mail-hints-request@uk.ac.rutherford 3. EARN (BITNET NETNORTH) For sites on BITNET and EARN, the sitename is usually a fairly horrid code of 4 to 8 characters. Alternatively it may be in the domain form, machine.place.domain, in which case it can be a real problem deciding that this is a BITNET/EARN address. This problem is discussed in section 14 below. If it is in the simple 4 to 8 character format, then it will follow the style below. In Europe it is a country code (1 or 2 characters) followed by some identifier which has often been allocated by a naming convention with one or two character fields for city/region, site, machine etc. Very rarely the country code is separated by a space from the rest. This space MUST NOT be inserted into the address. E.g. D B0ZIB21 should be used as DB0ZIB21 (the D means it's in Germany (Federal Republic)). An almost obsolete practice is for correspondents to refer to EARN as `country prefixEARN', e.g. DEARN or FREARN. In such cases one has to decide whether the country prefix has been prepended to the sitename, and prepend it if necessary. On BITNET/NETNORTH sites names are often more meaningful. They sometimes have dot BITNET appended to them; this can be left out, or prepended instead. The method is to mail: person%sitename@uk.ac.earn-relay or: person%earn.sitename@uk.ac.earn-relay or even: person%bitnet.sitename@uk.ac.earn-relay The use of EARN.sitename or BITNET.sitename is interchangeable, the network behaves as one network, with the different parts administered by different managements. So, should you wish, you could prefix a node name on EARN with `BITNET.', or a node on BITNET with `EARN.'. The relay also accepts the address given with EARN/BITNET appended to the sitename, thought it's safer to prepend it in case there is a clash between the address and the name of another domain. E.g. person%sitename.earn@uk.ac.earn-relay or: person%sitename.bitnet@uk.ac.earn-relay UK.AC.EARN-RELAY was once known as UK.AC.RL.EARN. The old name was deleted after a substantial overlap period. Local mailers may wish to make use of the above, so that if a user presents an address in the form person@earn.sitename (or person@bitnet.sitename) the mail is forwarded to UK.AC.EARN-RELAY. However, as mentioned in the introduction, the document assumes basic mailers. 3.1 Examples Address as given by remote correspondent who to mail user RZS01 at EARN RZS01%frsl003@uk.ac.earn-relay node FRSL003 PRJOHAN@DGOGWD01 PRJOHAN%dgogwd01@uk.ac.earn-relay SKLOD on DK BN07 SKLOD%dkbn07@uk.ac.earn-relay LEAR@HAMLET.BITNET LEAR%hamlet@uk.ac.earn-relay 3.2 Getting Mail Back The method is that the EARN/BITNET user mails: person@machine.place.ac.uk or less preferably: person%uk.ac.place.machine@UKACRL The first form is now much more widespread - sometime ago I had never found anywhere which could handle that form. (The remote site's tables and mail software have to know about the fact that UKACRL is a relay, known within EARN and BITNET as AC.UK, and many sites took a while to do this). The second form works at a number of sites which can not cope with the first form, but that still leaves some BITNET/EARN sites which run ancient mailers which can only cope with very simple addressing styles of the style: max-8-chars-user-id@max-8-chars-node-name A good standby for US correspondents is to advise them to use the Internet for reply, if they are allowed to do so. Many either know how to route mail via the Internet, or faced with a decrepit mailer could use another machine with access to the Internet. Some mailers would interpret an address of the first form as an Internet address anyway, so the mail would come back via UCL (see Internet section below). If you wish to force the mail to come back over the Atlantic on EARN/BITNET then quote your Internet address as: person%machine.place.ac.uk@cunyvm.cuny.edu If all the above fails, then you may need to advise the remote correspondent as follows: If none of these address forms work, you may have to consult your network manager. It should be explained to him/her that, to send mail via Earn/BitNet/NetNorth to JANET, the address in the envelope must be quite different from the address in the RFC-822 header. In particular, the mail envelope must specify MAILER@UKACRL as the intended recipient, whereas the RFC-822 header should contain (as the value of the `To: ' field), the address form outlined above. I.e. person@machine.place.ac.uk This file should be sent as a PUNCH file to user MAILER at EARN node UKACRL with class M. 3.3 Contacts and Further Information Information on the EARN gateway is held on the JANET NEWS machine (make an interactive call to UK.AC.JANET.NEWS). Further information on EARN can be gained by fetching an information file from the relay by mailing netserv@uk.ac.earn-relay with a line containing: GET JANET EARNGATE Other files worth GETting from NETSERV are: NETSERV FILELIST for a full list of files available NEWS SUMMARY for the latest news There is an EARN Usergroup discussion mailing list, EARNUS@UK.AC.RL. To join, apply to EARNUS-REQUEST@UK.AC.RL Problems with use of the EARN gateway are handled by User Support, US@UK.AC.RL.IB 3.4 Tried and Tested? Users throughout JANET have been sending mail to people on EARN, and getting replies back for sometime now. It works very well. The only problems seem to be with some ancient mailers at the other end which can not reply. EARN and BITNET are largely `store & forward' networks (not `point-to-point like JANET). So mail has to be temporarily stored on one intermediate nodes and forwarded on to the next. This can cause delays if an intermediate site suffers problems which cause a backlog. The effect is that the majority of the mail is moved very speedily, with an occasional long delay. 4. INTERNET (DARPA, ARPANET, NSFNET) UK.AC.NSFNET-RELAY is the official gateway to the Internet. (The machine is physically located at, and administered by, ULCC - The University of London Computer Centre.) The relay was previously known as UK.AC.UCL.CS.NSS, and major improvements have taken place in the last year. Mail to the Internet can also be sent via the EARN relay. Many users made use of the EARN route when there were restrictions on the use of UK.AC.UCL.CS.NSS, and more recently because of other problems like lack of domain routing and problems with the high speed link with the USA. It is now well worth using UK.AC.NSFNET-RELAY. The method works for obsoleted ARPA addresses, ending .arpa, and the current Internet ones which end: .edu, .com, .gov, .net, or .org. simply change the @ in the address to a % and mail to UK.AC.NSFNET-RELAY (or to UK.AC.EARN-RELAY for the EARN route). The old style of addresses (ending .arpa) are rapidly becoming defunct, and if you are still managing to use such an address, it is worth finding out the new style address before the old one fails to work. (See below for how to do this.) Although both UK.AC.NSFNET-RELAY and UK.AC.EARN-RELAY can handle the Internet address in either order. I.e. machine.place.domain or domain.place.machine, it is advisable to give it in the order domain.place.machine. Note this is the opposite order to how someone on the Internet would normally quote their address. But if the address given you already contains a `%' do not change the order of anything to the left of that `%'. 4.1 Routing Problem UK.AC.NSFNET-RELAY has moved from using one big table to look up an address, to one of `domain server systems' and `domain routing'. I.e. systems know where to send mail for a particular domain or sub-domain when they do not know the exact address of the particular site. The result of this is that many US sites don't now register individual machines on Internet; the tables were getting too big anyway. If the system you are trying to mail is on the Internet, the mail should find its way through. However, there are the occasional problems where mail will succeed one day and fail the next. This can be due to routers being unable to resolve an address quickly enough and so rejecting the mail. Such problems should become rarer since `domain routing' is now widely used on the Internet. The main problem with mail failure on the Internet, is that the address is not actually on the Internet. This is due to what I call the `domain problem' in section 14. 4.2 Examples The first example shows a number of the alternatives mentioned. In the case of the remainder, just one address is shown - it's the one that is probably the most certain to work. Address as given by remote correspondent who to mail MJONES@uxyvax.arpa MJONES%arpa.uxyvax@uk.ac.nsfnet-relay or MJONES%arpa.uxyvax@uk.ac.earn-relay DBROWN@hp1.hplabs.com DBROWN%com.hplabs.hp1@uk.ac.nsfnet-relay Mary@isten.hous.edu Mary%edu.hous.isten@uk.ac.nsfnet-relay tbgc%vrg.uxy@gate.uxy.edu tbgc%vrg.uxy%edu.uxy.gate@uk.ac.nsfnet-relay 4.3 Getting Mail Back This is reasonable easy; quote your address as: person@machine.place.ac.uk sophisticated mailers at the other end may choose to route mail back either via EARN/BITNET or Internet, depending on their preference. Due to `domain routing', the vast majority of Internet sites of cope with this. However, for the few which can't, it's worth giving your explicit Internet address as: person%machine.place.ac.uk@nsfnet-relay.ac.uk I think all Internet sites should be able to handle that, but in case of desperation it may be worth keeping a further form up your sleeve if all else fails: person%machine.place.ac.uk@cunyvm.cuny.edu This would cause the mail to come back via EARN/BITNET. 4.4 Contacts and Further Information Full details of the UK.AC.NSFNET-RELAY gateway are held on by its `info-server'. Send some mail to info-server@uk.ac.nsfnet-relay containing: Request: userguide Topic: index Request: end And you should get some mail back telling you of the documents which can be collected by the same mechanism, replacing the word `index' with the file you wish to grab. For further details of how to use this info-server, just send an empty message to it (or, if your mailer refuses to send an empty message, send something the info-server won't recognize, e.g. `boo!'). To find the details of a site on the Internet, send some mail to: service%arpa.sri-nic@uk.ac.nsfnet-relay with either the `Subject:' field or the text of the message: whois some-keyword The gateway contact at ULCC is: Liaison@uk.ac.nsfnet-relay, but if you are going via EARN/BITNET, the contacts for EARN above may be more appropriate. 4.5 Tried and Tested? Vast amounts of mail to the Internet are handled by UK.AC.NSFNET-RELAY. In addition UK.AC.EARN-RELAY still handles a lot of traffic to the Internet. The great majority of Internet users are able to reply without problem. 5. UUCP UUCP is the general name given to a network of mostly Unix computers. There are different names for it in different parts of the World. In North America it's often known as Usenet, in Europe as Eunet, and in the UK as UKnet. It is largely a store-and-forward network, where a mail item is passed from machine to machine, often using dial-up lines. Older uucp address tend to be sprinkled with exclamation marks, as they specify the route, left to right. Strictly speaking then you needed to know the route, but the `backbone' sites knew the route to other backbone sites, and so you just needed to specify the route from a backbone site such as ukc or cwi.nl (previously mcvax), in Europe, or seismo, (now effectively replaced by uunet.uu.net), in the USA. These days almost all uucp sites are registered in the uucp `world maps' - lists of which sites are connected to which. If a site is in the maps you can simply refer to it as `site.uucp' (Rest-of-the-World) or `uucp.site' (UK). If your machine recognizes `uucp' as a partial domain (i.e. it can route such an address to an appropriate gateway without you needing to specify the gateway) then hopefully that is all you need to know - simply use person@uucp.site. But note that this will only work if that site is in the uucp maps, see below. You can also, it seems, address sites which are not in the maps but whose connection to a mapped machine you know - see the gateway specific information below. You can check if a `.uucp' style name is in the uucp maps by sending a message to `netdir@uk.ac.ukc' with a subject line containing the name of the machine (without the `.uucp'). A message containing the map entry for that machine is returned if it exists, or an error message if it doesn't. Note that this only applies for place.uucp. Netdir will not return information about domains it recognises and will successfully route the mail to. The system cwi.nl (in Amsterdam) previously had the name mcvax. (Well its a completely different machine if you want to be pedantic.) In place of seismo, formerly a major US backbone site, use instead uunet.uu.net which has taken over most of seismo's traffic. 5.1 Sending via UKC It is possible to send mail to uucp sites via UKC. However, one needs to register the SITE with UKC to do this, agreeing to meet the bills incurred, as a site. The bills are usually very low, unless a lot of transatlantic traffic is involved. The cost is highest for transatlantic mail, much lower for European mail, and zero for UK mail. Practically we've [Warwick] found it best to subscribe, since the traffic is very low, even though we currently place no restriction upon access to it. Sites with the mail software to cope with charging may pass on the costs to the department or user incurring the bills. If a site is in the maps you can probably send mail to person%uucp.site@UK.AC.UKC (It may well work without the ``uucp.'', but it does no harm to make your intentions clear.) UKC will also accept translations of !-strings in standard relayed form `person%site1@uucp.site2' or `person%site1%uucp.site2@uk.ac.ukc' - each of these is equivalent to `...site2!site1!person' where the `...' means `whatever is connected to site2'. If you really must use `!'s then you can include them in the user's name section of the address enclosing it in double quotes to protect it from your mail system (it's not strictly legal without the quotes, though some mailers will cope with it). Double quotes can cause problems to some systems the mail is sent from, see section 11.5 Thus you could address: ...site2!site1!person as "site2!site1!person"@uk.ac.ukc 5.1.1 Examples Assume that mondib, tiped and ucyvax have been checked out against netdir@uk.ac.ukc Address as given by remote correspondent who to mail ...seismo!lll-crg!mondib!jones try jones%uucp.mondib@uk.ac.ukc or jones%mondib%uucp.lll-crg@uk.ac.ukc or even jones%mondib%lll-crg%net.uu.uunet@uk.ac.ukc ...mcvax!seismo!tiped!martin martin%uucp.tiped@uk.ac.ukc ...{ihnp4 seismo}!ucyvax!mary mary@uucp.ucyvax@uk.ac.ukc ...ihnp4!gateck!dcbtla!jeh Now let's assume that dcbtla doesn't check out against the directory (netdir@uk.ac.ukc), so we can't use jeh%uucp.dcbtla@uk.ac.ukc. However, gateck checks out as OK, so it's: jeh%dcbtla%uucp.gateck@uk.ac.ukc 5.1.2 Contacts Contact point for the UKC UUCP Gateway is: uknet@uk.ac.ukc 5.2 Sending Via EARN The EARN node at Rutherford recognizes the domain `uucp', and passes the mail to a gateway site in the USA. This in turn knows about the uucp world maps. If the address is given as: person@site or person@site.uucp then use person%uucp.site@uk.ac.earn-relay If the address is given as a !-style address (...site1!site2!final-site!user) pick out the final site, and send the mail to: user%UUCP.final-site@UK.AC.EARN-RELAY If final-site is not in the uucp maps (send mail to netdir@uk.ac.ukc to check - see above) then you can try either of user%final-site%UUCP.site2@UK.AC.EARN-RELAY or if you really must: final-site!user%uucp.site2@uk.ac.earn-relay If you do have to use this sort of address, try to avoid multiple trips across the Atlantic. This means knowing where the sites in the route are. Mail routed as UUCP.site@UK.AC.EARN-RELAY will get routed via an EARN (BITNET) UUCP gateway in the USA. If you know the uucp site you are mailing to is in Europe, you can specify a more efficient route by user%site.uucp%gateway@uk.ac.earn-relay Where gateway is one of: mcvax The EARN name for cwi.nl in the Netherlands unido In Germany ariadne In Greece Here are the examples from above, but this time routed via EARN and making the same assumptions about checks against netdir@uk.ac.ukc. There is an additional example where we assume itacen is a valid, European, uucp site. 5.2.1 Examples Address as given by remote correspondent who to mail ...seismo!lll-crg!mondib!jones jones%uucp.mondib@uk.ac.earn-relay ...mcvax!seismo!tiped!martin martin%uucp.tiped@uk.ac.earn-relay ...{ihnp4 seismo}!ucyvax!mary mary%uucp.ucyvax@uk.ac.earn-relay ...ihnp4!gateck!dcbtla!jeh jeh%dcbtla%uucp.gateck@uk.ac.earn-relay ...mcvax!itacen!chris chris%itacen.uucp%mcvax@uk.ac.earn-relay or chris%uucp.itacen@uk.ac.earn-relay 5.2.2 Contacts Contacts would be the usual EARN gateway ones (see above) 5.3 Sending Via the Internet Site uunet.uu.net is on both the Internet and the uucp network, so it could be used as an alternative route. uunet.uu.net knows about the uucp world maps, so if the address is given as: person@site or person@site.uucp then use person%site.uucp%net.uu.uunet@uk.ac.nsfnet-relay If the address is given as a !-style address (...site1!site2!final-site!user) pick out the final site, and send the mail to: user%final-site.uucp%net.uu.uunet@uk.ac.nsfnet-relay If final-site is not in the uucp maps (send mail to netdir@uk.ac.ukc to check - see above) then you can try either of user%final-site%site2.uucp%net.uu.uunet@uk.ac.nsfnet- relay or if you really must: final-site!user%site2.uucp%net.uu.uunet@uk.ac.nsfnet- relay If you do have to use this sort of address please note that backbone sites ukc, cwi.nl (mcvax), unido and ariadne are in Europe, and the gateway is in the USA, so don't put these in your path if the mail is going to the USA. Here are the examples from above, but this time routed via the Internet and uunet.uu.net and making the same assumptions about checks against netdir@uk.ac.ukc 5.3.1 Examples Address as given by remote correspondent who to mail ...seismo!lll-crg!mondib!jones jones%mondib.uucp%net.uu.uunet@uk.ac.nsfnet-relay ...mcvax!seismo!tiped!martin martin%tiped.uucp%net.uu.uunet@uk.ac.nsfnet-relay ...{ihnp4 seismo}!ucyvax!mary mary%ucyvax.uucp%net.uu.uunet@uk.ac.nsfnet-relay ...ihnp4!gateck!dcbtla!jeh jeh%dcbtla%gateck.uucp%net.uu.uunet@uk.ac.nsfnet-relay 5.3.2 Contacts Contacts would be the usual Internet gateway ones (see above) 5.4 Getting mail back With the spread of domainised addressing most uucp sites should now be able to send mail directly to JANET sites using the standard Rest-of- the-World form: person@machine.place.ac.uk This will direct the mail by whatever route the system prefers, possibly via UKC or perhaps via the Internet or EARN/BITNET (see separate sections). If your site subscribes to UKC for use of uucp mail, then you have no worries. However, if that route is unavailable to you, then you need to make sure that the mail does not come back via UKC, as it will be discarded there. So either give an Internet address as mentioned above in the Internet section e.g.: person%machine.place.ac.uk@nsfnet-relay.ac.uk Machines which can still only use !-style addressing will probably have to route explicitly via UKC. ...!ukc!machine.place.ac.uk!person However, that's no good if your site doesn't subscribe to UUCP use at UKC. In which case you could always try: ...!psuvax1!cunyvm.bitnet!machine.place.ac.uk!person 5.5 Tried and Tested? Much of the new text in this section was originally supplied by Edinburgh, and has been updated to reflect the change of access to the Internet. Both Edinburgh and Warwick make a lot of use of UUCP and normally route via UKC which is a reliable UUCP backbone site returning helpful error messages when it has been unable to relay the mail. If a failure occurs at some remote UUCP site, then return of error messages is less reliable. Although mail sent to US UUCP sites via EARN can be fast, the success rate is not as high as via UKC. Possibly this is as a result of case translation (see section 11.1 below). The Internet route to US UUCP sites is probably well worth trying, but I have not had many reports of its performance as yet. Since both Edinburgh and Warwick subscribe to UKC, little is known about the success of the return routes which avoid UKC. 6. CSNET Phonenet CSNET is not really a network as such, but a logical network which makes use of a number of real networks. As mail between these real networks is becoming easier to achieve, the use of CSNET as a logical network is going out of use, and sites in this CSNET are moving over to addresses in whichever real network they are in. If you are faced with an address which contains the domain `csnet', then the best thing to do with it is to route it via Internet address relay.cs.net. E.g. user%somewhere.csnet%net.cs.relay@uk.ac.nsfnet-relay or user%somewhere.csnet%net.cs.relay@uk.ac.earn-relay 6.1 Example Address as given by remote correspondent who to mail DBROWN@zodnap.csnet DBROWN%zodnap.csnet%net.cs.relay@uk.ac.nsfnet-relay or DBROWN%zodnap.csnet%net.cs.relay@uk.ac.earn-relay 6.2 Getting Mail Back As much mail to CSNET goes via Internet, then the standard way of quoting your address internationally is best, as most Internet sites will handle this. I.e. person@machine.place.ac.uk If the CSNET machine can't handle this, it may be that the only Internet site it knows is the CSNET/Internet gateway, and so it will need: person%machine.place.ac.uk%nsfnet- relay%ac.uk@relay.cs.net 6.3 Contacts The CSNET general postmaster's Internet address is: cic@sh.cs.net and can therefore be reached by mailing cic%net.cs.sh@uk.ac.nsfnet-relay 6.4 Tried and Tested? As mentioned above, specific CSNET addresses are being replaced by addresses on the real network the site actual resides on, so the information above may become out of date. It is based on experience at Aston, Edinburgh and Kings College London. 7. EAN and X.400 MHS RELAYS EAN is a project involving the connection of sites which have been using an early `intercept' of the X.400 protocols. The main gateway to EAN is called UK.AC.EAN-RELAY, or UK.AC.EAN for short, and is sited at the University of London Computer Centre (ULCC). It was originally sited at UCL. ULCC also operate another gateway to X.400 mail, this service was also at UCL and has only recently moved to ULCC. It is called UK.AC.MHS-RELAY. Previously UK.AC.UCL.CS handled this service. 7.1 EAN In EAN the names of the participating sites are often in the dot separated form used by many other networks, and use the ordering machine.place.domain (where domain is often a country code). Within the UK the ordering domain.place.machine is used. Below is a list of domains that EAN-RELAY currently handles. These overlap with domains handled by other gateways on JANET, as described in section 14, the `domain problem'. So to help immediately exclude sub-domains which are not handled by EAN-RELAY, if all sites reachable via EAN-RELAY fall in the same sub-domain, then that sub-domain is given below (domain.place.machine order). However, the description on the right is normally that of the whole domain, not just the sub-domain. If a domain name is marked as `now extinct', don't use it. For those that are marked `former name', or `will be replacing', either name is allowable for an overlap period. domain or sub-domain Description at.ptt Austria au.mu.munnari University of Melbourne, Australia be.rtt.fundp.info Belgium research network br.ebt.rnp.unicamp Brazil ca will be replacing `cdn' cdn CDNnet, Canada cern European Organization for Nuclear Research, Geneva ch Swiss University Network, Switzerland de.dpb Deutsche Forshungsnetz, Germany dfn now extinct - replaced by `de.dpb' dk Danish University Network, Denmark dunet former name for `dk' es.iris-dcp Spanish Research Network fi will be replacing `funet' funet Finnish University Network hasler.kom.vax2 HASLER AG, Bern, Switzerland ie.ucd Irish Research Network (but see section 9.5) iris now extinct - replaced by `es' irl former name for `ie' isanet.hi.rhi Icelandic University Network kr Korean Research Network nz New Zealand (Grey Book - but see section 9.3) osiride.cnr.iasi Italian Research Network oz Autralian Computer Science Network pt.ctt.inesc Portuguese Research Network riup former name for `pt' se Swedish University Network surf.kun Dutch Research Network, Netherlands uninett Norwegian University Network yu.jumail Yugoslavia For information on how to obtain a fuller list, see below. The gateway accepts the addresses in either the UK style ordering, shown above, or its inverse; though UK style ordering is recommended. Note that the relay won't necessarily handle all addresses in the domains shown, only those in the ean.sites list mentioned below. 7.1.1 Examples Address as given by remote correspondent who to mail glp@lge.ethz.ch glp%ch.ethz.lge@uk.ac.ean-relay or glp%lge.ethz.ch@uk.ac.ean-relay (the other address below may also be given in this form) S1DM@instr.camosun.bcc.cdn S1DM%cdn.bcc.camosun.instr@uk.ac.ean-relay 7.1.2 Getting Mail Back EAN sites are built around the idea of handling different mail systems, so there should be no problems getting the mail back. The official thing to do is just quote your standard NRS format, but invert the components to save upsetting those who haven't come across the UK ordering before! I.e. person@machine.place.ac.uk 7.1.3 Contacts and Information Information on the EAN gateway is held on the JANET NEWS machine (make an interactive call to UK.AC.JANET.NEWS). For further information, five documents are available from UK.AC.EAN-RELAY These are: ean.usage full details how to use the relay. ean.sites the list of sites handled. ean.sites.raw the site list without explanatory text. oz.sites a list of sites on ACSNET reachable via EAN. ean.news the latest news All are available doing an NIFTP to UK.AC.EAN-RELAY giving the name of the document as the FILENAME, guest as the USERNAME and your mail address as the PASSWORD. The documents may also be fetched using mail: send mail to information@uk.ac.ean-relay with the `Subject:' field the name of the file, without the initial `'. The contact for help and advice is: liaison@uk.ac.ean-relay 7.1.4 Tried and Tested As long as you are attempting to mail a site which is mentioned in ean.sites there is every chance of success. Beware of addresses which at first site look as though one of these relays can handle it (because the top domain is one handled by one of these relays), though closer inspection will reveal that the address is not in ean.sites. This is the `domain problem', discussed in section 14. 7.2 X.400 MHS-RELAY The transfer of the function of relaying X.400 mail was underway, but not fully complete as I finished this document on 23 March 1990. Previously handled by UK.AC.UCL.CS, the service is now to be provided by UK.AC.MHS-RELAY. If you make use of this document very shortly after its issue date, you may have to use UK.AC.UCL.CS for a week or two instead. The domains handled by the X.400 gateway at UK.AC.MHS-RELAY are: domain or sub-domain Description fr French Research Network gb United Kingdom, comprising: gb.gold-400.hp.hpl Hewlett Packard gb.btmhs.icl.icl.poda ICL gb.gold-400.hmg gb.gold-400.mitsy IDEM gb.btmhs.itl.itl ITL gb.gold-400.rml.nsd Racal de.dbp.nixdorf.nme de.dbp.siemens-ag.ap11 Deutsche Forshungsnetz, F.R. Germany Again, information on how to obtain a fuller list is given below. In addition the mail can be sent to UK.AC.EAN-RELAY, which will re-route it to UK.AC.MHS-RELAY. Though this is not really recommended due to the inefficiency involved. The gateway accepts the addresses in either the UK style ordering, shown above, or its inverse; though UK style ordering is recommended. 7.2.1 Examples Address as given by remote correspondent who to mail TEST1@gb.gold-400.hmg.mi5 TEST1%gb.gold-400.hmg.mi5@uk.ac.mhs-relay jaques@emu.gipsi.aristote.fr jaques%fr.aristote.gipsi.emu@uk.ac.mhs-relay 7.2.2 Gold-400 and Wider X.400 mailing Beware the information in this section is not documented in the advertised files available from UK.AC.UCL.CS, so is not as reliable as the information above. The list of places one can mail on Gold-400 is wider than given in the x400.sites list mentioned below. For example mail to: gb.gold-400.digital works (and I've also seen it used as gb.gold- 400.digital.digital). Here the person is identified by given name, dot, surname. E.g. joe.bloggs%gb.gold-400.digital@uk.ac.mhs-relay Other site not in x400.sites, but apparently accessible are: gb.gold-400.btrl.btrl gb.gold-400.dtied.ied.ied1 In addition it is possible to mail a wider set of X.400 sites by following the information below. X.400 address formats are different from those used on JANET and it is important to find out the exact address parameters to be used. X.400 address fields are: Given name (givenname - not normally used) Initials (inits) Surname (surname) Organisation unit (orgunit) Organisation (org) Private management domain (prmd) Administrative domain (admd) Country (country) It is more usual to use Initials and Surname to identify a person, though there are some instances of Given name and Surname, but don't use both Given name and Initials. Construct a localpart to be either inits.surname or occasionally givenname.surname. All fields from country to organisation must be known but it is generally not required to know the organisation unit, unless there is likely to be confusion between names within the organisation. The address to mail to is then localpart%country.admd.prmd.org.orgunit@uk.ac.mhs-relay where .orgunit is omitted if organisation is not required. An alternative, and more complex form, handled by UK.AC.MHS-RELAY is where the X.400 attributes of what it calls the `MTS.ORAddress' are identfied by a key, this is followed by by an `=', then the value of that attribute. Each key=value pair being separated by a `/'. This yields addresses such as: /PN=Jean.Blanc/O=cie/PRMD=inria/ADMD=atlas/C=fr/ The latest proposals for these forms of address are described in detail in RFC 1138 by Steve Kille of UCL. Key=value pairs can be sent to UK.AC.MHS-RELAY in two forms. One is just as given, though one would normallly enclose it in double quotes, or mailers may object to its illegality as a mailbox name. Double quotes can cause problems to some systems the mail is sent from, see section 11.5 E.g. "/PN=Jean.Blanc/O=cie/PRMD=inria/ADMD=atlas/C=fr/"@uk.ac.mhs- relay Another way is to extract the personal name components as a localpart to use as the user, use the remainder as an address to be relayed via UK.AC.MHS-RELAY E.g. Jean.Blanc%"/O=cie/PRMD=inria/ADMD=atlas/C=fr/"@uk.ac.mhs- relay The most common use of this form would be if one receives mail apparently from an address in this format. Constructing one by hand could be difficult. However, for those determined to try it, the following attributes are common and are identified by the key shown Attribute Key CountryName C AdministrationDomainName ADMD PrivateDomainName PRMD OrganizationName OU OrganizationalUnitNames.value O PersonalName PN PersonalName.surname S PersonalName.given-name G PersonalName.initials I 7.2.3 Getting Mail Back The simplest thing to do is just quote your standard NRS format, but invert the components to save upsetting those who haven't come across the UK ordering before! I.e. person@machine.place.ac.uk If the remote correspondent is in an X.400 environment, then your address in an X.400 style may be of use. For person@uk.ac.place.machine this is best quoted as: country GB admd GOLD 400 prmd UK.AC org site orgunit machine (if required) personal name person E.g. T.Clark@uk.ac.warwick is: country GB admd GOLD 400 prmd UK.AC org warwick personal name T.Clark whilst es412@uk.ac.camford.eng.mat is country GB admd GOLD 400 prmd UK.AC org camford orgunit eng.mat personal name es412 7.2.4 Contacts and Information The following documents were available from UK.AC.UCL.CS: x400.usage full details how to use the relay. x400.sites the list of sites handled. They were obtained by doing an NIFTP to UK.AC.UCL.CS giving the name of the document as the FILENAME, guest as the USERNAME and your mail address as the PASSWORD. These files were very much out of date in March 90. UK.AC.MHS-RELAY will be taking over, but no details are available yet on how to get information from it. It will probably be similar to UK.AC.EAN (see section 7.1.3 above). Steve Kille's RFC 1138 on `Mapping Between X.400(1988) / ISO 10021 and RFC 822' can be obtained by sending mail to info-server@UK.AC.UCL.CS containing the message: request: rfc topic: rfc1138 request: end For help and advice the contact is liaison@uk.ac.mhs-relay 7.2.5 Tried and Tested As long as you are attempting to mail a site which is mentioned in x400.sites, there is every chance of success. If you are trying something more, perhaps following the advice in 7.2.2 above, then things are not so predicatble. One thing to beware of is that if the connection fails from Gold-400 to the distant end you will get a message back saying, ``Unrecognised ORname'' (i.e. unknown organisation) rather than saying there is a fault. This appears to be a bug within Gold-400 and is decidedly unhelpful until you learn to recognise it. 8. JUNET (JAPAN) JUNET have a domain name of `jp', `jpn', or `junet'. JUNET is moving over to a secondary domain similar to that used within JANET, and a top-level domain of `jp'. These are: .ac.jp%universities .co.jp%commercial organisations .go.jp%governmental institutes .or.jp%other organisations Users on JUNET who are registered to receive mail through CSNET may be reached by routing the mail through relay.cs.net (encountered in the CSNET information above). Previously the domain name `junet' had to be used, though now relay.cs.net knows the domain name `jp' too. E.g. sui%kddlab.kddlabs.junet%net.cs.relay@uk.ac.nsfnet- relay sui%kddlab.co.jp%net.cs.relay@uk.ac.nsfnet-relay Note that messages from/to CSNET have been charged to the JUNET users since Oct. 1, 1987 and so only mail to users registered to receive it via this route will work. If a JUNET user wishes to use the CSNET-JUNET link, he/she has to send an application to the VAX8600 machine (tansei.cc.u-tokyo.junet) in the office of the Computer Centre, University of Tokyo, get the account on the machine, then execute the `csnet' command or generate a message to csnet-account@u-tokyo.junet in order to register the addresses using the account. The general method though is to treat JUNET addresses in the same way as UUCP addresses and send them via UK.AC.UKC, which knows about all three forms of the domain name (jp, jpn and junet). See section 5 above. Kyoto University is on BITNET, and now uses addresses of the form machine.kyoto-u.ac.jp, so any addresses of this form are best handled by the EARN-RELAY. If your site doesn't subscribe to UKC, and the JUNET user doesn't subscribe to CSNET, then things get a little tricky. The EARN route to mcvax, and the Internet route to uunet.uu.net would seem worth trying. However, mcvax doesn't know about the domains `jp' and `jpn'. On the other hand, EARN-RELAY knows about `jp', so that's worth a try, especially if the address ends `.ac.jp'. I suspect mail can find its way via UK.AC.NSFNET-RELAY, without the need for mentioning another relay. However, as this may take the route via net.cs.relay, (for which the recipient needs to be registered) this is probably best avoided. 8.1 Examples Address as given by remote correspondent who to mail kimio@aoba.tohoki.junet kimio%junet.tohoki.aoba@uk.ac.ukc or kimio%aoba.tohoki.junet%net.uu.uunet@uk.ac.nsfnet-relay suo@titcca.cc.titeck.jpn suo%titcca.cc.titeck.jpn@uk.ac.ukc or suo%titcca.cc.titeck.jpn%net.uu.uunet@uk.ac.nsfnet-relay li@tokyo.ac.jp li%jp.ac.tokyo@uk.ac.ukc or li%tokyo.ac.jp%net.uu.uunet@uk.ac.nsfnet-relay or li%jp.ac.tokyo@uk.ac.earn-relay 8.2 Getting Mail back The best way to quote your address is in the person@machine.place.ac.uk format, though the correspondent in Japan will probably have to use something like: person%machine.place.ac.uk@bitnet-relay 8.3 Tried and Tested The route out via either UKC or relay.cs.net (for those sites in CSNET) is reliable. The route via uunet.uu.net is questionable. The information about the BITNET link is the newest, and therefore untried. 8.4 Contact There is a network administrator who may be reached as junet-admin%junet%net.cs.relay@uk.ac.nsfnet-relay The CSNET-JUNET gateway administration office is csnet-admin%u-tokyo.junet%net.cs.relay@uk.ac.nsfnet- relay 9. MISCELLANEOUS OTHER NETWORKS 9.1 MAILNET A long dead network which lingers in name only. EARN-RELAY gateway knows about this, so route it via there. Most MAILNET sites are now on BITNET or Internet, so make sure the remote correspondent knows your EARN/BITNET return address or your Internet return address (See Internet and EARN/BITNET sections above). E.g. sue%mailnet.osye@uk.ac.earn-relay 9.2 INFNET or IT.INFN - ITALY This has undergone a few changes. A number of sites used to be linked directly into EARN and so could be handled as described in section 3. There is a migration to the form of address site.infn.it. Where possible it is best to find the new name and make use of it as described below. There was an intermediate stage where sites were reached via EARN and known as site.infnet. If you have such an address, replace the infnet by infn.it. Once you have an address ending `.infn.it', then EARN-RELAY will cope with it as follows. Use: userid%it.infn.site@uk.ac.earn-relay For reply, quote your EARN reply address. 9.3 TUAI - NEW ZEALAND Some sites in New Zealand run Grey Book mail and are contactable via PSS. If the site's PSS address is registered, in NIFTP-MAIL context in the NRS, then it is possible to route the mail via UK.AC.EAN-RELAY, which handles Grey Book mail between the UK and New Zealand. The addresses concerned are mostly `nz.ac.' with a few `nz.govt'. E.g. psyabcd%nz.ac.otago@uk.ac.ean-relay However, there is a move away from Grey Book to Internet protocols, and the best route for reaching sites in New Zealand is now via the Internet. E.g. psyabcd%nz.ac.otago@uk.ac.nsfnet-relay Previously recommended routes via Munnari (at the University of Melbourne in Australia) and via relay.cs.net are not likely to work where the Internet route fails. 9.4 ACSNET and CSIRONET - AUSTRALIA The Australian Computer Science Network, which relies in part on the government funded CSIRONET. The gateway machine, Munnari at Melbourne University is an EAN participant, and is addressed as munnari.mu.au. The rest have names ending either just, `.oz' or `.oz.au'. If it does end `.oz.au', then you may need to strip off the `.au' then route it via EAN-RELAY (see section 7 above). That relay knows to route the mail via Munnari. It may be worth checking that the site is in the file oz.sites mentioned in that section. Although `.oz' is strictly a sub-domain of `.au', there used to be a problem adding the missing `.au'; I'm not sure if it's fixed yet. So it's best not to use `.au' after `.oz' in an address. Address as given by remote correspondent who to mail bsm@cascade.trl.oz.au bsm%oz.trl.cascade@uk.ac.ean-relay jtbg@ditmelb.oz jtbg%oz.ditmelb@uk.ac.ean-relay The same sites can also be reached via UKC and NSFNET-RELAY, though there seems little point in sending the mail that way. Some sites on ACSNET and CSIRONET can also be reached by Grey Book mail over the Public Packet Switch Data Network (PSS in the UK) directly; see section 10 below. Mail coming back to the UK is best routed via munnari.mu.au, I.e. person%machine.place.ac.uk@munnari.mu.au 9.5 HEANET - EIRE The Irish national academic network. Addresses used to look like: person@irl.hean.place.machine but now are more commonly specified as: person@machine.place.ie If the address is in the older format, convert it to the newer, and route via the EARN-RELAY. Address as given by remote correspondent who to mail leary@vax1.rcd.ie leary%ie.rcd.vax1@uk.ac.earn-relay sean@irl.hean.ucc.cms ie.ucc.cms@uk.ac.earn-relay A list of sites is held on UK.AC.JANET.NEWS in HEANET. For replies just quote your JANET address in the order: person@machine.place.ac.uk Although some machines at University College Dublin (ucd.ie) appear in the EAN list, this is little used, and the use of the EARN-RELAY is recommended instead. Uucp is also used as a means of connection to Eire, but I don't know if that can reach places which EARN-RELAY can't. As a desparate last measure consider: person%machine.place.ie@uk.ac.ukc 9.6 SDN - KOREA This is a network in South Korea. The domain name is `kr', and mail should be routed as for either UUCP or CSNET addresses. Note that some sites with the domain `kr' are reached via the EAN-RELAY (see section 7). 9.7 SPAN - SPACE PHYSICS The Space Physics Analysis Network. The domain name is `.SPAN' and there is now a relay in the UK, called UK.AC.SPAN-RELAY, which handles this traffic. SPAN users usually identify themselves by node and user. To send to such a person, use: "node::user"@UK.AC.SPAN-RELAY Double quotes can cause problems to some systems the mail is sent from, see section 11.5 The following routes are now hopefully redundant: user%node.SPAN%edu.stanford.star@uk.ac.nsfnet-relay user%node.SPAN%gov.nasa.jpl.vlsi@uk.ac.nsfnet-relay user%node.SPAN%gov.nasa.arc.ames@uk.ac.nsfnet-relay user%node.SPAN%bitnet.sdsc@uk.ac.earn-relay person%gov.nasa.span.site%uk.ac.nsfnet-relay To get a reply to someone on JANET the SPAN user should send the mail to RLESIS::CBS%uk.ac.site.machine::person For further information contact Postmaster@UK.AC.SPAN-RELAY 9.8 Easynet - DEC This is DEC's internal network. Addresses tend to be of the form host::user But beware, just because you see an address in this form don't assume it's on Easynet - the same format is used on numerous other Decnets. `Decnet' is not a single network, it is the name of a proprietary protocol for linking together DEC machines. Provided the host is on Easynet, route the mail as follows: user%host.dec%com.dec.decwrl@uk.ac.nsfnet-relay If you are mailing to someone in DEC UK, it's better to make use of X.400, see section 7.2. Give your Internet address as the reply address. 9.9 Xerox Grapevine Also known as the Xerox RIN (Research INternet). Addresses on this network are given as: person.registry and the mail should be routed as follows: person.registry%com.xerox@uk.ac.nsfnet-relay Give your Internet address as the reply address. 9.10 VNET - IBM This is IBM's internal network. It is not possible to mail users on VNET hosts in general. You can only send mail to IBM VNET users who are registered to receive external mail - they will have a unique username on VNET, which is linked EARN/BITNET. Send the mail to: username%vnet@uk.ac.earn-relay 9.11 HARNET - HONG KONG This is the Hong Kong part of the UUCP network. However, only the gateway machine, hkucs, is in the UUCP site maps. Therefore to reach other machines on this network such as: cpccvx, hkucc, hkueee, encvax, hkpv07, cucsc, bc750, hkpv03, hkpv06, hkpv08, cucsd, cuele, bc785a, bc785b route the call via hkucs.uucp. I.e.: person%site%hkucs.uucp@uk.ac.ukc or person%site%hkucs.uucp%net.uu.uunet@uk.ac.nsfnet-relay 9.12 CANET - CHINA A network gatewayed via the University of Kalsrhue in West Germany and thence to Beijing. In general you should be able to reach a user in China using the address: user%beijing%ira.uka.de%net.cs.relay@uk.ac.nsfnet-relay or perhaps: user%beijing%de.uka.ira@uk.ac.earn-relay There are more than 30 member institutions of CANET. several institutions use a personal computer and a modem to login on an account at the host Beijing to read and post mail. That is why the site is not identified in the address. The following points have been made: Please don't send tons of information to China. The link is slow and both ends pay dearly for each byte. Please avoid sending political statements. This could do more harm than use. The postmaster at Beijing is called `mail' not `postmaster'. CANET is not related to the CHINANET-BITNET project (of which I have no information apart from this sentence). 9.13 BT Telecom Gold and Gold-400 British Telecom have been completely unable to link their Gold `network' into electronic mail in general. Gold is not in reality a network at all, but a collection of machines on which users are given an account. They then have to connect to that machine to send and receive mail. Although mail can be passed amongst the individual machines, and to some others running the same sort of system, Gold provides no interface to the electronic mail network. Fortunately there is a means of making contact though. Work was underway at British Telecom to connect Gold into the electronic mail network by means of X.400. However, they appear to have admitted defeat and the service is split between Gold and Gold-400. Most Telecom Gold users are on the former. The Gold 400 service is based on X.400 and accessible via UK.AC.MHS-RELAY. This is described in section 7 above. 9.13.1 Telecom Gold All is not lost for those trying to mail people on plain `Gold'. Accounts on Gold are composed of two important components. The first two digits form the system number. This is the identity of the machine the user's account is held on, values seem to be in the range 72 to 84 inclusive. The remainder is the account, and consists of three letters then three or four digits. E.g. 83LLX1062 Due to work by the Commercial Mail relay Project (CMR) at USC's Information Sciences Institute in the USA, (see section 9.15), there is a route to Gold. The class of service which Gold fits into is called `DIALCOM' by CMR. On this system users are identfied by a domain number (one to three digits), which for Gold (and a couple of others) is 100. This is then followed by a two digit system number, for which CMR say Gold has the range 01,04,17,80-89. This is followed by a colon and then the account number. Don't despair if you are faced with a system number outside the range given by CMR; it does work for others, e.g. 79. For the above Gold example of 83LLX1062, this translates to a CMR DIALCOM address of: 10083:LLX1062 There are then two possible starting points for experiment. The first is simply to try: "domain system:account"%telemail%isi.edu@uk.ac.nsfnet- relay E.g. for account 83LLX1062 one might try: "10083:LLX1062"%telemail%edu.isi@uk.ac.nsfnet-relay Double quotes can cause problems to some systems the mail is sent from, see section 11.5 Tests with addresses such as those have not yet worked, however there is an alternative, though more messy way, which does work. That is to send some mail to: intermail%edu.isi.intermail@uk.ac.nsfnet-relay with the first two lines of the body of the mail (i.e. the text of the message itself, not the header) containing: Forward: COMPMAIL To: domain system:account E.g. Forward: COMPMAIL To: 10083:LLX1062 9.14 TTNS - The Times Network for Schools This uses Telecom Gold, and so the method described in 9.13.1 above should work. I believe it uses the system number 01. 9.15 Commercial Mail Relay - Intermail In 1988, the Commercial Mail Relay (CMR) was developed at the USC Information Sciences Institute to run on a dedicated UNIX system, replacing the TOPS-20 based Intermail system. The Commercial Mail Relay service currently provides mail relay service between the Internet and three commercial electronic mail systems: US Sprint/Telenet, MCI-Mail, and DIALCOM systems (IEEECompmail, NSFMAIL, and USDA-MAIL). Once a person is a user of one of these systems they may exchange electronic mail with users on the Internet via the Commercial Mail Relay service. The only requirement for using this mail gateway is that the work conducted must be DARPA sponsored research and other approved government business. While CMR has the technical capability to interconnect any two mail systems, their policy requires at least one end of the communication to be DARPA related. They cannot allow DARPA facilities to be used simply as a bridge between two commercial systems. 9.15.1 Direct Addressing In order for a message to be delivered from ARPA-Mail to a mailbox on a Telemail system you simply type the Telemail mailbox in the ARPA- Internet header. I.e. user-mailbox%TELEMAIL%edu.isi@uk.ac.nsfnet-relay The major effort is in deciding what the user-mailbox is. If it includes any characters which are not legal in a mailbox name, (e.g. / [ ] : ), then this must be put in double quotes. Double quotes can cause problems to some systems the mail is sent from, see section 11.5 For systems in the Telemail group of systems the format of a user-mailbox is: [user/org]sysbranch/country Where sysbranch/country is one of: TELEMAIL/USA NASAMAIL/USA MAIL/USA TELEMEMO/AUSTRALIA TELECOM/CANADA TOMMAIL/CHILE TMAILUK/GB ITALMAIL/ITALY ATI/JAPAN PIPMAIL/ROC DGC/USA FAAMAIL/USA GSFC/USA GTEMAIL/USA TM11/USA TNET.TELEMAIL/USA USDA/USA TBXSPA/SWEDEN CORREO.PEMEX/MEXICO PIPMAIL1/TAIWAN So to mail to JBloggs/Acme on the TMAILUK network in Britain, one would use: "[JBloggs/Acme]TMAILUK/GB"%TELEMAIL%edu.isi@uk.ac.nsfnet- relay OMNET's Sciencenet is on the telenet system MAIL/USA. Listed below are some subdivisions CMR mail to: AIR Atmospheric Sciences EARTH Solid Earth Sciences LIFE Life Sciences OCEAN Ocean Sciences POLAR Interdisciplinary Polar Studies SPACE Space Science and Remote Sensing A typical user-mailbox of someone on OMNET would be in the form: [username/omnet]mail/usa Note that Telemail can also be reached as described in section 9.16 below. For other systems handled by CMR the user-mailbox is of the form indicated by the following examples: MCIMAIL: (see also section 9.17 below) 123-4567 seven digit address John Smith person's name (must be unique) COMPMAIL: NSFMAIL: USDAMAIL: CMP0123 three letters, followed by three or four digits J.Smith initial . last name 157:CMP0123 system number : account name DIALCOM: 6007:AUS0123 domain and system numbers : account name For COMPMAIL the system number is 134 and for both NSFMAIL and USDAMAIL it is 157. For DIALCOM related systems the domain is a one to three digit number and the system is a two digit number as per the following table: Service Name Country DOMAIN SYSTEM Keylink-Dialcom Australia 60 07,08,09 Dialcom Canada 20 20,21,22,23,24 DPT-Databoks Denmark 124 71 Telebox Finland 127 62 Telebox Germany 30 15,16 Dialcom Hong Kong 80 88,89 Eirmail Ireland 100 74 Goldnet Israel 50 05,06 Mastermail Italy 130 65,67 Mastermail Italy 1 66,68 Dialcom Japan 70 13,14 Dialcom Korea 1 52 Telecom-Gold Malta 100 75 Dialcom Mexico 1 52 Memocom Netherlands 124 27,28,29 Memocom Netherlands 1 55 Starnet New Zealand 64 01,02 Dialcom Puerto Rico 58 25 Telebox Singapore 88 10,11,12 Dialcom Taiwan 1 52 Telecom-Gold UK 100 01,04,17,80-89 DIALCOM USA 1 29,30,31,32,33,34,37,38,41,42, 43,44,45,46,47,48,49,50-59,61, 62,63,90-99 Unfortunately it's not quite clear what the name of the relay one mails to at isc.edu is. The documentation is unclear in this area. Although it implies TELEMAIL, this would seem to cause a clash (it would be unable to resolve accounts given by name to COMPMAIL, USDAMAIL or NSFMAIL). I suspect, therefore, that one either has to use the domain/system number method in full, or, more likely, one can only send mail to such systems by embedding the addresses in the mail as described later on. Examples (very doubtful) To mail account number 123-4567 on MCIMAIL use: 123-4567%TELEMAIL%edu.isi@uk.ac.nsfnet-relay To mail account CMP0123 on COMPMAIL 134:CMP0123%TELEMAIL%edu.isi@uk.ac.nsfnet-relay To mail account AGS0123 on USDAMAIL use: 157:AGS0123%TELEMAIL%edu.isi@uk.ac.nsfnet-relay To mail account KBH0123 on DPT Databoks in Denmark use: 12471:KBH0123%TELEMAIL%edu.isi@uk.ac.nsfnet-relay 9.15.2 Addresses Embedded in The Mail The alternative method is to put the address in the body of the message itself, as the first two lines of the message, and then send the mail to: intermail%edu.isi.intermail@uk.ac.nsfnet-relay The first two lines of the text of the message should be: Forward: system name To: user-mailbox Where system name is one of: TELEMAIL, MCIMAIL, COMPMAIL, NSFMAIL or USDAMAIL. For systems on DIALCOM related networks, one uses `COMPMAIL'. Using the same examples as used above: To mail to JBloggs/Acme on the TMAILUK network in Britain, make the first two lines of the text of the message: Forward: TELEMAIL To: [JBloggs/Acme]TMAILUK/GB and send it to intermail%edu.isi.intermail@uk.ac.nsfnet- relay. To mail account number 123-4567 on MCIMAIL, make the first two lines of the text of the message: Forward: MCIMAIL To: 123-4567 and send it to intermail%edu.isi.intermail@uk.ac.nsfnet- relay. To mail account KBH0123 on DPT Databoks in Denmark, make the first two lines of the text of the message: Forward: COMPMAIL To: 12471:KBH0123 and send it to intermail%edu.isi.intermail@uk.ac.nsfnet- relay. This is the method that it is used to contact Telecom Gold users (see 9.13 above). 9.15.3 Getting Mail Back To get the mail back to JANET: the users of these services have to construct an item of mail where the first two lines contain: Forward: ARPA TO: person@machine.place.AC.UK and leave the third line blank. E.g. Forward: ARPA TO: T.Clark@Warwick.AC.UK This item of mail must be dispatched to the CMR which has mailboxes on various commercial mail systems as follows: Telemail: [Intermail/USCISI]TELEMAIL/USA MCI-Mail: Intermail or 107-8239 CompMail: Intermail or CMP0817 NSF-Mail: Intermail or NSF153 USDA-Mail: Intermail or AGS9999 On other DIALCOM systems which need a domain/system number, it's probably worth trying: 134:CMP0817 or 157:NSF153 or 157:AGS9999 9.15.4 Further Information For more information send a message to NETSERV@UK.AC.EARN- RELAY containing the text GET A01APR14 HELPNEWS. For further help and advice, contact Intermail- Request%edu.isi.intermail@uk.ac.nsfnet-relay. 9.16 Telemail Telemail can be accessed as just described in section 9.15 above, or as: id%TELEMAIL%gov.nasa.arc.orion@uk.ac.nsfnet-relay It is unclear whether the id is only the short form: JBloggs/Acme (which would imply TELEMAIL/USA) or whether it allows the use of other Telemail systems by using the fuller form such as: [JSmith/Ford]ITALMAIL/ITALY 9.17 MCIMAIL Although the CMR relay described in 9.15 above can perform this task, a better way to send mail to a user of MCI MAIL is simply to mail it to: id%com.mcimail@uk.ac.nsfnet-relay Where id is three digits, hyphen, four digits. E.g. 123-4567%com.mcimail@uk.ac.nsfnet-relay For users with unique names the id can be their name, but with any spaces replaced by underscores. E.g. Alfred_Scholl%com.mcimail@uk.ac.nsfnet-relay E.g. VHalkett%com.mcimail@uk.ac.nsfnet-relay To get mail from MCIMAIL to JANET the MCIMAIL user responds `INTERNET' when promted for `EMS:' and the standard Rest- of-the-World form of the address (i.e. person@machine.place.AC.UK) when prompted for `MBX:'. 9.18 FIDO NET FIDONET is a network of PC systems which exchange mail via dialup connections. Mail can be sent from the Internet to users on these systems; their addresses will end in ".fidonet.org". Sometimes you may receive a FIDONET address in a numerical address notation. A complete address such as `1:105/4.0' translates to the domain name `p0.f4.n105.z1.fidonet.org'. The leading `1:' and the trailing `.0' are defaults, and are sometimes omitted; thus, `1:105/4' or `105/4' is the same address. The components of the numerical address are called the Zone, Net, FidoNode, and Point, respectively. The numbers are preceded by `z', `n', `f', and `p', followed by periods, concatenated in reverse order, and suffixed by `fidonet.org' to produce the complete host name. Usernames are typically of the form `Firstname_Lastname'. The Internet address should then be inverted to UK ordering before forwarding it via UK.AC.NSFNET-RELAY. Thus the Fidonet address `Jerry Frophaus of 129/37' can be translated into the address Jerry_Frophaus%org.fidonet.z1.n129.f37.p0@uk.ac.nsfnet- relay Conversely, to send a message from Fidonet to JANET, address the message to user UUCP on the nearest Fido-Net node which forwards mail to UUCP. (When the new nodelist flags are in place and widely used, the Fido user won't need to know what the nearest Fido-Net forwarding node is.) Fido-Net node 1:105/6 is a node which forwards mail to UUCP. The first line of the message should contain: To: person@machine.place.AC.UK For more information send a message to NETSERV@UK.AC.EARN- RELAY containing the text GET A01SEP19 HELPNEWS. 9.19 APPLE LINK This is Apple Computer Inc.'s in-house network. To mail a user on this use: user%com.apple.applelink@uk.ac.nsfnet-relay 9.20 COMPUSERVE Members of the CompuServe Information Service have an address (also known as User ID) which consists of number, comma, number. E.g. 70000,11. Change the comma to a dot and send it to compuserv.com as explained in section 4. E.g. 70000.11%com.compuserve@uk.ac.nsfnet-relay Members of organisations with a private CompuServe Mail area have an address of the form organisation:name, such as `ABC:J.SMITH'. To send mail to such an address from the JANET, send it to: name%com.compuserv.organisation@uk.ac.nsfnet-relay E.g. J.SMITH%com.compuserv.ABC@uk.ac.nsfnet-relay A few organisations have adresses which also include a department in the form organisation:department:name, such as `ABC:ACCTG:JOHN'. To send mail to such an address from JANET, send it to name%com.compuserv.organisaion.department@uk.ac.nsfnet- relay E.g. JOHN%com.compuserv.ABC.ACCTG@uk.ac.nsfnet-relay There are also a number of special destinations available to users of CompuServe Mail which are NOT accessible from outside, including: Facsimilie Delivery (e.g. >FAX: ) Postal Delivery (e.g. >POSTAL: ) Telex Delivery (e.g. >TLX: ) MCI Mail Delivery (e.g. >MCIMAIL: ) For mail to MCI refer to section 9.17 above. CompuServe subscribers can reach people on JANET from CompuServe's mailers via the specification: >internet:person@machine.place.ac.uk The use of `>network:' is CompuServe's general gateway- access syntax; it does not appear in anything on the Internet side of the gateway, and proper RFC-compliant headers are generated. 9.21 INDIA Apart from the Tata Institute which has two nodes on BITNET (TATAVAX and TIFRVAX, reached as explained in section 3), the majority of reachable sites in India are accessed via UUCP. However, it appears that the only site registered in the maps is shakti. To reach other sites one has to use addresses with `!' s in them from shatki, as explained in section 5 above. For more information send a message to NETSERV@UK.AC.EARN- RELAY containing the text GET A01MAY26 HELPNEWS. 9.22 MICROLINK This is part of TMAILUK and can be reached by X.400 (see section 7.2 for more details of X.400 relaying). Microlink mailboxes consist of the letters MAG followed by between three and six digits. E.g. MAG900665 Mail from JANET to Microlink should go via UK.AC.MHS-RELAY as follows: "/dd.un=mailbox_number/"%gb.tmailuk.microlink@uk.ac.mhs- relay E.g. "/dd.un=MAG900665/"%gb.tmailuk.microlink@uk.ac.mhs- relay Double quotes can cause problems to some systems the mail is sent from, see section 11.5 Getting mail back from Microlink is horrendously complex, the recipient should be entered as: (C:GB,PUB:GOLD 400,PVT:uk.ac,O:place,SN:user,OU:machine) NB: a space MUST be included in `GOLD 400'. The OU:machine can be left out if not used. E.g. (C:GB,PUB:GOLD 400,PVT:uk.ac,O:warwick,SN:T.Clark) Refering to section 7.2 it will be seen that the `C', `PUB' etc. components are Microlink's way of representing the X.400 attributes. Microlink allows use of so-called Nicknames, and again the process is complex. It is as follows At the prompt Enter Command? Nickname (Menu) ADD (Menu) X4 Enter nickname the nickname required Country name GB Public system gold 400 [Note space] Private system uk.ac (Menu) NAM Last name person Generational Qualifier n First name press return Middle initial n Organisation Name place Organisation Unit(s): : machine : press return DDAs press return This will generate an address of the form (and in the order) shown above. 9.23 Miscellaneous: ATT, BIX, BMUG, Connect, Geonet, Mfenet, NASAMail, Sinet These are a variety of networks for which I have no information other than brief details on how to mail them. The details are given in the table below. network address given address to mail ATT user user%attmail%com.att@uk.ac.nsfnet-relay BIX user user%net.das.dcibix@uk.ac.nsfnet-relay BMUG Name Surname Name.Surname%org.fidonet.bmug@uk.ac.nsfnet-relay CONNECT NAME NAME%net.das.dcjcon@uk.ac.nsfnet-relay GEONET user@host user%net.das.host@uk.ac.nsfnet-relay MFENET user@mfenode user%mfenet.mfenode.%@uk.ac.earn-relay NASAMAIL user user%gov.nasa.nasamail@uk.ac.nsfnet-relay SINET node::user user%com.slb.sinet.node@uk.ac.nsfnet-relay node1::node::user user%node%com.slb.sinet.node1@uk.ac.nsfnet-relay Mail is sent back to JANET address person@uk.ac.place.machine as follows: From CONNECT Send to CONNECT id `DASNET' with the first line of message: "person%machine.place.ac.uk"@DASNET From NASAMAIL Send to POSTMAN with the first line of the message: To: person@machine.place.ac.uk From SINET Send to M_MAILNOW::M_INTERNET::"person@machine.place.ac.uk" or M_MAILNOW::M_INTERNET::machine.place.ac.uk::user 9.24 Elsewhere If you've read through all sections above, then you've probably gained enough information to make an intelligent stab at networks not mentioned. Faced with an address like Bloggs@somwhere.wierdonet the basic idea is to try and pass the buck of deciding what to do with it to a place where there are experts who spend a lot of time sorting out mail routing problems, and hopefully have that network in their routing tables. So initial stabs may be: Bloggs%wierdonet.somewhere@uk.ac.earn-relay or Bloggs%wierdonet.somewhere@uk.ac.nsfnet-relay or Bloggs%wierdonet.somewhere@uk.ac.ukc Certainly the EARN-RELAY knows about the following domains (or sub-domains) that are not mentioned elsewhere: .una.at, .chunet, .guelph, .hepnet, .il, .is, .cnr.it, .no, .ac.sg, .utoronto, .weslyn, .wustl Don't assume you can relay via any arbitrary site. A site must have relaying capabilities. Although most UUCP sites can relay, most BITNET/EARN ones can not. A little trick which may be of use to those trying to send mail to the CERN DECNET (with names like place.decnet.cern.ch). If it gets rejected because the place is unknown, and you know its DECNET hostnumber then User%ch.cern.decnet.hostnumber@uk.ac.earn-relay may well work. 10. GREY BOOK ABROAD Some sites abroad use the Coloured Book protocols, and are accessible via PSS (IPSS) using Grey Book over NIFTP. There are sites running Coloured Book software in, Australia, New Zealand, Ireland, parts of Scandinavia, and some High Energy Physicists worldwide. Note that New Zealand sites will be moving away from use of these protocols. A number of sites in Australia are currently running the Colour book software. There is an initiative - Spearnet, South Pacific Educational and Research Network, which will initially be using this suite of protocols but migrating to others. Some examples are: NZ.AC.LINCOLN Lincoln College, New Zealand (VAX/VMS) NZ.AC.MASSEY Massey University Computer Centre, New Zealand (Pr1me) NZ.AC.WAIKATO University of Waikato, New Zealand (VAX/VMS) NZ.GOVT.DSIR Dept. of Scientific & Industrial Research, Div. of Information Technology, VMS AU.AUSTEK AUSTEK VLSI Design, Adelaide, Australia (VAX/VMS) AU.DITSYDA CSIRO Sydney; Gould UTX RPEPPING CSIRO Division of Radio Physics, Australia (VAX/VMS) AU.CSIRO.DITMELB CSIRO Division of Information Technology (Melbourne) - MicroVAX II and all of the HEANET sites mentioned in JANET.NEWS (see 9.5 above) The main problem that JANET users have to face here is getting Grey Book mailers to make the call incorporating the authorisation in the YBTS address, in order to negotiate through the JANET/PSS gateway. It's usually the fastest way to reach such sites if you can get it to work though. Information on the JANET/PSS gateway is held on the JANET NEWS machine (make an interactive call to UK.AC.JANET.NEWS). 11. VARIOUS PROBLEMS 11.1 Case translation UK.AC.EARN-RELAY translates all mailbox addresses to upper case. This prevents mail getting through to users whose username is lower or mixed case, and the target machine insists on the username being in the correct case. The same is usually true if mail goes over EARN/BITNET for any other reason. So if a username or sitename is only recognizable in mixed or lower case, you have to avoid EARN/BITNET. 11.2 Line truncation Many BITNET/EARN machines truncate or fold lines longer than 80 characters. This can be a problem for address lines which must be on one line. The address may start as a modest 30 characters or so, but by the time mailers and relays have been to work on it it's surprising how long the addresses can get. The truncation or folding of an address line then has a fatal affect on the mail. The culprits are almost invariably IBM machines which hanker after the old days of 80 column punched cards. 11.3 Character translation Going via relays may involve your mail in being translated from one character code to another. Even if the mail starts and ends in the same code, the fact that it has been through translation to another, then through an inverse translation which is not an exact inverse, causes alterations of characters. This is not usually a problem for the characters used within mail names and addresses. It would only show up if someone's mail name had an unusual character in it. 11.4 Alteration of the Contents All of the above changes can alter the contents of a mail item. Apart from truncation, this is within the bounds of what a mail service is there to provide. If you're trying to use mail as a file transfer mechanism, then you need to adopt an encoding which will survive these changes. Some of the encodings actually in use are not really sufficient. For an encoding to work over all possible networks it should really only use letters (regarding upper and lower as equivalent) and digits and be prepared for white space to be altered to other white space (E.g. several spaces, a new line, and several more spaces might become a new line and a tab). Few encodings meet such standards. 11.5 Characters trapped by the local mailer or Operating System Mail addresses can use a wide range of punctuation characters. Sometimes when an address is typed in to a particular operating system, by the user sending the mail, the operating system will take special action on some of these characters, and not pass them to the mailer as typed. Double quotes often cause problems. The problems which occur when double quotes are removed from an address are sometimes difficult to diagnose. Although it may render the address technically illegal according to RFC 822, the sending mailer may cope with it. It may then be a relay mailer which objects to the illegal address. Problems may also occur inside the mailer itself. Many Unix mailers are unable to pass double quotes in mail addresses (even having overcome the problem of getting the double quotes past the shell). 11.6 Mail Just Disappears This is one of the most frustrating problems to track down. It doesn't harm to state the obvious: just because you don't get a reply to some mail, you can't assume that your mail didn't get through - it may be the reply which has got lost. In such circumstances a phone call is often the easiest way of determining what got lost. Sometimes the mail will arrive eventually, it may get held up due to a machine in the route being out of action for a while, or a backlog building up on a machine in a store- and-forward mail network like EARN or UUCP. 11.7 Indecipherable Mail Addressee There are two main problems here. The first is that a mail address is not given fully. For both domain oriented addresses and network name oriented addresses, it is important that the address is given fully. For example, although many mailers in the uk.ac. domain can handle an address like T.Clark@Warwick, I should never quote my address as such, it's useless to people outside the uk.ac. domain unless they can work out that's where I am. EARN, BITNET and UUCP network users often quote their node name without mentioning the network they are on, in which case some detective work is required. EARN and BITNET names are never more than eight characters (but then very few UUCP names are) and tend to be quoted in upper case, whilst UUCP names tend to be quoted in lower case. If the indecipherable address appears in an item of mail, the problem can be a lot easier to solve as the headers may provide clues. For example something that has come through uk.ac.nsfnet-relay and isi.edu is likely to have come from one of the systems that the CMR (section 9.15) handles. The second problem is that users sometimes quote the address in the way in which it has to be typed in to a particular operating system. For example CBS%uk.ac.warwick::T.Clark Is the way one would enter the address T.Clark@uk.ac.warwick to some VMS MAIL systems on JANET. Faced with a format like that shown, one has to be able to unscramble it. As VMS MAIL is the most common non-standard format one is likely to come across, some guides on unscrambling it may be of use to non-VMS users. You can generally ignore whatever name appears before the `%'. If there is just one `::' then the piece before this is the site name and the piece after it the username. If there is more than one `::', then these separate the relays in order. Hence rubbish%site::user is user@site and rubbish%relay-1::relay-2::site::user is user%site%relay-2@relay-1 11.8 Mail gets Rejected This topic could form a whole document by itself. When the mail has been through a number of relays it can be difficult to track down precisely what went wrong where. There's nothing to beat a very careful examination of the entire rejection message, including its own headers. Beware that the rejection message may well not originate from the system which actually rejected the mail, but it is a report from a relay that the system it tried to pass the mail on to would not accept the mail. Whilst engrossed in the careful examination of headers, don't ignore such simple things as the user or system name being wrong. It's easy to confuse the letter O and the digit 0, or the letter l and the digit 1. Worse mistakes are made if the address has been conveyed by handwriting or speech. Because of the `domain problem' (see section 14.1), even with the best efforts the wrong JANET gateway may have been chosen. The only thing to do then is make five separate tries explicitly routing the mail through the five main JANET gateways listed in section 1. 12. OTHER INFORMATION SOURCES `Communications of the ACM' had an excellent article, `Notable Computer Networks' in their October 1986 issue (Vol:29 No:10). It was written by John S. Quarterman and Josiah C. Hoskins and runs to 40 pages in all. It is obviously rather out of date now. An updated version was published in the March 1987 issue of the journal, `Unix Review', entitled `Somewhere Over the Network' and written by John S. Quarterman. (Published by Miller Freeman Publications Co., San Francisco.) More recent still is the book: `The Matrix: Computer Networks Worldwide' written by John S. Quarterman, ISBN 1- 55558-033-5, published by Digital Press. DEC part number EY-C176E-DP. US price $60. Available in the UK from: Digital Equipment Corp Ltd Educational Services Shire Hall Shinfield Park READING Berks RG2 9XY tel: 0734 868711 The `Electronic Mail Guide' by Chris Benn and Ralph Martin of the Royal Greenwich Observatory. specialises in astronomical networks. It includes the actual addresses of about 4000 astronomers. Copies from CRB@UK.AC.RGO.STAR Another useful resource is the `Directory of Research Institutes in High Energy Physics' CERN, GENEVA published anually. It lists along with loads of other stuff the e- mail addresses of all universities and institutes with any High Energy Physics interest. 13. SUMMARY I've built up a table of suggestions below which summarises the information above. I've put the suggestions into three categories: (1) reasonably trustworthy, (2) probably works, (3) rather a wild shot. Numbers in parentheses are references to notes at the end of the section. The use of capital letters (shown in italics) and the single italic letter a is also described there. To cataddress ACSNET 1 U%a.A%uk.ac.ean-relay APPLELINK 2 U%com.apple.applelink@uk.ac.nsfnet-relay ARISTOTE 1 a.F@uk.ac.mhs-relay BITNET 1 U%H@uk.ac.earn-relay BIX 2 U%net.das.dcibix@uk.ac.nsfnet-relay BMUG 2 U%org.fidonet.bmug@uk.ac.nsfnet-relay CANET 2 U%beijing%de.uka.ira@uk.ac.nsfnet-relay CANET 3 U%beijing%de.uka.ira@uk.ac.earn-relay COMPUSERVE 2 U%com.compuserv@uk.ac.nsfnet-relay COMPUSERVE 2 U%com.compuserv.H@uk.ac.nsfnet-relay CONNECT 2 U%net.das.dcjcon@uk.ac.nsfnet-relay CSNET 1 U%Z%net.cs.relay@uk.ac.nsfnet-relay CSNET 1 U%Z%net.cs.relay@uk.ac.earn-relay DARPA Internet 1 U%I.a@uk.ac.nsfnet-relay DARPA Internet 1 U%I.a@uk.ac.earn-relay DARPA Internet 1 U%arpa.H@uk.ac.nsfnet-relay DARPA Internet 1 U%arpa.H@uk.ac.earn-relay DEC's Easynet 1 U%H.dec%com.dec.decwrl@uk.ac.nsfnet-relay DEC's Easynet 2 U%H.dec%com.dec.decwrl@uk.ac.earn-relay EAN 1 U%Z@uk.ac.ean-relay EARN 1 U%H@uk.ac.earn-relay FIDO 1 U%org.fidonet.zn.nn.fn.pn@uk.ac.nsfnet-relay GEONET 2 U%net.das.H@uk.ac.nsfnet-relay GOLD 2 intermail%edu.isi.intermail@uk.ac.nsfnet-relay (2) HEANET 1 U%E.a@uk.ac.earn-relay HARNET 2 U%H%uucp.hkucs@uk.ac.ukc (1) HARNET 3 U%H%hkucs.uucp%net.uu.uunet@uk.ac.nsfnet-relay HEANET 1 U%E.a@uk.ac.earn-relay IBM's VNET 1 U%vnet@uk.ac.earn-relay INFNET 1 U%it.infn.H@uk.ac.earn-relay JUNET 1 U%J.a@uk.ac.ukc (1) JUNET 2 U%J.a@uk.ac.nsfnet-relay JUNET 2 U%J.a@uk.ac.rl.earn JUNET 2 U%a.J%net.cs.relay@uk.ac.rl.earn MAILNET 1 U%mailnet.H@uk.ac.earn-relay MCIMAIL 1 U%com.mci@uk.ac.nsfnet-relay MICROLINK 1 "/dd.un=U/"%gb.tmailuk.microlink@uk.ac.mhs-relay MFENET 1 U%a@uk.ac.earn-relay NASAMAIL 2 U%gov.nasa.nasamail@uk.ac.nsfnet-relay NETNORTH 1 U%H@uk.ac.earn-relay NZ 2 U%N.a@uk.ac.ean-relay NZ 1 U%N.a@uk.ac.nsfnet-relay SINET 2 U%com.slb.sinet.H@uk.ac.nsfnet-relay SPAN 2 "H::U"@uk.ac.span-relay TELEMAIL 2 U%telemail%gov.nasa.arc.orion@uk.ac.nsfnet-relay UUCP 1 U%uucp.H@uk.ac.ukc (1) UUCP 1 U%Z@uk.ac.ukc (1) UUCP 2 U%H.uucp%net.uu.uunet@uk.ac.nsfnet-relay UUCP 2 U%Z%net.uu.uunet@uk.ac.nsfnet-relay UUCP 2 U%uucp.H@uk.ac.earn-relay UUCP 2 U%H.uucp%mcvax@uk.ac.earn-relay Xerox Internet 2 U.R%com.xerox@uk.ac.nsfnet-relay Xerox Internet 2 U.R%com.xerox@uk.ac.earn-relay Notes (1) Use only if your site subscribes for use of UKC (2) The text of the mail contains further addressing information Italic capitals and a are used as follows: U denotes a user H denotes a single host name and does not contain any dots. Z denotes an arbitrary address within the network, which may contain dots. n denotes a number a denotes a domain type address. It may contain dots and is either preceded or followed by a domain name. The meaning of the letter, and order in which the address should be given is indicated as follows: a.A An address in ACSNET/CSIRONET, ending with the domain name `.au' or `.oz' E.a An address in HEANET, starting with the domain name `ie.' a.F An address in ARISTOTE, ending with the domain name `.aristote.fr' a.I An address in the Internet, ending with the domain name which is one of: `.com', `.edu', `.gov', `.net', `.org', `us' I.a An address in the Internet, starting with the domain name which is one of: `com.', `edu.', `gov.', `net.', `org.', `us' a.J An address in JUNET, ending with the domain name which is usually `.jp', though may also be `.junet' or `.jpn' J.a An address in JUNET, starting with the domain name `jpn.' a.N An address in New Zealand, ending with the domain name `.nz' a.N An address in New Zealand, starting with the domain name `nz.' a.R An address in Xerox grapevine, ending with the registry name, where R is the name of the registry. 14. DOMAINS 14.1 The Domain Problem Unfortunately it's just not possible to always route according to the domain. For example both EAN-RELAY and EARN-RELAY handle sites in the domain `.ie'. Apparently the EARN-RELAY route is best. Some domains are meant to indicate a particular network. For example `.edu' should mean that the site is accessible via the Internet. However, some sites on only UUCP have adopted names ending `.edu' sometimes without taking steps to register them with the Internet. (Or at least that the appropriate partial domain enabled source routing to work over the Internet.) Many BITNET sites use Internet style addresses, but most of these are registered with Internet. Domain style addresses are nicer for users to use, the problem is that the electronic mail networks are not generally in a good enough state to make use of them with high reliability. Despite analysis to greater than the top domain level, it is not always possible to predict with high accuracy the best JANET gateway one should forward the mail to. In many cases the mail will find its way through. But there are also cases where it won't work, and one has to explicitly route the mail through another gateway. 14.2 Partial Domain Routing The NRS (see section 1.2) has some information on partial domain routing. Below is a suggestion for a table which could be used to do the job more completely. Note that it is only a suggestion, if you know better for a particular entry, then drop the one suggested here. It's not complete; a better job could be done by regularly getting a copy of ean.sites.raw (see section 7) and making full use of that too. It has flaws: it can not cope with UUCP addresses which aren't in the UUCP maps. Since the route taken to reach a particular person may depend on whether they themselves are registered for receipt of mail by one method or another, the suggestions can obviously not cope with that sort of detail. You may wish to try inverting an address before matching it to the component on the left of the table. I refuse to enter into the `holy wars' on whether this is a good idea or not! The ordering used on the left is the UK ordering, domain.place.machine. 14.2 How to Use the Partial Domain Table The table is designed to work on addresses of the form: left-part@right-part which contain only one `@'. The left-part is never touched. If the right-part is not recognizable as an address registered in the NRS, scan the table sequentially, from the top, until a match is obtained between the whole of the item in the first column of the table and same number of dot separated components at the start of the right-part. This may or may not match all the components in the right-part. Ignore upper/lower case differences. If a match is obtained, consult the Flags column, this indicates a number of actions to perform, or checks to make. They must be done in the order the flags are given in the column. They are as follows: I Invert the order of the dot separated components in the right-part. E.g. domain.place.machine becomes machine.place.domain. K Count this as a match only if your site subscribes to UKC. N Count this as a match if your site does not subscribe to UKC. P Prepend the contents of the right column to the right- part, ensuring that it is separated by a dot. Rn Remove the first n dot separated components from the right-part. Now check the right column. If it is not empty, and has not been used up by a P key, change the `@' in your address to a `%' add an `@' to the end followed by the contents of the right colum. This now becomes the new right-part. If the new right-part is still not an NRS registered address then repeat the whole process using the new right-part, and scan from the top of the table again. 14.4 The Partial Domain Table domain keys relay/alteration yu.jumail uk.ac.ean-relay wustl uk.ac.earn-relay weslyn uk.ac.earn-relay vnet uk.ac.earn-relay uucp NI net.uu.uunet uucp K uk.ac.ukc utoronto uk.ac.earn-relay us uk.ac.ukc uninett uk.ac.ean-relay uk.co uk.ac.ukc telemail gov.nasa.arc.orion surf.kun uk.ac.ean-relay span I edu.stanford.star sinet P com.slb sg.ac uk.ac.earn-relay se uk.ac.ean-relay riup.ctt.inesc uk.ac.ean-relay pt.ctt.inesc uk.ac.ean-relay oz uk.ac.ean-relay osiride.cnr.iasi uk.ac.ean-relay org uk.ac.nsfnet-relay nz uk.ac.nsfnet-relay no uk.ac.earn-relay nl uk.ac.earn-relay netnorth uk.ac.earn-relay net uk.ac.nsfnet-relay nasamail P gov.nasa mfenet uk.ac.earn-relay mcimail P com mailnet uk.ac.earn-relay kr uk.ac.ean-relay junet NI net.uu.uunet junet K uk.ac.ukc jpn NI net.uu.uunet jpn K uk.ac.ukc jp.ac uk.ac.earn-relay jp N uk.ac.earn-relay jp K uk.ac.ukc it uk.ac.earn-relay isanet.hi.rhi uk.ac.ean-relay is uk.ac.earn-relay irl.heanet R2P ie irl.hean R2P ie irl R1P ie iris R1P es infnet R1P it.infn il uk.ac.earn-relay ie uk.ac.earn-relay hepnet uk.ac.earn-relay hasler.kom.vax2 uk.ac.ean-relay guelph uk.ac.earn-relay gov uk.ac.nsfnet-relay geonet R1P net.das gb.gold-400 uk.ac.mhs-relay gb.btmhs uk.ac.mhs-relay funet uk.ac.ean-relay fr uk.ac.mhs-relay fi uk.ac.ean-relay es.etsitm uk.ac.ean-relay edu uk.ac.nsfnet-relay earn uk.ac.earn-relay dk uk.ac.ean-relay dfn R1P de.dbp dec I com.dec.decwrl de.dbp.siemens-ag.ap11 uk.ac.mhs-relay de.dbp.nixdorf.nme uk.ac.mhs-relay de.dbp uk.ac.ean-relay de uk.ac.earn-relay csnet I net.cs.relay connect R1P net.das.dcjcon compuserve P com com uk.ac.nsfnet-relay chunet uk.ac.earn-relay ch.cern uk.ac.earn-relay ch uk.ac.ean-relay cern uk.ac.earn-relay cdn uk.ac.ean-relay ca uk.ac.ean-relay bmug P org.fidonet bix R1P net.das.dcibix bitnet uk.ac.earn-relay be.rtt.fundp.info uk.ac.ean-relay be uk.ac.earn-relay aut uk.ac.earn-relay au.oz R1 au uk.ac.ean-relay at.una uk.ac.earn-relay at.ptt uk.ac.ean-relay arpa uk.ac.nsfnet-relay applelink P com.apple 14.3 Examples Suppose we have the address: graf@dfn.gmd.zix `graf' is the left-part and `dfn.gmd.zix' the right-part, and it's not an NRS registered address. Scanning down the table we get a match on `dfn'. The keys tell us to remove the first component (leaving `gmd.zix') and add `de.dbp'. Our new right-part is therefore `de.dbp.gmd.zix'. This is still not an NRS registered address, so we start the process again. This time the `de.dbp' matches an entry, there are no flags, and there is an entry in the right column. So we turn the existing `@' to a `%' (giving a new left-part of `graf%de.dbp.gmd.zix' and then add the right column (uk.ac.ean-relay) after an `@' as the new right-part. This time it is registered in the NRS, so we can now use the address, it's: graf%de.dbp.gmd.zix@uk.ac.ean-relay Take another example: Harry%iapetus@SPAN.saturn The left-part is `Harry%iapetus' and the right-part is `SPAN.saturn'. It's not in the NRS, and the table gets a match at `span', where the key tells us to invert the right-part, becoming `saturn.SPAN'. The right column demands that we change the `@' to a `%', making the left- part now `Harry%iapetus%saturn.span', and pick up a new right-part of `edu.stanford.star'. That's still not in the NRS. Into the table again, from the top, and we get a match on `edu'. No flags, but we pick up a new right part (uk.ac.nsfnet-relay), which is NRS registered, so we end up with: Harry%iapetus%saturn.span%edu.stanford.star@uk.ac.nsfnet- relay As it happens, that's not the best route, but the table can't cope with the re-arrangement of the username required to route it via uk.ac.span-relay 15. INDEX TO NETWORKS Networks mentioned in this document and the section they appear in. acsnet 9.4 mcimail 9.17 applelink 9.19 memocom 9.15 arpanet 4 mfenet 9.23 ati 9.15 microlink 9.22 att 9.23 nasamail 9.23 bitnet 3 netnorth 3 bix 9.23 nsfmail 9.15 bmug 9.23 nsfnet 4 bt gold 9.13 omnet 9.15 canet 9.12 phonenet 6 cmr 9.15 pipmail 9.15 compmail 9.15 sdn 9.6 compuserve 9.20 sinet 9.23 connect 9.23 span 9.7 correo pemex 9.15 starnet 9.15 csironet 9.4 tbxspa 9.15 csnet 6 telebox 9.15 darpa 4 telecom 9.15 dearn 3 telecom gold 9.13 decnet 9.8 telemail 9.16 dgc 9.15 telememo 9.15 dialcom 9.15 tm11 9.15 dpt databoks 9.15 tmailuk 9.15 ean 7 tommail 9.15 earn 3 ttns 9.15 easynet 9.8 tuai 9.3 eirmail 9.15 uknet 5 eunet 5 usdamail 9.15 faamail 9.15 usent 5 fidonet 9.18 uucp 5 frearn 3 vnet 9.10 geonet 9.23 x.400 7 gold 9.13 xerox RIN 9.9 goldnet 9.15 grapevine 9.9 gsfc 9.15 gtemail 9.15 harnet 9.11 heanet 9.5 ibm 9.10 infnet 9.2 intermail 9.15 internet 4 italmail 9.15 janet 1 junet 8 keylink 9.15 mailnet 9.1 mastermail 9.15 16. SIGNATURES It's often worthwhile adding a `signature' line to outgoing mail headed for places other than on JANET. A short signa- ture should suffice most of the time. E.g. Tim Clark T.Clark@warwick.ac.uk (JANET: T.Clark@uk.ac.warwick) If you want to cram into it as much help as possible for those who may not be able to make use of that, then I sug- gest something like the one below. I would not get a mailer to add the long signature automatically (it's too long for some anyway). Tim Clark T.Clark@warwick.ac.uk Post: Computing Services JANET: T.Clark@uk.ac.warwick | University of Warwick Internet: T.Clark%warwick.ac.uk@cunyvm.cuny.edu | Coventry, UK EARN/BITNET: T.Clark%warwick.ac.uk@UKACRL | CV4 7AL UUCP: T.Clark%warwick.ac.uk@ukc.uucp | Phone: +44 203 523224