M.A.H. MacCallum
Queen Mary and Westfield College, Mile End Road
LONDON E1 4NS, U.K.
E-mail: M.A.H.MacCallum@qmw.ac.uk
Last update: 28 May 1993
Contents
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)
infn.it (INFNET, ASTRONET) (Italy)
JUNET (Japan)
JANET (U.K.)
3. Mail sites and usernames
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 uk.ac.earn-relay . 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 x%y.bitnet@earn-relay.ac.uk 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 britain.eu.net (=gbnet.ac.uk) 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.
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!).
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 relay.cs.net). 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).
SPAN is a similar net for Space Physics.
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 foo.bar.edu is not registered but bar.edu is a registered gateway, the mailer sends the mail to bar.edu and assumes bar.edu 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 nsfnet-relay.ac.uk for some time did not, while the EARN gateway at earn-relay.ac.uk 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!
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!britain.eu.net!uk.ac.qmw.maths!mm
Note that at uknet, and uk.ac.qmw.maths 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 jato.jpl.nasa.gov (at my request) has made this unnecessary now, but if a future similar problem arises I will apply the same method again.
See the note at the end of the ARPA entry. It applies to EAN too.
Since January 1992 there has been an IP service run over Janet called JIPS and many sites have effectively become IP rather than X.25 or X.400 sites.
The registered NRS names now include a few outside the U.K. with top domain other than uk, for example, some in New Zealand with top domain nz, and others at cern and in the au domain.
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 maths.qmw.ac.uk 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 qmw.ac.uk. 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. watmath.waterloo.edu 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, M.A.H.MacCallum@qmw.ac.uk is translated to mm@maths.qmw.ac.uk 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.
For example, BITNET/EARN/NETNORTH and JANET are connected at exactly one point, the machine called UKACRL on BITNET and uk.ac.earn-relay 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 M.A.H.MacCallum%qmw.ac.uk@UKACRL whereas I could address Tevian Dray at his edu address as tevian%edu.orst.math@uk.ac.earn-relay 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 infn.it.
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 = cunyvm.cuny.edu BITNET to/from Internet nsfnet-relay.ac.uk Internet to/from JANET britain.eu.net = gbnet.ac.uk JANET to/from UUCP CERNVAX infn.it to/from BITNET PSUVAX1 UUCP to/from BITNET uunet.uu.net UUCP to/from Internet LBL (= lbl.gov) BITNET to/from HEPNET mhs-relay.ac.uk EAN and X.400 to/from JANET earn-relay.ac.uk = UKACRL JANET to/from BITNET utokyo-relay JUNET to/from CSnetNote: I am told that to reach JANET from JUNET the syntax (for example) mm@maths.qmw.ac.uk.janet works
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.