Guide to usage of the E-mail list of gravity researchers

                        M.A.H. MacCallum
           Queen Mary and Westfield College, Mile End Road
                        LONDON E1 4NS, U.K.

Last update: 28 May 1993

1. Introduction
2. The national and international networks
      Introduction and DECnet(s)
   A. International networks
        CREN: BITNET and CSNET (EARN, NETNORTH, Asianet)
        HEPNET and SPAN
        Internet (ARPA, edu, gov, mil, and so on)
        UUCP (Usenet)
        X.400 (EAN)
   B. Examples of national networks
        AARnet (Australia) (INFNET, ASTRONET) (Italy)
        JUNET (Japan)
        JANET (U.K.)
3. Mail sites and usernames
4. Addressing sites on one network from another
5. Bibliography on email networks
Appendix: Format of the surface mail address file

1. Introduction

The objective of this guide is to enable recipients of the list of electronic mail addresses of researchers in gravity to make effective use of it. The list of email address supplies, for each listed person, one or more entries each of one line containing 6 fields separated by an & (For the list of surface addresses see the appendix). These fields are

1. Surname or family name (or the one not abbreviated in citations!)
2. (Other) given names and initials
3. An enumerator of the addresses for the same person. Addresses relating to different physical locations will be numbered. Different e-mail addresses for the same location will be given letters A, B, C etc. At any time the address to which I actually send mail (i.e. the primary address) will be the one labelled 1A. (This increases the number of changes for those who move around a lot.) The default values are 1 and A so a blank here should be read as 1A, B means 1B, 1 means 1A, and so on.
4. An indicator of whether the e-mail address is shared or personal. Shared addresses are denoted S. All others are assumed to be personal, so this field will be blank.
5. The indexing used to locate the relevant surface mail address in the file of such addresses. This may be one word or two. If it is two they will be separated by a comma and a space.
6. The e-mail address. The domain style addressing is easy enough to decompose if necessary, since the separators (. % and @) are well-known and have fixed roles. The domain addresses will have the top-level last (i.e. will *not* be in the UK form). Most networks understand these electronic mail names in the internationally agreed domain form, but there are some special cases where this is not correct for a given network, so please check the relevant section below before trying to use an address. Please also note the remarks about mailers in this section.

To retain the human readability of this files I lay it out with blank spaces to make it look tabular, but the discardable blank spaces will always be at the end of a field. The end of line will terminate the record. As well as the file of email addresses there is a file of surface mail addresses, described in the Appendix.

