| Here is a document taken from the public domain (that's what my local
comms. man said - who am I to argue!). The information looks useful
but I haven't read all of it and can't pretend to understand all that
I have read.
I was told that the best way of getting an address is for the potential
recipient to send a message, then just answer it. Someone has got to
know what they're doing to get the ball rolling.
I have enclosed the whole document as it might be useful to you
elsewhere as well.
At the end of the document I have tacked an example.
Dave
================================================================
THE DECWRL MAIL GATEWAY
Last updated 2 September 1989 at 15:20
This document is also available as a PostScript file DECWRL::GATEWAY.PS
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. The gateway currently performs no screening,
editing, or checking of mail flowing in either direction, so we depend on the
integrity of our user community to protect us from problems. 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 (September 1989) is about 10,000 mail messages per
day and about 3,000 USENET messages per day. Gatewayed mail traffic has doubled
every year since 1983. decwrl is currently a Vax 8530 computer with 64
megabytes of main memory, 2500 megabytes of disk space, 8 9600-baud (Telebit)
modem ports, and various network connections. We will shortly be upgrading to
a Vax 8650 system.
ADMINISTRATION
The gateway has no dedicated staff. It is operated by volunteers who have other
work to do. We do try to be helpful, though.
If you have problems relating to electronic mail, e.g. addressing difficulties
or delivery problems, please send mail to DECWRL::POSTMASTER from Digital's
Easynet, or to [email protected] from IP networks and from outside
Digital.
If you have problems relating to the gateway itself, e.g. error messages that
you don't understand, or questions about its technology or configuration,
please send mail to DECWRL::ADMIN from Digital's Easynet, or to
[email protected] from IP networks and from outside Digital.
We also post periodic status reports to the USENET newsgroup dec.general.
Various helpful VMS users usually copy these reports to the GATEWAYS vaxnotes
conference within a day or two.
We are not easy to reach by telephone. If you are having trouble getting mail
through to DECWRL, you obviously cannot send mail to ask about it. Any user in
the Palo Alto cluster can be reached by sending mail to any node in the Palo
Alto cluster; other large nodes here are JOVE, GILROY, JUMBO, BIGTOP, and
DECWSE.
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 double quotes 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!ed"
To: nm%DECWRL::"[email protected]"
To: nm%DECWRL::"[email protected]"
To: nm%DECWRL::"[email protected]"
To: nm%DECWRL::"<@star.stanford.edu:HAK3::JONES>"
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.
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 [email protected], 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!ed"@decwrl.dec.com
To: "postmaster%g.gp.cs.cmu.edu"@decwrl.dec.com
To: "listsrv%CUNYVM.bitnet"@decwrl.dec.com
To: "[email protected]"@decwrl.dec.com
To: <@decwrl.dec.com,@star.stanford.edu:HAK3::JONES>
Sending from All-in-1
We actually don't know a thing about All-in-1, and would be grateful if
somebody who was expert in its use could send us some instructions for All-in-1
use of our gateway.
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 [email protected]. The Internet itself cannot be
used for commercial purposes.
UUCP A very primitive network with no management, built 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. Some Digital employees have
Fidonet computers at home. We are unsure of the status of using
Fidonet for commercial purposes, nor are we sure of its
efficacy.
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 "[email protected]" 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
[email protected] or [email protected]. The Internet convention is to say
[email protected], 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 The BITNET
.MAILNET The MAILNET
.?? 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 the 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 [email protected]. 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%[email protected]. From uucp mailers, the
address would be decwrl!demo.enet!guest. Some Internet mailers require the form
<@decwrl.dec.com:[email protected]>. (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.
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 [email protected]. Mail received from the All-in-1 mailer 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.
At the end of this file is a list of the uucp nodes to which decwrl currently
has a working connection.
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 consisting primarily of IBM computers. A
native BITNET address is something like "USER at MUMBLEVM", but when translated
into our Internet format it becomes [email protected]. 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
[email protected]. To send a message to Fred Smith at Fidonet
node 987/654.32, use address [email protected]. 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.
Appendix: list of UUCP neighbor sites
This table shows most of the sites that decwrl dials directly via uucp. You
may find it useful to help you construct a uucp route to a particular
destination. Those sites marked with "*" are major uucp routing nodes. You
should prefer uucp routes that use these sites as the first hop from decwrl.
Case is significant in uucp host names.
3comvax 3Com Corporation, Santa Clara, CA
abvax Allen-Bradley Company, Highland Heights, OH
acad Autodesk, Inc, Sausalito, CA
adobe Adobe Systems Inc., Mountain View, CA
alberta University of Alberta, Edmonton, Alberta, Canada
allegra AT&T Bell Laboratories, Murray Hill, NJ
*amdahl Amdahl Corp., Sunnyvale, CA
amdcad Advanced Micro Devices, Sunnyvale, CA
ames NASA Ames Research Center, Mountain View, CA
*apple Apple Computers, Cupertino, CA
ardent Ardent Computer Corp., Sunnyvale, CA
argosy MassPar Computer Corp., Sunnyvale, CA
atha Athabasca University, Athabasca, Alberta, Canada
athertn Atherton Technology, Sunnyvale, CA
*att AT&T Bell Laboratories, Columbus, Ohio
avsd Ampex Corporation, Redwood City, CA
cae780 Tektronix Inc. (Santa Clara Field Office) Santa Clara, CA
chip M/A-COM Government Systems, San Diego, CA
claris Claris Corporation, Mountain View, CA
daisy Daisy Systems, Mountain View, CA
decuac DEC/Ultrix Applications Ctr, Landover, MD
*decvax DEC/Ultrix Engineering, Nashua, NH
dsinc Datacomp Systems, Inc, Huntington Valley, PA
eda EDA Systems Inc., Santa Clara, CA
emerald Emerald Systems Corp., San Diego, CA
escd Evans and Sutherland Computer Division, Mountain View, CA
esunix Evans and Sutherland Corp., Salt Lake City, UT
fluke John Fluke Manufacturing, Everett, WA
gryphon Trailing Edge Technology, Redondo Beach, CA
handel Colorodo State Univ., CS Dept., Ft. Collins, CO
hoptoad Nebula Consultants, San Francisco, CA
*hplabs Hewlett Packard Research Labs, Palo Alto, CA
ide Interactive Development Environments, San Francisco, CA
idi Intelligent Decisions, Inc., San Jose, CA
imagen Imagen Corp., Santa Clara, CA
intelca Intel Corp., Santa Clara, CA
limbo Intuitive Systems, Los Altos, CA
logitech Logitech, Inc., Palo Alto, CA
megatest Megatest Corp., San Jose, CA
metaphor Metaphor Corp., Mountain View, CA
microsoft Microsoft, Bellevue, WA
mindcrf Mindcraft Corp., Palo Alto, CA
mips MIPS Computer Systems, Mountain View, CA
mntgfx Mentor Graphics Corp., Beaverton, OR
mordor Lawrence Livermore National Lab, Livermore, CA
mtu Michigan Tech Univ., Houghton, MI
mtxinu Mt. Xinu, Berkeley, CA
nsc National Semiconductor Corp., Sunnyvale, CA
oli-stl Olivetti Software Techn. Lab, Menlo Park, CA
oracle Oracle Corp., Belmont, CA
*pacbell Pacific Bell, San Ramon, CA
parcplace Parc Place Systems, Palo Alto, CA
purdue Purdue University, West Lafayette, IN
*pyramid Pyramid Technology Corporation, Mountain View, CA
qubix Qubix Graphic Systems, San Jose, CA
quintus Quintus Computer Systems, Mountain View, CA
research AT&T Bell Laboratories, Murray Hill, NJ
riacs Res.Inst. for Adv. Compu. Sci., Mountain View, CA
rtech Relational Technology Inc., Alameda, CA
sci Silicon Compilers, San Jose, CA
sco Santa Cruz Operation, Santa Cruz, CA
sequent Sequent Computer System, Inc., Beaverton, OR
sgi Silicon Graphics, Inc., Mountain View, CA
shell Shell Development Corp., Houston, TX
simpact Simpact Assoc., San Diego, CA
sjsca4 Schlumberger Technologies, San Jose, CA
sun Sun Microsystems, Mountain View, CA
td2cad Intel Corp., Santa Clara, CA
teraida Teradyne EDA Inc., Santa Clara, CA
theta Process Software Inc., Wellesley, MA
turtlevax CIMLINC, Inc, Palo Alto, CA
*ucbvax University of California, Berkeley, CA
utcsri Univ. of Toronto, Computer Science, Toronto, CA
vlsisj VLSI Technology Inc., San Jose, CA
wyse Wyse Technology, San Jose, CA
zehntel Zehntel, Inc., Walnut Creek, CA
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
Received: by decpa.pa.dec.com; id AA02713; Tue, 28 Aug 90 08:23:46 -0700
Received: by mcsun.EU.net via EUnet; Tue, 28 Aug 90 17:23:39 +0200 (MET)
Message-Id: <[email protected]>
Received: from svax05.pcr.co.uk by kestrel.Ukc.AC.UK via PSS (UKC CAMEL FTP)
id aa14747; 28 Aug 90 15:55 BST
Date: Tue, 28 AUG 90 15:56:44 GMT
From: [email protected]
To: EASTON <suburb::EASTON>
Subject: just back from my hols!
Reply-To: williams_b <[email protected]>
X-Usenet: ..mcsun!ukc!pfizer!williams_b
X-Name: Brian Williams
X-Service: Sandwich VAX 8600
X-Address: Pfizer Central Research, Sandwich, Kent CT13 9NJ UK
X-Telephone: Sandwich (0304) 616223
X-Uk: Brian Williams <uk.co.pcr.svax05> <uk pss 234216700127>
================================================================
An example: From an All-IN-1 account
Nickname entry
Nickname: PETE
Mail Address: "[email protected]"@DECWRL@MRGATE@UCO
|