vixie@pa.dec.com (Paul Vixie) (06/07/91)
In article <17582.284cdebb@ul.ie> bourkej@ul.ie writes:
# How do you mail a DEC employee on DEC's private network.
Here is gatekeeper.dec.com:~ftp/gateway.doc, also DECWRL::"/gateway.doc"
if you are on Digital's internal corporate DECnet ("Easynet").
Cheers,
Paul Vixie
DEC Western Research Lab <vixie@pa.dec.com> <paul@vixie.sf.ca.us>
Palo Alto, California, USA ...!decwrl!vixie ...!vixie!paul
DECWRL::"GATEWAY.DOC" Last updated 22 January 1991 at 10:28
Please check for more recent editions
This document is also available as a PostScript file DECWRL::"GATEWAY.PS"
THE DECWRL MAIL GATEWAY
INTRODUCTION
DECWRL is a mail gateway computer operated by Digital's Western Research
Laboratory in Palo Alto, California. Its purpose is to support the interchange
of electronic mail between Digital and the "outside world".
decwrl is connected to Digital's Easynet, and also to a number of different
outside electronic mail networks. Digital users can send outside mail by
sending to DECWRL::"outside-address", and digital users can also receive mail
by having your correspondents route it through decwrl. The details of incoming
mail are more complex, and are discussed below.
It is vitally important that Digital employees be good citizens of the networks
to which we are connected. We depend on the integrity of our user community to
ensure that tighter controls over the use of the gateway are not required. The
most important rule is "no chain letters", but there are other rules depending
on whether the connected network that you are using is commercial or
non-commercial.
The current traffic volume (January 1991) is about 20,000 mail messages per day
and about 5,000 USENET messages per day. Gatewayed mail traffic has doubled
every year since 1983. decwrl is currently a pair of DECsystem 5400's, each
with 64 megabytes of main memory, 3000 megabytes of disk space, 12 19200-baud
(Telebit T2500) modem ports, and various network connections. We run Ultrix
3.1D as the base operating system.
ADMINISTRATION
The gateway has engineering staff, but no administrative or clerical staff. We
work hard to keep it running, but we do not have the resources to answer
telephone queries or provide tutorials in its use.
We post periodic status reports to the USENET newsgroup dec.general, and more
technical reports to dec.mail.config. Various helpful people usually copy these
reports to the VAXNOTES "gateways" conference within a day or two.
If you have technical problems with the gateway, please send electronic mail to
the mailing list DECWRL::ADMIN (admin@decwrl.dec.com from IP sites).
We ask that you consider the telephone to be an instrument of desperate last
resort in trying to contact us. All of the gateway staff keep unusual
schedules, are not often at their desks, and when a call comes through, the
secretary or guard who answers it must decide whether the call is urgent enough
to have one of us tracked down or paged.
If the problem that you would like to report is that you cannot get electronic
mail to decwrl, please try sending to the mailing list "gatekeepers" at one of
the other major nodes in the Palo Alto cluster. If you cannot reach
JOVE::GATEKEEPERS or GILROY::GATEKEEPERS or DECSRC::GATEKEEPERS, the problem is
almost certainly not in Palo Alto, so talking to us on the phone isn't going to
help solve it.
HOW TO SEND MAIL
DECWRL is connected to quite a number of different mail networks. If you were
logged on directly to it, you could type addresses directly, e.g.
To: strange!foreign!address.
But since you are not logged on directly to the gateway, you must send mail so
that when it arrives at the gateway, it will be sent as if that address had
been typed locally.
Sending from VMS
If you are a VMS user, you should use NMAIL, because VMS mail does not know how
to requeue and retry mail when the network is congested or disconnected. From
VMS, address your mail like this:
To: nm%DECWRL::"strange!foreign!address"
The quote characters (") are important, to make sure that VMS doesn't try to
interpret strange!foreign!address itself. If you are typing such an address
inside a mail program, it will work as advertised. If you are using DCL and
typing directly to the command line, you should beware that DCL likes to remove
quotes, so you will have to enclose the entire address in quotes, and then put
two quotes in every place that one quote should appear in the address:
$ mail test.msg "nm%DECWRL::""foreign!addr""" /subj="hello"
Note the three quotes in a row after foreign!addr. The first two of them are
doubled to produce a single quote in the address, and the third ends the
address itself (balancing the quote in front of the nm%).
Here are some typical outgoing mail addresses as used from a VMS system:
To: nm%DECWRL::"ucbvax!mtxinu!rjz"
To: nm%DECWRL::"postmaster@g.gp.cs.cmu.edu"
To: nm%DECWRL::"posix!george@uunet.uu.net"
To: nm%DECWRL::"listsrv@CUNYVM.bitnet"
To: nm%DECWRL::"Bob.Jones@f654.n987.z1.fidonet.org"
Sending from Ultrix
If your Ultrix system has been configured for it, then you can, from your
Ultrix system, just send directly to the foreign address, and the mail software
will take care of all of the gateway routing for you. Most Ultrix syustems in
Corporate Research and in the Palo Alto cluster are configured this way.
To find out whether your Ultrix system has been so configured, just try it and
see what happens. If it doesn't work, you will receive notification almost
instantly.
NOTE: The Ultrix mail system is extremely flexible; it is almost
completely configurable by the customer. While this is valuable to
customers, it makes it very difficult to write global instructions for
the use of Ultrix mailers, because it is possible that the local
changes have produced something quite unlike the vendor-delivered
mailer. One of the popular changes is to tinker with the meaning of
quote characters (") in Ultrix addresses. Some systems consider that
these two addresses are the same:
site1!site2!user@host.dec.com
and
"site1!site2!user"@host.dec.com
while others are configured so that one form will work and the other
will not. All of our examples use the quotes. If you have trouble
getting the examples to work, please try them again without the quotes.
Perhaps your Ultrix system is interpreting the quotes differently.
If your Ultrix system has an IP link to Palo Alto (type
"/etc/ping decwrl.dec.com" to find out if it does), then you can route your
mail to the gateway via IP. This has the advantage that your Ultrix mail
headers will reach the gateway directly, instead of being translated into
DECNET mail headers and then back into Ultrix at the other end. Do this as
follows:
To: "alien!address"@decwrl.dec.com
The quotes are necessary only if the alien address contains a ! character, but
they don't hurt if you use them unnecessarily. If the alien address contains
an "@" character, you will need to change it into a "%" character. For example,
to send via IP to joe@widget.org, you should address the mail
To: "joe%widget.org"@decwrl.dec.com
If your Ultrix system has only a DECNET link to Palo Alto, then you should
address mail in much the same way that VMS users do, save that you should not
put the nm% in front of the address:
To: DECWRL::"strange!foreign!address"
Here are some typical outgoing mail addresses as used from an Ultrix system
that has IP access. Ultrix systems without IP access should use the same syntax
as VMS users, except that the nm% at the front of the address should not be
used.
To: "ucbvax!mtxinu!rjz"@decwrl.dec.com
To: "postmaster%g.gp.cs.cmu.edu"@decwrl.dec.com
To: "listsrv%CUNYVM.bitnet"@decwrl.dec.com
To: "posix!george%uunet.uu.net"@decwrl.dec.com
To: "Bob.Jones@f654.n987.z1.fidonet.org"@decwrl.dec.com
Sending from ALL-IN-1
ALL-IN-1 is an integrated software package that is very popular with Digital's
customers and is widely used by non-technical people inside Digital. Normally
it is only used to communicate with other ALL-IN-1 users, but there is a
special VMS-based gateway that can be used to route ALL-IN-1 mail to other
places.
The DECWRL staff have never used ALL-IN-1 ourselves, so we rely on reports from
ALL-IN-1 users to keep us informed of the details of its use. The instructions
below are for ALL-IN-1 version 2.3.
If you are sending to a foreign address that contains no "@" characters, and if
your node runs the MRGATE gateway software, then you can send to:
To: "strange!foreign!address" @ DECWRL @ MRGATE
If your node does not run the MRGATE mail gateway, then you need to route it to
one that does:
To: "strange!foreign!address" @ DECWRL @ MRGATE @ local-node
Here "local-node" is the name of the node local to you that runs MRGATE.
The path between ALL-IN-1 mail and the Internet is long and error-prone. It is
passed through a message router, which routes it into VMS VAXMAIL, and then out
to Ultrix. Ultrix then converts again from VAXMAIL format into Internet format.
Very often your return address will be mangled or lost in the process; it is
always best to include your return address in the body of the message and to
tell your correspondents that "reply" will not work. Your return address is:
First.Last@facility.mts.dec.com
for example,
Ken.Olsen@MLO.mts.dec.com
DETAILS OF USING OTHER NETWORKS
All of the world's computer networks are connected together, more or less, so
it is hard to draw exact boundaries between them. Precisely where the Internet
ends and UUCP begins is a matter of interpretation.
For purposes of sending mail, though, it is convenient to divide the network
universe into these categories:
Easynet Digital's internal DECNET network. Characterized by addresses
of the form NODE::USER. Easynet can be used for commercial
purposes.
Internet A collection of networks including the old ARPAnet, the NSFnet,
the CSnet, and others. Most international research,
development, and educational organizations are connected in
some fashion to the Internet. Characterized by addresses of the
form user@site.subdomain.domain. The Internet itself cannot be
used for commercial purposes.
CSNET The CSNET network is completely reachable via the Internet (see
above), and the CSNET organization is in the process of merging
with the BITNET organization (see below).
UUCP A very primitive network with no management, built largely with
auto-dialers phoning one computer from another. Characterized
by addresses of the form place1!place2!user. The UUCP network
can be used for commercial purposes provided that none of the
sites through which the message is routed objects to that.
USENET Not a network at all, but a layer of software built on top of
UUCP and Internet.
BITNET An IBM-based network linking primarily educational sites.
Digital users can send to BITNET as if it were part of
Internet, but BITNET users need special instructions for
reversing the process. BITNET cannot be used for commercial
purposes.
Fidonet A network of personal computers. We are unsure of the status
of using Fidonet for commercial purposes, nor are we sure of
its efficacy. Most Fidonet computers are bulletin board systems
and not mail relay systems.
DOMAINS AND DOMAIN ADDRESSING
There is a particular network called "the Internet"; it is somewhat related to
what used to be "the ARPAnet". The Internet style of addressing is flexible
enough that people use it for addressing other networks as well, with the
result that it is quite difficult to look at an address and tell just what
network it is likely to traverse. But the phrase "Internet address" does not
mean "mail address of some computer on the Internet" but rather "mail address
in the style used by the Internet". Terminology is even further confused
because the word "address" means one thing to people who build networks and
something entirely different to people who use them. In this document an
"address" is something like "reid@decwrl.dec.com" and not "192.1.24.177" (which
is what network engineers would call an "internet address").
The Internet naming scheme uses hierarchical domains, which despite their title
are just a bookkeeping trick. It doesn't really matter whether you say
NODE::USER or USER@NODE, but what happens when you connect two companies'
networks together and they both have a node ANCHOR?? You must, somehow, specify
which ANCHOR you mean. You could say ANCHOR.DEC::USER or DEC.ANCHOR::USER or
USER@ANCHOR.DEC or USER@DEC.ANCHOR. The Internet convention is to say
USER@ANCHOR.DEC, with the owner (DEC) after the name (ANCHOR).
But there could be several different organizations named DEC. You could have
Digital Equipment Corporation or Down East College or Disabled Education
Committee. The technique that the Internet scheme uses to resolve conflicts
like this is to have hierarchical domains. A normal domain isn't DEC or
STANFORD, but DEC.COM (commercial) and STANFORD.EDU (educational). These
domains can be further divided into ZK3.DEC.COM or CS.STANFORD.EDU. This
doesn't resolve conflicts completely, though: both Central Michigan University
and Carnegie-Mellon University could claim to be CMU.EDU. The rule is that the
owner of the EDU domain gets to decide, just as the owner of the CMU.EDU gets
to decide whether the Electrical Engineering department or the Elementary
Education department gets subdomain EE.CMU.EDU.
The domain scheme, while not perfect, is completely extensible. If you have two
addresses that can potentially conflict, you can suffix some domain to the end
of them, thereby making, say, DECWRL.UUCP be somehow different from
DECWRL.ENET.
decwrl's entire mail system is organized according to Internet domains, and in
fact we handle all mail internally as if it were Internet mail. Incoming mail
is converted into Internet mail, and then routed to the appropriate domain; if
that domain requires some conversion, then the mail is converted to the
requirements of the outbound domain as it passes through the gateway. For
example, we put Easynet mail into the domain ENET.DEC.COM, and we put BITNET
mail into the domain BITNET.
The "top-level" domains supported by the decwrl gateway are these:
.EDU Educational institutions
.COM Commercial institutions
.GOV Government institutions
.MIL Military institutions
.ORG Various organizations
.NET Network operations
.BITNET BITNET and CSNET (now combined)
.?? 2-character country code for routing to other countries
.OZ Part of the Australian (.AU) name space.
2-character country codes include UK (United Kingdom), FR (France), IT (Italy),
CA (Canada), AU (Australia), etc. These are with certain exceptions standard
ISO 2-character country codes.
MAILING TO EASYNET
To mail to user GUEST at node DEMO (which is DECNET address DEMO::GUEST),
Internet mail should be addressed to guest@demo.enet.dec.com. Easynet
addresses are not case-dependent; DEMO and demo are the same node name and
GUEST and guest are the same user name.
Sites that are not directly connected to the Internet may have difficulty with
Internet addresses like demo.enet.dec.com. They can send into the Easynet by
explicitly routing the mail through DECWRL. From domain-based Internet mailers,
the address would be guest%demo.enet@decwrl.dec.com. From uucp mailers, the
address would be decwrl!demo.enet!guest. Some Internet mailers require the form
<@decwrl.dec.com:guest@demo.enet>. (This last form is the only technically
correct form of explicit route, but very few Internet sites support it.)
The decwrl gateway also supports various obsolete forms of addressing that are
left over from the past. In general we support obsolete address forms for two
years after the change, and then remove it.
MAILING TO DIGITAL ALL-IN-1 USERS
Some Easynet users do not have a direct DECNET node address, but instead read
their mail with All-in-1, which uses addresses of the form "James Guest @UCO".
Here "UCO" is a Digital location code name. To route mail to such people, send
to James.Guest@UCO.MTS.DEC.COM. Here "MTS" is the Message Transport Service,
which is used to deliver mail to ALL-IN-1 and other users.
If your correspondent does not actually use ALL-IN-1 to read mail, then you
should, if possible, avoid using MTS addresses when sending from outside
Digital. Such mail is routed from the Internet through DECWRL, from DECWRL via
VAXMAIL to an MRGATE message router gateway, into MTS, and then through another
MRGATE at the receiving end, back from MTS into VAXMAIL again, where it is
finally delivered to the end node. The second instance of MRGATE (the one that
gateways the message out of MTS back into VAXMAIL) often rejects such messages
with a "return address is too complex" error. If you get such an error, this is
an indication that your correspondent is using VAXMAIL and not ALL-IN-1; you
should use the VAXMAIL address directly.
Mail received via Internet to the MTS domain is unreplyable, and in fact unless
the respondent tells you his return address in the body of the message, it is
not normally possible even to puzzle out the return address by studying the
message header. Mail from ALL-IN-1 to Easynet passes through a gateway program
that does not produce valid return addresses.
MAILING TO THE INTERNET
decwrl's mailer is an Internet mailer, so to mail to an Internet site, just use
its address. If you are having trouble determining the Internet address, you
might find that the Ultrix host table /etc/hosts.txt is useful. If you can't
find one anywhere else, there's one on decwrl. See the comments above under
"how to send mail" for details about making sure that the mail program you are
using has correctly interpreted an address.
MAILING TO UUCP
UUCP mail is manually routed by the sender, using ! as the separator character.
Thus, the address xxx!yyy!zzz!user means to dial machine xxx and relay to it
the mail, with the destination address set to yyy!zzz!user. That machine in
turn dials yyy, and the process repeats itself.
To correctly address uucp mail, you must know a working path through the uucp
network. The database is sufficiently chaotic that automatic routing does not
work reliably (though many sites perform automatic routing anyhow). The
information about uucp connectivity is distributed in the USENET newsgroup
comp.mail.maps; many sites collect this data and permit local queries of it.
If you would like to send uucp mail to some address zzz!user and you do not
know a path, the DECWRL gateway will route it for you using the aforementioned
public routing tables. Because the data in those tables is not reliable, we
cannot offer any guarantees that the autorouting will succeed and we cannot
respond to nondelivery complaints involving the autorouter. If you know a
reliable route to some site it is better to use that route rather than rely on
the autorouter.
Specifically, if DECWRL receives a uucp mail message whose first hop is to a
site that DECWRL does not have a link to, then it will add an
automatically-generated route to the front of that address. Otherwise the
address that you provide will be left intact.
MAILING TO USENET
Usenet is not a network. It's a software layer, and it spans several networks.
Many people say "Usenet" when they really mean uucp. You can post a message to
a Usenet newsgroup by mailing it to "name.usenet" at decwrl. For example,
mailing from VMS to this address:
nm%DECWRL::"rec.autos.tech.usenet"
causes the mail message to be posted as an article to the Usenet newsgroup
rec.autos.tech. It is better to use Usenet software for posting articles, as
more features are available that way, such as restricted distributions,
crossposting, and cancellation of "wish I hadn't sent that" articles.
MAILING TO BITNET
Legend has it that the "BIT" in BITNET stands for "Because It's There" or
"Because It's Time" It is a network that originally consisted primarily of IBM
computers, but in recent years has been dominated by VMS VAXes. A native BITNET
address is something like "USER at MUMBLEVM", but when translated into our
Internet format it becomes user@mumblevm.bitnet. Once translated into Internet
form, a BITNET address is used just like any other Internet address.
MAILING TO FIDONET
By comparison with the other linked networks, Fidonet has an addressing
complexity bordering on the bizarre. The Fidonet people have provided us with
this description:
Each Fidonet node is a member of a "network", and may have subsidiary nodes
called "point nodes". A typical Fido address is "1:987/654" or "987/654"; a
typical Fido "point node" address is "1:987/654.32" or "987/654.32". This is
zone 1, network 987, Fido (node) 654, "point node" 32. If the zone number is
missing, assume it is zone 1. The zone number must be supplied in the outgoing
message.
To send a message to Bob Jones on Fidonet address 1:987/654, use the address
Bob.Jones@f654.n987.z1.fidonet.org. To send a message to Fred Smith at Fidonet
node 987/654.32, use address Fred.Smith@p32.f654.n987.z1.fidonet.org. Use them
just like any other Internet address.
Sometimes the return addresses on messages from Fidonet will look different.
You may or may not be able to reply to them.
MAILING TO MCI MAIL
MCI Mail is a commercial communication service that offers a wide range of
electronic messaging services to its subscribers. To address a message to an
MCI Mail subscriber, suffix "@mcimail.com" to the user name, to the 7-digit MCI
ID number, or to the subscriber's registered formal name. For example, Harry
Bovik could be addressed in any of the following ways:
123-4567@MCIMail.com
HQBovik@MCIMail.com
Harry_Bovik@MCIMail.com
Note that all blank spaces in the formal name must be replaced by underscores.
The most reliable delivery is by MCI ID number, and it should be used whenever
it is known.
MAILING TO COMPUSERVE
CompuServe is a commercial online data service that offers an electronic mail
capability in addition to its database offerings.
CompuServe subscribers are identified by a "User ID" that is two numbers
separated by a comma. For example, "31416, 3601" is a CompuServe user ID. You
can send mail to CompuServe customers by replacing the comma with a period and
suffixing "@compuserve.com": 31416.3601@compuserve.com.
Some organizations or companies contract with CompuServe to provide a mail
service for their entire organization. These are given a CompuServe "private
mail area", and will typically list their addresses in the form
"organization:name", such as "DECCA:M.JAGGER". To send mail to such an address,
send it to "name@organiation.CompuServe.com". For example, for the above-named
user you would send to "M.JAGGER@DECCA.CompuServe.com".
ANSWERS TO COMMON QUESTIONS
1. Q: Why does it take mail so long to get through decwrl? My messages
typically are delayed 3 or 4 hours, and I find this annoying.
A: For precisely the same reason that it takes so long to get from
Logan Airport to Marlboro in a car. There's a lot of mail traffic,
and the networks are usually pretty congested. Decwrl handles
20,000 or more mail messages on a typical business day; the
slightest hiccup in the network causes long backups. Surely you've
seen the same phenomenon on a busy highway when there is an accident
on the other side of the road. Everybody slows down, just a little,
to take a look at the accident, and as a result there is a 10-mile
traffic backup.
2. Q: The mail that I receive always has some junk at the end of it,
with the label "Internet headers". What does this mean and how can I
get rid of it?
A: The DECNET mail protocol allows for a very limited amount of
information to be sent about a mail message. It supports a "To:", a
"From:", an "Subj:", and (sometimes) a "Cc:" field. Any other
information must be passed as part of the message body.
The Internet mail protocol has many more standard header fields in
it, and gives users the ability to add their own header fields.
Sometimes there is valuable information contained in these
non-DECNET header fields, so they cannot be merely discarded. When
you buy a cut-up packaged chicken at the grocery store, the giblets
are usually packaged in with it, just on the off chance that you
might want them. It's easy for you to throw them away, but very hard
for you to recover them if somebody else has already thrown them
away. Internet mail headers are not unlike giblets. If we threw
them away, there is always the chance that you would come back and
ask us for them, which means that we would both have to save them
and also would have to answer requests for them.
3. Q: I use an Ultrix system, and I find that my mail doesn't work
properly for non-local recipients, especially through a mail
gateway. Is there a way to fix this?
A: The "sendmail.cf" file that is packaged with Ultrix is very
generic, and must normally be customized for any specific
application. It is not particularly suitable for use inside Digital.
A "sendmail.cf" file more suited to use inside Digital is available
as DECUAC::"/public/*.cf*".
4. Q: The mail gateway sometimes muddles files that I send through it.
For example, it turns copyright symbols into parentheses. Why can't
this be fixed?
A: There is no such thing as a copyright symbol in most parts of the
computer network world. It's part of the DEC character set. Many
other vendors don't recognize that character set, even though it is
an international standard. The thing about international standards
is that there are so many to choose from. The world of electronic
mail networks is currently based on the 7-bit ISO 646 (ASCII)
character set. There is no such character as Copyright, or Pound, or
1/2, in it. So we can't translate your use of such characters.
5. Q: I have real trouble sending VMS mail through decwrl sometimes. I
get error messages like "insufficient resources at remote node" or
"object not defined". Could you please fix this?
A: Those error messages are symptoms of congestion from too many
people using the network at once. To use the decwrl gateway
effectively from VMS you must use NMAIL. NMAIL can queue and retry
mail during congested periods. If you cannot or will not use NMAIL,
then you must keep retrying by hand; you will eventually get
through.
6. Q: I had trouble accessing the file GATEWAY.DOC; here is what
happened:
$ type decwrl::gateway.doc
%TYPE-W-OPENIN, error opening DECWRL::/GATEWAY.DOC as input
-RMS-F-SYN, file specification syntax error
Where did the "/" come from? What is the matter with the directory?
A: This is one of those situations that makes you appreciate how
well Ultrix and VMS work together when they do work together. This
time they don't.
The short answer is that you have to quote the "gateway.doc", this
way:
$ type decwrl::"gateway.doc"
For those of you with a penchant for horror stories, here is why the
"short way" doesn't work. The VMS "type" command first sends a
"directory" command to the remote site. This is so you can do things
like
type TEST.*
First, your computer sends DECWRL a "DIRECTORY TEST.*" command to
get a list of the files matching TEST.*, and then it opens and reads
each one in turn.
DECWRL is an Ultrix machine. Ultrix file names all begin with a "/"
character. Just as the "true name" of some VMS file "TEST.LIS" might
be "DSK3:[REID.TEMP]TEST.LIS;4", the "true name" of some Ultrix file
"test.lst" might be "/usr/users/reid/temp/test.lst". In the case of
the file "DECWRL::GATEWAY.DOC", the "true name" of the file is
"/gateway.doc".
The VMS system sends DECWRL a "directory gateway.doc" command, and
gets back a list of the names of the files that match it. This list
contains one name: /gateway.doc. The VMS machine then processes the
command "type DECWRL::/GATEWAY.DOC", which it parses as a null file
name with the /GATEWAY.DOC command qualifier. Failure.
But if you quote the file name:
type decwrl::"gateway.doc"
then it bypasses the file name expansion phase and just uses the
name as you type it, whereupon it works fine.
7. Q: Where can I turn for more information?
A: Several sources, none comprehensive. There are various USENET
newsgroups and VAX notesfiles that can be used to ask questions or
read answers. USENET Newsgroups dec.mail.config, dec.news.config,
dec.mail.software, and dec.ip are primary sources. The VAX notesfile
UPSAR::NEWS-BACKBONE also contains information about USENET inside
Digital.
The book "The Matrix", by John S. Quarterman (Digital Press)
explains the worldwide computer networks. The book named "!%@::", by
Donnalyn Frey and Rick Adams (O'Reilly and Associates) explains the
mail addressing syntax of all the world's electronic mail networks.
--
Paul Vixie
DEC Western Research Lab <vixie@pa.dec.com> <paul@vixie.sf.ca.us>
Palo Alto, California, USA ...!decwrl!vixie ...!vixie!paul