An email address can be thought of as having three components, the mailusername, mailsite, and network. In the next section, section 2, the different international networks are briefly described. The descriptions are incomplete, as this guide has only a limited purpose. The best article giving more details is `Notable computer networks' by J.S. Quartermain and J.C. Hoskins, Communications of the Association of Computing Machinery 29, pp 932-971 (1986), but unfortunately it is now out of date. A short Bibliography of other references, some more recent than the Quartermain/Hoskins article, is attached as section 5.

The remaining two subfields, <mailusername> and <mailsitename>, are discussed in section 3. At this point the reader should understand her or his own address, but this is of no help if trying to reach a user on another network, so section 4 tries to give some advice on this matter. It is worth bearing in mind that ALL the networks with users on the list do interconnect (otherwise I could not reach all the people on the list!).

In trying to send mail, one very important consideration is the actual mailer program at your own site, and the way in which it has been configured. Unfortunately it is almost impossible to give globally valid advice on this point, and I am certainly not qualified to advise on systems I have never used. Perhaps the main point I would make is that there is no standard form of address valid at all sites. The list assumes a domain form of a widely-used type.

To appreciate why no standard is possible one must recognize that at present the mailer programs available on the main types of machine used by people on the list differ widely (though there is some convergence going on in the use of domain names). One possibly useful piece of advice is that the VAX VMS mailers, once one goes outside their local DECNET (see notice +), seem to require addresses to be supplied in a form such as IN%"<an Internet address>"
JANET%"<a Janet address>"
Users of Unix machines running uucp may need to use old-style 'bang' addresses (see under UUCP in section 2) rather than domain addresses, although modern Unix mailers use domain addressing and convert to 'bang' form if necessary (we do exactly that at my site).

(+ DECNET, along with Unix, VMS, RSCS, and so on are trade-marked or copyrighted property of various commercial companies: I hope they will not sue me for any inadvertent failure to observe their rights.)

My own machine uses (at present) the Berkeley Unix sendmail program, and is directly connected, as far as mail is concerned, to a departmental Ethernet and to the UK national X.25 network JANET. Other machines on our Ethernet provide the connection (for telnet and FTP as well as mail) via a College Ethernet to the international Internet. The X.25 and Ethernet connections link us to other machines in the U.K. and hence to the international UUCP network, BITNET etc.

As well as the mailer program, its configuration must be considered. This can strongly affect the ease with which you can address remote sites. For example the main mailer machine at my site recognizes addresses of the form x@y.bitnet . It is configured so that it "knows" such mail should be sent to the gateway between JANET and BITNET, which is at the Rutherford Laboratory and known on JANET as . Machines on our network know that anything that is not local goes (in SMTP format, like a usual Ethernet mail) to the mailer machine on our Ethernet, which converts the mail to the JANET format and sends it to Rutherford. The mailer machine therefore will expand x@y.bitnet into The reason that such useful translations take place automatically is that I as the departmental electronic mail postmaster set up the tables used by our mailer program to give the users the convenience of only needing to provide the x@y.bitnet part.

The degree to which other sites can and have set up configuration tables in a similar manner is beyond my control, but it is worth noting that the sites which act as gateways between one network and another frequently have large tables of this sort (e.g. on UUCP some routing information is almost essential but for UK users the JANET/UUCP gateway at ( maintains a list of more than 12 thousand mailsites it can recognize without further information).

What all that advice about mailers and their configuration boils down to in practice is that you will have to consult your local experts to find out how your machines want their addresses supplied. Only if the local experts are not sufficiently expert (this was sadly all too frequent because computer centres often are not users of international electronic mail, but seems to be improving as Internet grows) should you get caught up in trying to do it yourself. (Believe me, it takes a lot of time and causes much frustration.)

An important way (perhaps the most important, and the one assumed in the list) in which addresses are constructed is known as domain addressing (see the start of section 3 for a fuller description). Most networks have not yet started to conform to the forthcoming X.400 standard from the International Standards Organization (ISO), and there is instead a de facto standard which comes from the Internet (ARPA) network (see section 2) document RFC 822. Here RFC means 'Request for comment'. The series is available from the ARPAnet Information Center, Menlo Park, CA, U.S.A, and by electronic mail from various information servers. Any reader who wants a copy and cannot get one is invited to contact me for help. In domain addressing the top-level domains (except for the U.S.: see under Internet in section 2) are country codes, using the 2-letter codes of the ISO standard 3166, except where they are the names of networks such as BITNET which do not follow this standard. (For this reason no host on Internet should ever have a 2-character name: the worst offenders used to be CS departments who called their machines cs , leading to confusion with the country code for Czechoslovakia: since the breakup of the country this has become less of a problem.)

Corrections and useful additions to the information in this guide will be much appreciated.

2. The international and national networks

Introduction and DECnet(s)

The international network which used to be best known to physicists is BITNET and indeed people sometimes referred to the whole international electronic mail system as BITNET. This was a mistake: BITNET was small compared say to UUCP (2526 sites in the tables we had at QMW on 31 Dec 88, compared with 11641 on UUCP) and it has peculiarities not common to the other networks (the most irritating of which is that it does not reliably transmit TeX files, because it messes up TeX's special characters). The reason physicists thought this way is probably that CERN started on BITNET at an early stage and thus influenced physicists worldwide. Computer scientists similarly thought of UUCP as being THE international network. (Both these views are rapidly being superseded by the rise of Internet.) In what follows I describe all international networks appearing in the e-mail lists (which does not - yet - include all such networks in existence), and then some of the national ones.

One small point before I start is to note that people often give DECnet addresses. Unfortunately the term DECnet is both the name of an international network and of the proprietary system for networking VMS VAXes (and other DEC products) which it uses. Hence there could in principle be many disjoint DECnets (for instance, on the lists below, HEPNET and SPAN are DECnets but are in fact connected to the (single) international DECnet). It is worth noting that the DECnet address numbering scheme originally (up to Phase IV) allowed for 63 areas of up to 1023 nodes each: the numerical address is of the form (<area>.<host>) where <area> and <host> are numbers: such addresses were usually represented by the single number 1024<area> + <host>. DECnet machines also maintain a translation table from mnemonics to numbers (and vice versa). In the tables I give the mnemonic wherever known to me. Recently Phase V (also called DECnet/OSI) has been introduced, allowing a larger number of addresses (by a factor 16) called NSAP addresses.

Moreover the usual syntax within a DECnet of host::user is awkward to use internationally as RFC 822 rules recognize the colon as the terminator of the name of a mail header field and get confused when the 'To:' line contains 3 colons! Hence if you are at a site whose only direct connection is to a DECnet please try to find out which DECnet it is and if possible what your host is known as at the gateway to other nets (i.e. the mnemonic name rather than the number of the host would be useful). The international and national networks SPAN (for space physics), HEPNET (for high-energy physics), and others are linked up in one very large DECnet, but the addresses are still not usable from other nets (and are hence no use to me!).

A. International networks


BITNET, EARN, NETNORTH and Asianet form a single network: the division is purely administrative (I use only the BITNET name in the tables, though EARN is preferred within Europe). In about 1990 BITNET formally merged with Csnet (see below) into CREN (Corporation for Research and Educational Networking), but the merger was administrative only and the technical bases of the two networks still differed. In September 1991 CREN closed CSnet down.

The Computer Science net CSNET was mainly U.S. based. (It started as a non-military equivalent of the ARPA net, see below.) It used domain addressing with top domain CSNET or net (the main link to other nets was CSnet has now been merged into the Internet, see below.

BITNET ("Because It's Time" network) was based on the IBM RSCS protocols and was initially promoted and partly funded by IBM. RSCS did not use domain addressing, which has been a problem, but many (if not all) BITNET sites now also use domain forms of address. The other major irritation is that IBM used EBCDIC (extended binary coded decimal information code) as its coding of characters: this differs from the now generally used ASCII (American standard code for information interchange) 7-bit code and there is no unique translation between the two (partly because EBCDIC has more characters and more than one form). The consequence is that certain characters are usually not correctly transmitted over BITNET: in particular, as mentioned above, this affects TeX files. For sites directly on BITNET, there are compensating advantages including the speed of communication and extra facilities. However, due to the cost of BITNET, sites in Europe at least have recently been moving over to national networks using Internet domain addresses (e.g. this has been happening recently in Germany and Switzerland).


HEPNET is an international DECNET for High Energy physics with about 600 hosts, 150 or so in Europe.

SPAN is a similar net for Space Physics.

Internet (ARPA, edu, gov, mil, NSFnet, org)

This grew from the U.S. Defence Department's Advanced Research Project Agency net which began in 1969. Its initial military overtone dissipated as more and more academic sites joined, and it spread outside the U.S. The protocols used for transport over this network are the well-known TCP/IP (IP = Internet protocol!) family. In 1982 the decision was taken to go over from the original sitenames (which were rather like those of BITNET) to domain names and this has since been largely implemented. As part of this change the former ARPA sites were sub-divided into several domains. The U.S. domains do not (unlike others) use a country code (presumably this is another instance of the belief within the U.S. that the U.S. is the world, as in 'World Series' for baseball): instead there are edu (for educational), gov (government establishments), mil (military) and other domains.

The term Internet at one time strictly referred to the sites listed in the HOSTS.TXT database, but now many sites using the same addressing scheme and protocols are connected. While the numerical addressing used is still centrally controlled, this control takes the form of allocation of ranges of numbers to more local adminstrations, who then allocate to individual hosts. The local administrations are now obliged to support name-server facilities enabling remote sites to locate hosts wthin the local networks. The National Science Foundation's NSFnet forms part of the Internet. (The politics of this are very fluid, and I may be out-of-date.)

Note: Most sites on the Internet have mailer software which will recognize the leading part of a sitename and forward mail to an appropriate gateway even though the address in full is not registered: for instance if is not registered but is a registered gateway, the mailer sends the mail to and assumes will recognize foo. This is in principle a very good scheme but falls foul of the fact that not all Internet machines have such software (e.g. in the U.K. the official gateway at for some time did not, while the EARN gateway at did). For sites where the name given is not registered in full I have sometimes given a working alternative as well. It also seems to me there is sometimes a tendency for sites to give themselves valid domain names, when in fact these names will not be recognized, even with gatewaying, at Internet hosts. This rather confusing practice should be avoided! It is nowadays very important that major international name servers can recognise the name of your site!

UUCP (Usenet)

"UUCP" refers to the rather loosely organized network of machines running the Unix operating system and making mail transfers via the uucp program. It was the main network of Computer Science departments, and is very large (although I believe many transfers of data between machines notionally on this net actually use Internet protocols). Usenet is the news and mailing list network also using uucp, most of its sites being UUCP mail sites. Machines on UUCP may quote uucp as their top-level domain (if they use domain addressing) but full domain addresses on UUCP are gradually coming in (the main hold-up is that early versions of uucp only allow 6 significant characters in names).

One way to recognize a UUCP site is that the uucp program itself uses a different address format (known as 'bang' addressing from its use of the exclamation mark), often quoted in some form such as .....!{seismo,ucbvax}!site1!site2!user where the dots mean use any route you can find to one of the sites inside the {} and from there on route the mail to site1, then to site2 which is where the user really is. Note the ordering and the use of ! as a separator. For example a user trying to reach me from a uucp site which has a direct connection to the seismo machine might use the uucp address seismo!mcsun!!!mm

Note that at uknet, and and many other UUCP sites, the domain form of my address is valid. This is an increasing trend, and is the reason UUCP addresses in the table are NOT supplied in domain form. Typically the conversion is as for R. Gleiser, whose domain address gleiser%famaf%dcfcen@atina.uucp became a uucp address ....!atina!dcfcen!famaf!gleiser

The real snag this gives is when one has to use both forms to reach a site. Mixed forms violate both uucp and domain standards, basically because in sitea!user@siteb the poor mail system cannot be sure if the mail goes first to sitea or siteb. Usually what is meant is mail should be sent to siteb using domain addressing, and at siteb the remaining sitea!user will be interpreted using UUCP, but many mailers reject any such mixed form so it should only be used where the siteb cannot or does not convert user@sitea to sitea!user. There was only one such address in the table (Frank Estabrook's): a change of configuration at (at my request) has made this unnecessary now, but if a future similar problem arises I will apply the same method again.

X.400 (EAN)

The ISO standards give several relevant to mail. The X.25 standard lays down how packets of information are transmitted. X.400 is a related mail standard, saying how the data within those packets should be laid out if the packets are e-mail. It is used in a system of international data transfer developed by the public telephone companies. It is one of the more advanced systems, and quite recent. The actual syntax of addresses as specified for X.400 is rather cumbersome, so the international network EAN (said to stand for Electronic Access Network) which uses X.400 protocols used domain addressing (see section 3 of this guide), which the machines on EAN converted to and from the correct X.400 forms. There is an associated nameserver standard called X.500. The number of countries accessible over X.400 nets is growing rapidly: for example, it is a good route from the U.K. to Australia, although the sites at either end are not in general directly connected to EAN. (N.B. EAN is not the same as EARN.) It is my impression that EAN as a separate net is just getting submerged in the very general use of X.400 by public telephone provider services.

See the note at the end of the ARPA entry. It applies to EAN too.

B. National networks

An increasing number of countries are developing national networks, often as subnets of X.400, or Internet, or BITNET. In earlier versions of this guide I was able to be reasonably comprehensive in listing these, but to do so has now become impossible so I shall mention just a few as examples.

Mail sites and usernames

The format of address proposed in RFC 822 is an amended version of the one in RFC 733. It proposes domain addressing for sites, in which an address consists of one or more words separated by periods e.g. word1.word2. The ordering of the words is hierarchical so that in word1.word2.word3.word4 , word1 would be an individual site which is one of several in the word2 domain, which in turn is one of several in the word3 domain and so on. An address is 'absolute' if the top (last) domain belongs to no larger domain: these are usually the country codes or the top-level domains of the Internet. (Example: is an absolute address). A 'relative' address is one in which higher domains common to sender and recipient are omitted (Example: maths.qmw is a relative address in A 'fully-qualified' address is one with all domains specified (Example: the fully-qualified address of the machine I use the most is .)

I have tried to use the term 'mail site' for the "place" part of an e-mail address. The reason is that although in many cases the mail site is an individual machine, this is not necessarily so: i.e. the mail site name need not be fully-qualified. (Example: to send me mail it is not only unnecessary but counterproductive to use the galois part of my machine's fully-qualified name: in fact is a network of - at present - more than 15 machines of 5 types, but only the one name is registered with the NRS [see under JANET in section 2].)

The advantage of mail site names which do not include reference to a specific machine is that the mail site remains the same even if the machine is changed. Indeed there seems to be a trend in this direction which may one day lead to us addressing academic users' sites just by the name of their University or Institute (without mentioning departments): this has happened at my institution, and I can thus be reached at a mail site called just I would urge all of you who have influence in such matters to pressure your local authorities in this direction.

A secondary aspect is that even if machines are mentioned they should be given mail names which do not include the machine type: this again will help to keep mail names the same when technology changes. (What will happen when the world's VAXes finally retire? - there are many sites whose name includes 'VAX' and it is rumoured that in one recent case when the machine was changed but the name was not, the manufacturer sued the institution!)

As well as the top domains defined in the Internet, many places use the names of networks (e.g. BITNET) as top-level domains. Until or unless there is some international authority specifying a uniform system this is likely to continue.

Within the networks that use domain addressing the sequence of sub-domains is sometimes self-explanatory if you know the postal address (e.g. is clearly a University of Waterloo Maths department mail site) and this is becoming more common.

Hostnames on BITNET (when not in domain form), and mnemonic names on the various DECnets, do not follow the domain naming conventions and consist instead of a single word. The length of this word is not fixed (though there seems to be an upper bound around 8 characters), nor is its form. BITNET sites added in recent years have started to use a version of the Internet naming by beginning with the two-letter country code or the international car-plate code (e.g. just D for Germany, rather than DE), then adding 2 or 3 letters for the location, 1 or 2 for department, and digits for system type and number. For example: sesuf51 is in Sweden [se] at Stockholm University [su] Physics Department [f], is a VAX running a VMS mailer [5] and is the first such [1]. Unfortunately the brevity of the coding makes it somewhat cryptic, and confusion of letter O and digit 0 is easy (which is why I have put all site names in the list into lower case, where this confusion is avoided).

Usernames are also not allocated to any standard pattern (even within one organization). Example: at my site some users have usernames composed of initials, others use first names, others use nicknames or abbreviations: this should really be altered to a uniform system. The most awkward ones to remember, though, are those sites who number their users (for example, while in Australia in summer 1988 I had the username apm822v). There is a clear trend in the U.K. for mail names to be of the form <initials>.familyname, so that I have become M.A.H.MacCallum for this purpose: these need not be the actual usernames, as the mail program simply looks them up in a table, and converts to the real username and machine. For example, is translated to by our site's central mail service. This trend is to be strongly encouraged in my view, and it is for this reason that I refer to the corresponding subfield in the tables as <mailusername> rather than <username>.

To combine <mailusername>s and <mailsitename>s the usual way is to write <mailusername>@<mailsite>, or, if there is a need to specify the routing, username%mailsite%site2@site3, meaning that the mail is to be sent first to site3, from there to site2, and finally to mailsite where the user really is. In RFC 822 the route specification is different from this and looks like (@site3,@site2,@mailsite:username): it is partly for logical consistency with this scheme that JANET uses the opposite ordering of domains from the Internet, although RFC 822 does not.

4. Addressing sites on one network from another

[Before reading on, note the remarks on mailer configuration in section 1: if your local network experts are good enough you will not need to read this section.] The two factors in passing messages from one network to another are to know which is the machine that is the 'gateway' (i.e. the one directly connected to both networks which does any necessary re-formatting of the mail headers and changing of transmission protocols) and how to give the address so that the gateway handles it correctly.

For example, BITNET/EARN/NETNORTH and JANET are connected at exactly one point, the machine called UKACRL on BITNET and on JANET. This machine is at Rutherford Laboratory. The gateway assumes that addresses supplied from the U.K. side will use Janet ordering of domains throughout, and that addresses supplied from the BITNET side will use RFC 822 ordering. Thus senders from BITNET to JANET should address me as whereas I could address Tevian Dray at his edu address as if I wished to use that routing. (There used to be a small complication in that some BITNET sites used AC.UK as a substitute for UKACRL, but I believe this practice has ceased.)

It should be noted that although UKACRL is not directly on other nets it has set up its tables to allow relays through BITNET to other nets, in a convenient way. The list of such nets is long and includes, for example, the edu and gov domains of Internet and

Certain pairs of networks have many interconnections, e.g. BITNET and Internet, UUCP and Internet, Janet and UUCP. However, there is often just one standard gateway which is used by people setting up mailer configuration tables as described in section 1 above. I shall not try to list all of these, but give a few. Longer lists are available in the Quartermain/Hoskins article and elsewhere.

Some important gateways (named in the order in which the networks are given if the names are different on the two nets) are

CUNYVM =        BITNET to/from Internet              Internet to/from JANET =    JANET to/from UUCP
CERNVAX                to/from BITNET
PSUVAX1                         UUCP to/from BITNET                    UUCP to/from Internet
LBL (=                 BITNET to/from HEPNET                 EAN and X.400 to/from JANET = UKACRL       JANET to/from BITNET
utokyo-relay                    JUNET to/from CSnet

Note: I am told that to reach JANET from JUNET the syntax (for example) works

Bibliography on e-mail networks

[This comes from an e-mail by Charlotte Mooers , who is one of the principal people at CREN]

The first five books are concerned with the Internet and the networks that can exchange electronic mail with it. The final book describes the PC-based bulletin boards and commercial services that are available to anyone who has a personal computer and a modem.

Quarterman, John S., The Matrix: Computer Networks and Conferencing
  Systems Worldwide, Digital Press, 12 Crosby Drive, Bedford, MA  
  01730, 1990.
     A comprehensive reference book, with extensive bibliographies
     and excellent introductory material.  The author, formerly with
     the University of Texas, has long experience in many capacities
     on the Arpanet, the Internet, and uucp.

LaQuey, Tracey, Users' Directory of Computer Networks, to be published
  by Digital Press, May 15, 1990.
     Previous editions have been published by the University of Texas      
     for users of THEnet (The Texas Higher Education Network).  This      
     book contains detailed listings of individual hosts, network  
     numbers, and domains in networks accessible from the Internet,
     plus descriptions of the networks.

Frey, Donnalyn, and Adams, Rick, !@%:: A Directory of Electronic Mail
  Addressing and Networks, O'Reilly & Associates, Inc. 632 Petaluma Ave.,  
  Sebastopol, CA 95472, 1989; New edition to be published this summer.
     An attractive handbook of world-wide networks, which features
     computer-generated maps, and concise descriptions.  Rick Adams is  
     a moving spirit of UUNET.

Goos, Anke, and Karrenberg, Daniel, The European R&D E-mail Directory,
  European UNIX systems Users Group (euug), Owles Hall, Buntingford,  
  Herts, SG9 9PL, UK, 1988.
     Detailed listings of the hosts in the EARN (.bitnet), EUUG (.uucp),  
     and United Kingdom networks, with an introductory discussion of
     network names and problems from the European point of view.

Glossbrenner, Alfred, The Complete Handbook of Personal Computer
  Communications: The Bible of the Online World, 3rd edition, St.
  Martin's Press, 175 Fifth Ave., New York, NY 10010, 1990.
     Comprehensive information about commercial networks and dial-in
     hosts in the United States and Canada.  This is a different world
     from the one covered by the previous books.

Appendix: Format of the surface mail address file

The format of this file is as follows. The separator between records will be a blank line and the records will be multiline.
1. The first line will always be the indexing name, terminated by a new line. Subsequent lines of a record will be indented, to preserve human readability.
2, 3 and 4. The surface mail address will be three fields, terminated by a &, in which each component within a field will be on a new line. The fields will be (2) Department and Institution, or equivalent (3) Street, Town and Province (4) Country
5, 6 and 7. Following this will come the Phone, Telex, and Fax numbers, each as a separate field.
8. A comment field. This may contain any additional information concerning users at that site. If you request that particular information for your site should be added, please make it very brief. Suitable types of information might be individual extension phone numbers of users, the need for accents in users' names, or the fact that gr-list mail is only sent to one of the users listed.