sources-request@mirror.UUCP (02/18/87)
Submitted by: Larry Auton <lda@clyde.att.com>
Mod.sources: Volume 8, Issue 68
Archive-name: smail2/Part02
#! /bin/sh
# This is a shell archive. Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
# If all goes well, you will see the message "End of shell archive."
# Contents: doc/domain.mm doc/paths.8 doc/smail.8 doc/rfc976.mm
# src/patchlevel MANIFEST
# Wrapped by rs@mirror on Mon Feb 9 17:09:59 1987
PATH=/bin:/usr/bin:/usr/ucb; export PATH
echo shar: extracting "'doc/domain.mm'" '(19036 characters)'
if test -f 'doc/domain.mm' ; then
echo shar: will not over-write existing file "'doc/domain.mm'"
else
sed 's/^X//' >doc/domain.mm <<'@//E*O*F doc/domain.mm//'
X.TL
XWhat is a Domain?
X.AU "Mark R. Horton" "" CB 59473 4276 2C-249 "(cbosgd!mark)"
X.AS 0 10
XIn the past, electronic mail has used many different kinds of syntax,
Xnaming a computer
Xand a login name on that computer. A new system, called ``domains'',
Xis becoming widely used, based on a heirarchical naming scheme.
XThis paper is intended as a quick introduction to domains. For more details,
Xyou should read some of the documents referenced at the end.
X.AE
X.MT 4 1
X.H 1 "Introduction"
X.P
XWhat exactly are domains? Basically, they are a way of looking at the world as
Xa heirarchy (tree structure). You're already used to using two tree
Xworld models that work pretty well: the telephone system and the post
Xoffice. Domains form a similar heirarchy for the electronic mail
Xcommunity.
X.P
XThe post office divides the world up geographically, first into
Xcountries, then each country divides itself up, those units subdivide,
Xand so on. One such country, the USA, divides into states, which divide
Xinto counties (except for certain states, like Louisiana, which divide
Xinto things like parishes), the counties subdivide into cities, towns,
Xand townships, which typically divide into streets, the streets divide
Xinto lots with addresses, possibly containing room and apartment
Xnumbers, the then individual people at that address. So you have an
Xaddress like
X.DS
X Mark Horton
X Room 2C-249
X 6200 E. Broad St.
X Columbus, Ohio, USA
X.DE
X(I'm ignoring the name ``AT&T Bell Laboratories'' and the zip code, which
Xare redundant information.) Other countries may subdivide differently,
Xfor example many small countries do not have states.
X.P
XThe telephone system is similar. Your full phone number might look
Xlike 1-614-860-1234 x234 This contains, from left to right, your
Xcountry code (Surprise! The USA has country code ``1''!),
Xarea code 614 (Central Ohio), 860 (a prefix in the Reynoldsburg
XC.O.), 1234 (individual phone number), and extension 234. Some phone
Xnumbers do not have extensions, but the phone system in the USA has
Xstandardized on a 3 digit area code, 3 digit prefix, and 4 digit phone
Xnumber. Other countries don't use this standard, for example, in the
XNetherlands a number might be +46 8 7821234 (country code 46, city code
X8, number 7821234), in Germany +49 231 7551234, in Sweden +31 80
X551234, in Britain +44 227 61234 or +44 506 411234. Note that the
Xcountry and city codes and telephone numbers are not all the same
Xlength, and the punctuation is different from our North American
Xnotation. Within a country, the length of the telephone number might
Xdepend on the city code. Even within the USA, the length of extensions
Xis not standardized: some places use the last 4 digits of the telephone
Xnumber for the extension, some use 2 or 3 or 4 digit extensions you
Xmust ask an operator for. Each country has established local
Xconventions. But the numbers are unambigous when dialed from
Xleft-to-right, so as long as there is a way to indicate when you are
Xdone dialing, there is no problem.
X.P
XA key difference in philosophy between the two systems is evident from
Xthe way addresses and telephone numbers are written. With an address,
Xthe most specific information comes first, the least specific last.
X(The ``root of the tree'' is at the right.) With telephones, the least
Xspecific information (root) is at the left. The telephone system was
Xdesigned for machinery that looks at the first few digits, does
Xsomething with it, and passes the remainder through to the next level.
XThus, in effect, you are routing your call through the telephone
Xnetwork. Of course, the exact sequence you dial depends on where you
Xare dialing from - sometimes you must dial 9 or 8 first, to get an
Xinternational dialtone you must dial 011, if you are calling locally
Xyou can (and sometimes must) leave off the 1 and the area code. (This
Xmakes life very interesting for people who must design a box to call
Xtheir home office from any phone in the world.) This type of address
Xis called a ``relative address'', since the actual address used depends
Xon the location of the sender.
X.P
XThe postal system, on the other hand, allows you to write the same
Xaddress no matter where the sender is. The address above will get to
Xme from anywhere in the world, even private company mail systems. Yet,
Xsome optional abbreviations are possible - I can leave off the USA if
XI'm mailing within the USA; if I'm in the same city as the address, I
Xcan usually just say ``city'' in place of the last line. This type of
Xaddress is called an ``absolute address'', since the unabbreviated form
Xdoes not depend on the location of the sender.
X.P
XThe ARPANET has evolved with a system of absolute addresses:
X``user@host'' works from any machine. The UUCP network has evolved with
Xa system of relative addresses: ``host!user'' works from any machine with
Xa direct link to ``host'', and you have to route your mail through the
Xnetwork to find such a machine. In fact, the ``user@host'' syntax has
Xbecome so popular that many sites run mail software that accepts this
Xsyntax, looks up ``host'' in a table, and sends it to the appropriate
Xnetwork for ``host''. This is a very nice user interface, but it only
Xworks well in a small network. Once the set of allowed hosts grows
Xpast about 1000 hosts, you run into all sorts of administrative
Xproblems.
X.P
XOne problem is that it becomes nearly impossible to keep a table of
Xhost names up to date. New machines are being added somewhere in the
Xworld every day, and nobody tells you about them. When you try to send
Xmail to a host that isn't in your table (replying to mail you just got
Xfrom a new host), your mailing software might try to route it to a
Xsmarter machine, but without knowing which network to send it to, it
Xcan't guess which smarter machine to forward to. Another problem is
Xname space collision - there is nothing to prevent a host on one
Xnetwork from choosing the same name as a host on another network. For
Xexample, DEC's ENET has a ``vortex'' machine, there is also one on UUCP.
XBoth had their names long before the two networks could talk to each
Xother, and neither had to ask the other network for permission to use
Xthe name. The problem is compounded when you consider how many
Xcomputer centers name their machines ``A'', ``B'', ``C'', and so on.
X.P
XIn recognition of this problem, ARPA has established a new way to name
Xcomputers based on domains. The ARPANET is pioneering the domain
Xconvention, and many other computer networks are falling in line, since
Xit is the first naming convention that looks like it really stands a
Xchance of working. The MILNET portion of ARPANET has a domain, CSNET
Xhas one, and it appears that Digital, AT&T, and UUCP will be using
Xdomains as well. Domains look a lot like postal addresses, with a
Xsimple syntax that fits on one line, is easy to type, and is easy for
Xcomputers to handle. To illustrate, an old routed UUCP address might
Xread ``sdcsvax!ucbvax!allegra!cbosgd!mark''. The domain version of this
Xmight read ``mark@d.osg.cb.att.uucp''. The machine is named
Xd.osg.cb.att.uucp (UUCP domain, AT&T company, Columbus site, Operating
XSystem Group project, fourth machine.) Of course, this example is
Xsomewhat verbose and contrived; it illustrates the heirarchy well, but
Xmost people would rather type something like ``cbosgd.att.uucp'' or even
X``cbosgd.uucp'', and actual domains are usually set up so that you
Xdon't have to type very much.
X.P
XYou may wonder why the single @ sign is present, that is, why the above
Xaddress does not read ``mark.d.osg.cb.att.uucp''. In fact, it was
Xoriginally proposed in this form, and some of the examples in RFC819 do
Xnot contain an @ sign. The @ sign is present because some ARPANET
Xsites felt the strong need for a divider between the domain, which
Xnames one or more computers, and the left hand side, which is subject
Xto whatever interpretation the domain chooses. For example, if the ATT
Xdomain chooses to address people by full name rather than by their
Xlogin, an address like ``Mark.Horton@ATT.UUCP'' makes it clear that some
Xmachine in the ATT domain should interpret the string ``Mark.Horton'',
Xbut if the address were ``Mark.Horton.ATT.UUCP'', routing software might
Xtry to find a machine named ``Horton'' or ``Mark.Horton''. (By the way,
Xcase is ignored in domains, so that ``ATT.UUCP'' is the same as
X``att.uucp''. To the left of the @ sign, however, a domain can interpret
Xthe text any way it wants; case can be ignored or it can be
Xsignificant.)
X.P
XIt is important to note that
X.B "domains are not routes" .
XSome people look
Xat the number of !'s in the first example and the number of .'s in the
Xsecond, and assume the latter is being routed from a machine called
X``uucp'' to another called ``att'' to another called ``cb'' and so on. While
Xit is possible to set up mail routing software to do this, and indeed
Xin the worst case, even without a reasonable set of tables, this method
Xwill always work, the intent is that ``d.osg.cb.att.uucp'' is the name of
Xa machine, not a path to get there. In particular, domains are
Xabsolute addresses, while routes depend on the location of the sender.
XSome subroutine is charged with figuring out, given a domain based
Xmachine name, what to do with it. In a high quality environment like the
XARPA Internet, it can query a table or a name server, come up with a 32
Xbit host number, and connect you directly to that machine. In the UUCP
Xenvironment, we don't have the concept of two processes on arbitrary
Xmachines talking directly, so we forward mail one hop at a time until
Xit gets to the appropriate destination. In this case, the subroutine
Xdecides if the name represents the local machine, and if not, decides
Xwhich of its neighbors to forward the message to.
X.H 1 "What is a Domain?"
X.P
XSo, after all this background, we still haven't said what a domain is.
XThe answer (I hope it's been worth the wait) is that a domain is a
Xsubtree of the world tree. For example, ``uucp'' is a top level domain
X(that is, a subtree of the ``root''.) and represents all names and
Xmachines beneath it in the tree. ``att.uucp'' is a subdomain of ``uucp'',
Xrepresenting all names, machines, and subdomains beneath ``att'' in the
Xtree. Similarly for ``cb.att.uucp'', ``osg.cb.att.uucp'',
Xand even ``d.osg.cb.att.uucp'' (although ``d.osg.cb.att.uucp'' is a
X``leaf'' domain, representing only the one machine).
X.P
XA domain has certain properties. The key property is that it has a
X``registry''. That is, the domain has a list of the names of all
Ximmediate subdomains, plus information about how to get to each one.
XThere is also a contact person for the domain. This person is
Xresponsible for the domain, keeping the registry up-to-date, serving as
Xa point of contact for outside queries, and setting policy requirements
Xfor subdomains. Each subdomain can decide who it will allow to have
Xsubdomains, and establish requirements that all subdomains must meet to
Xbe included in the registry. For example, the ``cb'' domain might
Xrequire all subdomains to be physically located in the AT&T building in
XColumbus.
X.P
XARPA has established certain requirements for top level domains. These
Xrequirements specify that there must be a list of all subdomains and
Xcontact persons for them, a responsible person who is an authority for
Xthe domain (so that if some site does something bad, it can be made to
Xstop), a minimum size (to prevent small domains from being top level),
Xand a pair of nameservers (for redundancy) to provide a
Xdirectory-assistance facility. Domains can be more lax about the
Xrequirements they place on their subdomains, making it harder to be a
Xtop level domain than somewhere lower in the tree. Of course, if you
Xare a subdomain, your parent is responsible for you.
X.P
XOne requirement that is NOT present is for unique parents. That is, a
Xmachine (or an entire subdomain) need not appear in only one place in
Xthe tree. Thus, ``cb'' might appear both in the ``att'' domain, and in the
X``ohio'' domain. This allows domains to be structured more flexibly than
Xjust the simple geography used by the postal service and the telephone
Xcompany; organizations or topography can be used in parallel.
X(Actually, there are a few instances where this is done in the postal
Xservice [overseas military mail] and the telephone system [prefixes can
Xappear in more than one area code, e.g. near Washington D.C., and
XSilicon Valley].) It also allows domains to split or join up, while
Xremaining upward compatible with their old addresses.
X.P
XDo all domains represent specific machines? Not necessarily. It's
Xpretty obvious that a full path like ``d.cbosg.att.uucp'' refers to
Xexactly one machine. The OSG domain might decide that ``cbosg.att.uucp''
Xrepresents a particular gateway machine. Or it might decide that it
Xrepresents a set of machines, several of which might be gateways. The
X``att.uucp'' domain might decide that several machines, ``ihnp4.uucp'',
X``whgwj.uucp'', and ``hogtw.uucp'' are all entry points into ``att.uucp''. Or
Xit might decide that it just represents a spot in the name space, not a
Xmachine. For example, there is no machine corresponding to ``arpa'' or
X``uucp'', or to the root. Each domain decides for itself. The naming
Xspace and the algorithm for getting mail from one machine to another
Xare not closely linked - routing is up to the mail system to figure
Xout, with or without help from the structure of the names.
X.P
XThe domain syntax does allow explicit routes, in case you want to
Xexercise a particular route or some gateway is balking. The syntax is
X``@dom\d1\u,@dom\d2\u,...,@dom\dn\u:user@domain'', for example,
X@ihnp4.UUCP,@ucbvax.UUCP,:joe@NIC.ARPA, forcing it to be routed through
Xdom\d1\u, dom\d2\u, ..., dom\dn\u, and from domn sent to the final address.
XThis behaves exactly like the UUCP ! routing syntax, although it is somewhat
Xmore verbose.
X.P
XBy the way, you've no doubt noticed that some forms of electronic
Xaddresses read from left-to-right (cbosgd!mark), others read from
Xright-to-left (mark@Berkeley). Which is better? The real answer here
Xis that it's a religious issue, and it doesn't make much difference.
Xleft-to-right is probably a bit easier for a computer to deal with
Xbecause it can understand something on the left and ignore the
Xremainder of the address. (While it's almost as easy for the program
Xto read from right-to-left, the ease of going from left-to-right was
Xprobably in the backs of the minds of the designers who invented
Xhost:user and host!user.)
X.P
XOn the other hand, I claim that user@host is
Xeasier for humans to read, since people tend to start reading from the
Xleft and quit as soon as they recognize the login name of the person.
XAlso, a mail program that prints a table of headers may have to
Xtruncate the sender's address to make it fit in a fixed number of
Xcolumns, and it's probably more useful to read ``mark@d.osg.a'' than
X``ucbvax!sdcsv''.
X.P
XThese are pretty minor issues, after all, humans can
Xadapt to skip to the end of an address, and programs can truncate on
Xthe left. But the real problem is that if the world contains BOTH
Xleft-to-right and right-to-left syntax, you have ambiguous addresses
Xlike x!y@z to consider. This single problem turns out to be a killer,
Xand is the best single reason to try to stamp out one in favor of the
Xother.
X.H 1 "So why are we doing this, anyway?"
X.P
XThe current world is full of lots of interesting kinds of mail syntax.
XThe old ARPA ``user@host'' is still used on the ARPANET by many systems.
XExplicit routing can sometimes by done with an address like
X``user@host2@host1'' which sends the mail to host1 and lets host1
Xinterpret ``user@host2''. Addresses with more than one @ were made
Xillegal a few years ago, but many ARPANET hosts depended on them, and
Xthe syntax is still being used. UUCP uses ``h1!h2!h3!user'', requiring
Xthe user to route the mail. Berknets use ``host:user'' and do not allow
Xexplicit routing.
X.P
XTo get mail from one host to another, it had to be routed through
Xgateways. Thus, the address ``csvax:mark@Berkeley'' from the ARPANET
Xwould send the mail to Berkeley, which would forward it to the Berknet
Xaddress csvax:mark. To send mail to the ARPANET from UUCP, an address
Xsuch as ``ihnp4!ucbvax!sam@foo-unix'' would route it through ihnp4 to
Xucbvax, which would interpret ``sam@foo-unix'' as an ARPANET address and
Xpass it along. When the Berknet-UUCP gateway and Berknet-ARPANET
Xgateway were on different machines, addresses such as
X``csvax:ihnp4!ihnss!warren@Berkeley'' were common.
X.P
XAs you can see, the combination of left-to-right UUCP syntax and
Xright-to-left ARPANET syntax makes things pretty complex. Berknets are
Xgone now, but there are lots of gateways between UUCP and the ARPANET
Xand ARPANET-like mail networks. Sending mail to an address for which
Xyou only know a path from the ARPANET onto UUCP is even harder \-
Xsuppose the address you have is ihnp4!ihnss!warren@Berkeley, and you
Xare on host rlgvax which uses seismo as an ARPANET gateway. You must
Xsend to seismo!ihnp4!ihnss!warren@Berkeley, which is not only pretty
Xhard to read, but when the recipient tries to reply, it will have no
Xidea where the break in the address between the two UUCP pieces
Xoccurs. An ARPANET site routing across the UUCP world to somebody's
XEthernet using domains locally will have to send an address something
Xlike ``xxx@Berkeley.ARPA'' to get it to UUCP, then
X``ihnp4!decvax!island!yyy'' to get it to the other ethernet, then
X``sam@csvax.ISLAND'' to get it across their ethernet. The single address
Xwould therefore be ihnp4!decvax!island!sam@csvax.ISLAND@Berkeley.ARPA,
Xwhich is too much to ask any person or mailer to understand. It's even
Xworse: gateways have to deal with ambiguous names like
Xihnp4!mark@Berkeley, which can be parsed either ``(ihnp4!mark)@Berkeley''
Xin accordance with the ARPANET conventions, or ``ihnp4!(mark@Berkeley)''
Xas the old UUCP would.
X.P
XAnother very important reason for using domains is that your mailing
Xaddress becomes absolute instead of relative. It becomes possible to
Xput your electronic address on your business card or in your signature
Xfile without worrying about writing six different forms and fifteen
Xhosts that know how to get to yours. It drastically simplifies the job
Xof the reply command in your mail program, and automatic reply code in
Xthe netnews software.
X.H 1 "Further Information"
X.P
XFor further information, some of the basic ARPANET reference documents
Xare in order. These can often be found posted to Usenet, or available
Xnearby. They are all available on the ARPANET on host NIC via FTP with
Xlogin ANONYMOUS, if you have an ARPANET login. They can also be
Xordered from the Network Information Center, SRI International,
XMenlo Park, California, 94025.
X.DS
XRFC819 The Domain Naming Convention for Internet User Applications
XRFC821 Simple Mail Transfer Protocol
XRFC822 Standard for the Format of ARPANET Text Messages
XRFC881 The Domain Names Plan and Schedule
X.DE
X.nf
X#
X# @(#)domain.mm 2.1 smail 12/14/86
X#
@//E*O*F doc/domain.mm//
if test 19036 -ne "`wc -c <'doc/domain.mm'`"; then
echo shar: error transmitting "'doc/domain.mm'" '(should have been 19036 characters)'
fi
fi # end of overwriting check
echo shar: extracting "'doc/paths.8'" '(2859 characters)'
if test -f 'doc/paths.8' ; then
echo shar: will not over-write existing file "'doc/paths.8'"
else
sed 's/^X//' >doc/paths.8 <<'@//E*O*F doc/paths.8//'
X.TH PATHS 8
X.tr ~
X.SH NAME
Xpaths \- smail routing database
X.SH DESCRIPTION
XThe
X.I paths
Xfile is the routing database for
X.IR smail .
XEach line of the file provides routing information
Xto either a host or to a domain. Each line should
Xhave either two or three tab (ascii~0x9) separated fields.
XThe format of each line in the paths file is:
X.tr ~
X.sp
X.ce
X\fIkey~~route~~~[cost]\fP
X.sp
XThe
X.I key
Xfield is the key on which searches are performed.
XTypically this is either a UUCP host name or a domain name.
X.I smail
Xuses a binary search algorithm when searching the database,
Xso the keys must be sorted in ascending order.
XCase is ignored when searching, so the keys should be converted
Xto lower case before sorting (see
X.IR lcase (8)
Xand
X.IR pathproc (8)).
X.B Warning:
XThere is a bug in
X.I sort -f,
Xso don't use it. Convert the keys to lower case, and then sort.
X.PP
XThe
X.I route
Xfield is a "printf" string that details the route that mail to the
X.I key
Xshould take.
XSee
X.I pathalias
Xdocumentation for details.
X.PP
XThe optional
X.I cost
Xfield is used by
X.I smail
Xto determine whether to simply queue outbound
XUUCP mail, or to attempt immediate delivery
X(usually by invoking
X.IR uucico ).
XIf the cost field is present, and the value is at or below
X.IR smail "'s"
X.I queueing threshold
Xthen the mail will be queued and an attempt at immediate delivery
Xwill be made. This will speed mail delivery between hosts who
Xenjoy a cheap uucp link, like a hardwired line or some other
Xlow cost transport medium, while allowing mail sent over more
Xexpensive media to accumulate before transmission.
XIf the field is absent, the cost defaults to a value
Xabove the
X.I queueing threshold.
XThe default value for the queueing threshold is equal to the pathalias
Xcost DEDICATED+LOW. Thus, direct links with cost DEDICATED+LOW or less
Xwill see immediate delivery, while the others are queued for later delivery.
X.SH EXAMPLE
XHere's a sample paths file for a small host, like a pc, that doesn't
Xwant to maintain complete routing information. It illustrates
Xmost of the aspect of the
X.I paths
Xfile. Assme that the pc's name is
X.I mypc,
Xand that it's in domain
X.I .mydomain.
XAlso, assume that it has a dedicated link to
Xa smart host named
X.I bighub,
Xand that
X.IR bighub 's
Xadministrator has given
X.I mypc
X.B permission
Xto use
X.I bighub
Xas a mail relay.
XLastly, assume that
X.I mypc
Xhas a dialed on demand link to another computer named
X.I friend.
X.nf
X.sp
X.in +5
X\fIpathalias\fP input
X.sp
X mypc = .mypc.mydomain
X mypc friend(DEMAND), bighub(DEDICATED)
X smart-host = bighub
X.sp
X\fIpaths\fP file produced by \fIpathalias -c inputfile|pathproc\fP
X.sp
X .mypc.mydomain %s 0
X bighub bighub!%s 95
X friend friend!%s 300
X mypc %s 0
X smart-host bighub!%s 95
X.in
X.sp
X.fi
X.SH SEE ALSO
Xpathalias - by Peter Honeyman
X.br
Xsmail(8), lcasep(8), pathproc(8)
X.SH VERSION
X@(#)paths.8 2.1 smail 12/14/86
@//E*O*F doc/paths.8//
if test 2859 -ne "`wc -c <'doc/paths.8'`"; then
echo shar: error transmitting "'doc/paths.8'" '(should have been 2859 characters)'
fi
fi # end of overwriting check
echo shar: extracting "'doc/smail.8'" '(8914 characters)'
if test -f 'doc/smail.8' ; then
echo shar: will not over-write existing file "'doc/smail.8'"
else
sed 's/^X//' >doc/smail.8 <<'@//E*O*F doc/smail.8//'
X.TH SMAIL 8
X.SH NAME
Xsmail, rmail \- UUCP mailer with routing
X.SH SYNOPSIS
X.B smail
X[ options ] address ...
X.br
X.B rmail
X[ options ] address ...
X.SH DESCRIPTION
XThe
X.I smail/rmail
Xprogram replaces
X.IR /bin/rmail (1)
Xto become the UUCP mail transport mechanism.
XThey are links to the same executable.
X.I rmail
Xreceives mail from UUCP,
X.I smail
Xintroduces mail into UUCP.
X.PP
X.I smail/rmail
Xcan work with or without
X.IR sendmail (8),
Xor another intelligent mail system.
XFor hosts with just
X.IR /bin/mail (1),
X.I smail/rmail
Xsubsumes some of the functions of
X.I sendmail,
Xand hands only local mail to
X.I /bin/mail.
XFor hosts with
X.I sendmail,
X.I smail/rmail
Xcan act as UUCP front and back ends to
X.I sendmail,
Xallowing
X.I sendmail
Xto process all mail through the host.
XAs distributed, 'bang' mail that is not bound for a local
Xrecipient will be passed directly to
X.I uux
Xwithout calling
X.I sendmail.
X.PP
XTo varying degrees,
X.I smail/rmail
Xautomatically routes the addresses it processes.
X.I smail/rmail
Xmost often routes domain style addresses (i.e. user@domain), producing
Xa UUCP path (i.e. host!address) or a local address (i.e. user), but it can
Xalso reroute explicit UUCP paths.
X.SH OPTIONS
X.TP
X.B \-d
XBe verbose and don't invoke other mailers.
X.TP
X.B \-v
XBe verbose, but still invoke other mailers.
X.TP
X.BI \-h " hostname"
XSet hostname. The default is configuration dependent, but usually provided
Xby a system call such as
X.IR gethostname (2)
Xor
X.IR uname (2).
X.TP
X.BI \-H " hostdomain"
Xset hostdomain. The default is configuration dependent.
X.TP
X.BI \-p " pathfile"
XSet path database file name if not /usr/lib/uucp/paths.
X.TP
X.BI \-a " aliasfile"
XFor sites without sendmail, set alias database file name if not in /usr/lib/aliases.
X.TP
X.BI \-q " number"
XTake
X.I number
Xas the queueing threshold.
XWhen routing mail (
X.I -r, -R,
Xor domain addressed mail
X) to a given host, if the cost listed in the
X.I paths
Xfile is less than the queueing threshold, then the mail
Xwill be sent immediately. This overrides the default threshold
X(see QUEUECOST in defs.h) of DEDICATED+LOW.
X.TP
X.BI \-u " uuxflags"
XUse
X.I uuxflags
Xas the flags passed to uux for remote mail.
XThis overrides any of the default values and other queueing strategies.
X.TP
X.B \-r
XRoute the first component of a UUCP path (host!address) in addition to routing
Xdomain addresses (user@domain).
X.TP
X.B \-R
XReroute UUCP paths, trying successively larger righthand substrings
Xof a path until a component is recognized.
X.TP
X.B \-l
XInstead of routing a domain address, send it to the local mailer for
Xprocessing. Normally, only local addresses go to the local mailer.
X.TP
X.B \-L
XSend all addresses to the local mailer for processing, including UUCP paths.
X.PP
XMost of the flags are also compile time options, since
X.I uux
Xdoes not normally invoke
X.I rmail
Xwith the desired flags.
X.I smail
Xresets any preset
X.B -l
Xor
X.B -L
Xflags.
X.B -l
Xflag causes
X.B rmail
Xto send all domain addresses through the local mailer,
Xto process addresses for non UUCP domains.
XThe
X.B -L
Xflag causes
X.B rmail
Xto send even explicit UUCP paths through the local mailer,
Xpresumably to make use of other transport mechanisms.
XIn both cases, rmail defers any routing until smail gets hold it.
X.SH ADDRESSES
X.I smail/rmail
Xunderstands "user@domain" to be a domain address, "host!address" to be a
XUUCP path, and anything else to be a local address.
X.PP
XBecause hostile
X.I rmail's
Xunpredictably interpret mixed UUCP/domain addresses,
X.I smail/rmail
Xunderstands "domain!user" to be a domain address, and generates
X"path!domain!user" when mailing to a cognate
X.I smail/rmail
Xhost.
XTo distinguish domain "domain!user" from UUCP "host!address", "domain"
Xcontains at least one (1) period.
XUnlike the old
X.I /bin/rmail,
X.I smail/rmail
Xgives precedence to @ over ! when parsing mixed addresses,
Xthus a!b@c is parsed as (a!b)@c, rather than a!(b@c).
X.SH ROUTING
XBecause
X.I smail/rmail
Xis the UUCP transport mechanism, it can only effect delivery on UUCP paths
Xand local addresses; domain addresses require resolution into UUCP paths or
Xlocal addresses.
XTo resolve a domain address,
X.I smail/rmail
Xfinds a route to the most specific part of the domain specification listed
Xin the routing table.
XTwo degrees of resolution can occur:
X.RS
X.PP
XFull resolution:
X.I smail/rmail
Xfinds a route for the entire domain specification, and tacks the user
Xspecification onto the end of the UUCP path.
XThe address can also fully resolve to a local address (the UUCP path is null).
X.PP
XPartial resolution:
X.I smail/rmail
Xfinds a route for only righthand part of the domain specification, so it
Xtacks the complete address (in the form domain!user) onto the end of the
XUUCP path.
XSince this syntax is not widely understood, UUCP gateways listed in
Xthe path database must install new UUCP software, either
X.I smail/rmail
Xor new
X.I sendmail
Xconfiguration files (or both).
X.RE
X.PP
XIt is an error if a partially resolved address routes to the local host
X(a null UUCP path), since according to the routing table, the local
Xhost is responsible for resolving the address more fully.
X.PP
XThe
X.B -r
Xflag causes
X.I smail/rmail
Xto attempt to route the first component of a UUCP path, probably so it
Xcan impress people with how many UUCP hosts it knows.
XIf this fails, it passes the unrouted address to
X.I uux,
Xin case the path database is not complete.
XThe
X.B -R
Xflag causes
X.I smail/rmail
Xto take a UUCP path and route the rightmost component of the path (save
Xthe user name) possible.
XThis is mostly for hosts that have very up-to-date routing tables.
X.PP
XIf a route cannot be discerned from the available routing database,
Xthen one more attempt to route the mail is made by searching for an
Xentry in the database for a route to a
X.I smart-host.
XIf this entry exists, then the mail will be forwarded along that route
Xto be delivered. This allows a host to depend on another, presumably
Xbetter informed, host for delivering its mail.
XThis kind of arrangement should be worked out,
X.I in advance,
Xwith the
X.IR smart-host 's
Xadministrator.
X.PP
XAfter
X.I smail/rmail
Xresolves an address, it reparses it to see if it is now a UUCP path or
Xlocal address. If the new address turns out to be another
Xdomain address, smail complains because we don't like to resolve more than once.
XThis error occurs when an address partially resolves the local host.
X.PP
XBy default,
X.I smail
Xwill not alter the explicit bang path routing of any mail message.
XIf the stated path is unuseable, (i.e., the next hop host is unknown)
Xthen smail will apply ALWAYS routing, and attempt to deliver the mail
Xto the potentially new address. If this fails too, then REROUTE routing
Xwill be applied to the address, and another attempt to deliver is made.
XLastly, an attempt to find a path to a better informed host
X.I smart-host
Xwill be made and the mail passed to that host.
X.SH FROMMING
X.I smail/rmail
Xcollapses From_ and >From_ lines to generate a simple from argument, which
Xit can pass to
X.I sendmail
Xor use to create its own "From" line.
XThe rule for fromming is: concatenate each "remote from" host (separating
Xthem by !'s), and tack on the address on the last From_ line; if that address
Xis in user@domain format, rewrite it as domain!user; ignore host or
Xdomain if either is simply the local hostname. It also removes redundant
Xinformation from the From_ line. For instance:
X.sp
X.ce
X ...!myhost!myhost.mydomain!...
X.sp
Xbecomes
X.sp
X.ce
X ...!myhost!...
X.sp
XLeading occurrences of the local host name are elided as well.
X.PP
X.I smail/rmail
Xgenerates it own From_ line, unless it is feeding
X.I sendmail,
Xwhich is happy with the
X.BI -f from
Xargument.
XFor UUCP bound mail,
X.I smail/rmail
Xgenerates a "remote from hostname", where hostname is the UUCP hostname
X(not the domain name), so that From_ can indicate a valid UUCP path, leaving
Xthe sender's domain address in From:.
X.SH HEADERS
XCertain headers, To:, From:, Date, etc., are required by RFC822.
XIf these headers are absent in locally generated mail, they will
Xbe inserted by smail. Also, a line of trace information, called
Xa Received: line, will be inserted at the top of each message.
X.SH UNDELIVERABLE MAIL"
XAlthough nobody likes to have a mail message fail to reach its
Xintended destination, it somtimes happens that way.
XMail that is found to be undeliverable
X(i.e., unknown user or unknown host)
Xwill be returned to the sender.
X.SH FILES
X/usr/lib/uucp/paths ascii path database
X.br
X/usr/lib/aliases ascii alias database
X.br
X/usr/spool/uucp/mail.log log of mail
X.br
X/tmp/mail.log record of mail
X.SH AUTHOR
XChristopher Seiwald
X.br
Xchris@cbosgd.att.com
X.SH SUPPORT
XEnhancements, enhancement requests, trouble reports, etc.,
Xshould be sent to
X.sp
X.ce
Xuucp-problem@cbatt.att.com.
X.sp
X.SH "SEE ALSO"
X.IR uux (1),
X.IR paths (8),
X.IR aliases (8)
X.br
X.IR sendmail (8)
X.br
X.IR binmail (1)
Xon BSD systems only
X.br
X.IR mail (1)
Xon System V systems
X.SH VERSION
X@(#)smail.8 2.2 smail 1/11/87
@//E*O*F doc/smail.8//
if test 8914 -ne "`wc -c <'doc/smail.8'`"; then
echo shar: error transmitting "'doc/smail.8'" '(should have been 8914 characters)'
fi
fi # end of overwriting check
echo shar: extracting "'doc/rfc976.mm'" '(21687 characters)'
if test -f 'doc/rfc976.mm' ; then
echo shar: will not over-write existing file "'doc/rfc976.mm'"
else
sed 's/^X//' >doc/rfc976.mm <<'@//E*O*F doc/rfc976.mm//'
X.nr Hy 0
X.TL
XUUCP Mail Interchange Format Standard
X.AU "Mark R. Horton" "" CB 59443 4276 2C-249 "(cbosgd!mark)"
X.AS 0 10
XThis document defines the standard format for the
Xtransmission of mail messages between machines. It does not
Xaddress the format for storage of messages on one machine, nor the
Xlower level transport mechanisms used to get the data from one
Xmachine to the next.
XIt represents a standard for conformance by hosts in the UUCP zone.
X.AE
X.MT 4 1
X.H 1 "Status"
X.P
XIn response to the need for maintenance of current information
Xabout the status and progress of various projects in the
XARPA-Internet community, this RFC is issued for the benefit of
Xcommunity members. The information contained in this document
Xis accurate as of the date of publication, but is subject to
Xchange. Subsequent RFCs will reflect such changes.
X.P
XDistribution of this memo is unlimited.
X.H 1 "Introduction"
X.P
XThis document is intended to define the standard format for the
Xtransmission of mail messages between machines. It does not
Xaddress the format for storage of messages on one machine, nor the
Xlower level transport mechanisms used to get the data from one
Xmachine to the next.
XWe assume remote execution of the rmail command (or equivalent)
Xas the UUCP network primitive operation.
X.P
XThe general philosophy is that, if we were to invent a new standard,
Xwe would make ourselves incompatible with existing systems. There are
Xalready too many (incompatible) standards in the world, resulting
Xin ambiguities such as a!b@c.d which is parsed a!(b@c.d) in the
Xold UUCP world, and (a!b)@c.d in the Internet world. (Neither
Xstandard allows parentheses, and in adding them we would be compatible
Xwith neither. There would also be serious problems with the shell and
Xwith the UUCP transport mechanism.)
X.P
XHaving an established, well documented, and extensible family of
Xstandards already defined by the ARPA Internet, we choose to adopt
Xthese standards for the UUCP zone as well.
X(The UUCP zone is that subset of the community connected by UUCP
Xwhich chooses to register with the UUCP project.
XIt represents an administrative entity.)
XWhile the actual
Xtransport mechanism is up to the two hosts to arrange, and might
Xinclude UUCP, SMTP, MMDF, or some other facility, we adopt RFC920
X(domains) and RFC822 (mail format) as UUCP zone standards. All
Xmail transmitted between systems should conform to those two standards.
XIn addition, should the ARPA community change these standards at a
Xlater time, we intend to change our standards to remain compatible with theirs,
Xgiven a reasonable time to upgrade software.
X.P
XThis document specifies an interpretation of RFC822 and RFC920 in
Xthe UUCP world.
XIt shows how the envelope should be encoded,
Xand how UUCP routing is accomplished in an environment of mixed
Ximplementations.
X.H 1 "Basics"
XMessages can be divided into two parts: the envelope and the message.
XThe envelope contains information needed by the mail transport services,
Xand the message contains information useful to the sender and receiver.
XThe message is divided into the header and the body.
XSometimes an intermediate host will add to the message (e.g. a Received
Xline) but, except in the case of a gateway which must translate formats,
Xit is not expected that intermediate hosts will change the message itself.
XIn the UUCP world, the envelope consists of the ``destination addresses''
X(normally represented as the argument or arguments to the rmail command)
Xand the ``source path'' (normally represented in one or more lines at the
Xbeginning of the message beginning either ``From '' or ``>From '', sometimes
Xcalled ``From_ lines''.) The RFC822 header lines (including ``From:''
Xand ``To:'') are part of the message, as is the text of the message body itself.
X.P
XUUCP uses short host names, such as ``ucbvax'',
Xat and below the transport layer.
XWe refer to these names as ``6 letter names'', because all implementations
Xof UUCP consider at least the first 6 letters significant.
X(Some consider the first 7 or the first 14 significant, but we must use
Xthe lowest common denominator.)
XUUCP names may be longer than 6 characters, but all such names much be
Xunique in their first 6 letters.
XRFC 920 domain names, such as ``ucbvax.Berkeley.EDU'',
Xare called ``domain names.''
XThe two names are different.
XUpper and lower case are usually considered different in 6 letter names,
Xbut are considered equivalent in domain names.
XNames such as ``ucbvax.UUCP'',
Xconsisting of a 6 letter name followed by ``.UUCP'',
Xpreviously were domain style references to a host with a given 6 letter name.
XSuch names are being phased out in favor of organizational domain names
Xsuch as ``ucbvax.Berkeley.EDU''
X.H 2 "Hybrid Addresses"
XThere are (among others) two major kinds of mailing address syntax
Xused in the UUCP world. The a!b!c!user (``bang paths'') is used by
Xolder UUCP software to explicitly route mail to the destination.
XThe user@domain (``domain'') syntax is used in conformance to RFC 822.
XUnder most circumstances, it is possible to look at a given address
Xand determine which sort of address it is.
XHowever, a hybrid address with a ! to the left of an @, such as a!b@c,
Xis ambiguous: it could be interpreted as (a!b)@c.d or a!(b@c.d).
XBoth interpretations can be useful.
XThe first interpretation is required by RFC 822, the second is a de-facto
Xstandard in the UUCP software.
X.P
XBecause of the confusion surrounding hybrid addresses, we recommend that
Xall transport layer software avoid the use of hybrid addresses at all times.
XA pure bang syntax can be used to disambiguate, being written
Xc.d!a!b in the first case above, and a!c.d!b in the second.
XWe recommend that all implementations use this ``bang domain'' syntax
Xunless they are sure of what is running on the next machine.
X.P
XIn conformance with RFC 822 and the AT&T Message Transfer Architecture,
Xwe recommand that any host that accepts hybrid addresses apply the (a!b)@c.d
Xinterpretation.
X.H 2 "Transport"
XSince SMTP is not available to much of the UUCP domain, we define the
Xmethod to be used for ``remote execution'' based transport mechanisms.
XThe command to be ``remotely executed'' should read
X.DS I
Xrmail user@domain ...
X.DE
Xwith the message on the standard input of the command. The ``user@domain''
Xargument must conform to RFC920 and RFC822. More than one address
Xargument is allowed, in order to save transmission costs for multiple
Xrecipients of the same message.
X.P
XAn alternative form that may be used is
X.DS I
Xrmail domain!user
X.DE
Xwhere ``domain'' contains at least one period and no !'s. This is to
Xbe interpreted exactly the same as user@domain, and can be used to
Xtransport a message across old UUCP hosts without fear that they
Xmight change the address. The ``user'' string can contain any characters
Xexcept ``@''. This character is forbidden because it is
Xunknown what an intermediate host might do to it.
X(It is also recommended that the ``%'' character be avoided, since
Xsome hosts treat ``%'' as a synonym for ``@''.)
XHowever, to
Xroute across hosts that don't understand domains, the following
Xis possible
X.DS I
Xrmail a!b!c!domain!user
X.DE
XA ``domain'' can be distinguished from a 6 letter UUCP site name
Xbecause a domain will contain at least one period. (In the case
Xof single level domains with no periods, a period should be added
Xto the end, e.g. Mark.Horton@att becomes ``att.!Mark.Horton''. A
Xtranslator from ! to @ format should remove a trailing dot at the
Xend of the domain, if one is present.)
XWe don't expect this to happen, except for local networks
Xusing addresses like ``user@host''.
X.P
XA simple implementation can always generate domain!user syntax
X(rather than user@domain) since it is safe to assume that gateways
Xare class 3.
X.H 2 "Batch SMTP"
XStandard conforming implementations may optionally support a protocol
Xcalled ``Batch SMTP''.
XSMTP (Simple Mail Transfer Protocol) is the ARPANET standard mail
Xtransfer protocol.
XIt is also used on BITNET and Mailnet.
XWhile SMTP was designed to be interactive, it is possible to batch up
Xa series of commands and send them off to a remote machine for batch execution.
XThis is used on BITNET, and is appropriate for UUCP.
XOne advantage to BSMTP is that the UNIX shell does not get involved
Xin the interpretation of messages, so it becomes possible to include
Xspecial characters such as space and parentheses in electronic messages.
X(Such characters are expected to be popular in X.400 addresses.)
X.P
XTo support BSMTP on UNIX, a conforming host should arrange that mail to
Xthe user ``b-smtp'' is interpreted as Batch SMTP commands.
X(We use b-smtp instead of bsmtp because bsmtp might conflict with
Xa login name.)
XSince many mail systems treat lines consisting of a single period
Xas an ``end of file'' flag, and since SMTP uses the period as a
Xrequired end of file flag, and to strip off headers, we put an
Xextra ``#'' at the beginning of each BSMTP line.
XOn a sendmail system, an easy way to implement this is to include the alias
X.DS I
Xb-smtp: "|egrep '^#' | sed 's/^#//' | /usr/lib/sendmail -bs"
X.DE
Xwhich will feed the commands to an SMTP interpreter.
XA better solution would appropriately check for errors and send back an
Xerror message to the sender.
X.P
XAn example BSMTP message from seismo.CSS.GOV to cbosgd.ATT.COM is shown here.
XThis sample is the file shipped over the UUCP link for in put to the
Xcommand ``rmail b-smtp''.
XNote that the RFC 822 message is between the DATA line and the period line.
XThe envelope information is passed in the MAIL FROM and RCPT TO lines.
XThe name of the sending system is in the HELO line.
XThe actual envelope information (above the # lines) is ignored
Xand need not be present.
X.DS I
XFrom foo!bar Sun Jan 12 23:59:00 1986 remote from seismo
XDate: Tue, 18 Feb 86 13:07:36 EST
XFrom: mark@ucbvax.Berkeley.EDU
XMessage-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU>
XTo: b-smtp@cbosgd.ATT.COM
X
X#HELO seismo.CSS.GOV
X#MAIL FROM:<mark@ucbvax.Berkeley.EDU>
X#RCPT TO:<mark@cbosgd.ATT.COM>
X#DATA
X#Date: Tue, 18 Feb 86 13:07:36 EST
X#From: mark@ucbvax.Berkeley.EDU
X#Message-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU>
X#To: mark@cbosgd.ATT.COM
X#
X#This is a sample message.
X#.
X#QUIT
X
X.DE
X.H 2 "Envelope"
X.P
XThe standard input of the command should begin with a single line
X.DS I
XFrom domain!user date remote from system
X.DE
Xfollowed immediately by the RFC822 format headers and body of the message.
XIt is possible that there will be additional From_ lines
Xpreceding this line - these lines may be added, one line for each
Xsystem the message passes through. It is also possible that the
X``system'' fields will be stacked into a single line, with many !'s in the
X``user'' string. The ``>'' character may precede the ``From''. In general,
Xthis is the ``envelope'' information, and should follow the same conventions
Xthat previous UUCP mail has followed. The primary difference is that,
Xwhen the system names are stacked up, if previously the result would
Xhave been a!b!c!mysys!me, the new result will be a!b!c!mysys!domain!me,
Xwhere domain will contain at least one period, and ``mysys'' is often the
X6 letter UUCP name for the same system named by ``domain''.
XIf the ``domain!'' is redundant,
Xit may be omitted from the envelope,
Xeither in the source path or in the destination address.
X.P
XThe receiving system may discard extra ``From_'' lines if it folds
Xthe information into a a single From_ line. It passes the
Xpath!domain!user along as the ``envelope'' information containing the address
Xof the sender of the message, and possibly preserves the forwarding date and
Xsystem in a newly generated header line, such as Received or Sent-By.
X(Adding Received using this information is discouraged, since the line
Xappears to have been added on a different system than the one actually
Xadding it.
XThat other system may have actually included a Received line too!
XThe Sent-By line is similar to Received, but the date need not be
Xconverted into RFC 822 format, and the line is not claimed to have
Xbeen added by the system whose name is mentioned.)
X.P
XIf the receiving system passes the message along to another system,
Xit will add a ``From_'' line to the front, giving the same user@domain
Xaddress for the sender, and its own name for the system. If the
Xreceiving system stores the message in a local mailbox, it is recommended
Xthat a single ``From_'' line be generated at the front of the message,
Xkeeping the date (in the same format, since certain mail reading
Xprograms are sensitive to this format),
Xand not using the ``remote from system'' syntax.
X.P
XNote - if an intermediate system adds
Xtext such as ``system!'' to the front of a ``user@domain'' syntax address,
Xeither in the envelope or the body,
Xthis is a violation of this standard and of RFC 822.
X.H 2 "Routing"
XIn order to properly route mail, it is sometimes necessary to know what
Xsoftware a destination or intermediate machine is running, or what
Xconventions it follows. We have tried to minimize the amount of this
Xinformation that is necessary, but the support of subdomains may require
Xthat different methods are used in different situations. For purposes
Xof predicting the behavior of other hosts, we divide hosts into
Xthree classes. These classes are:
X.VL 10
X.LI "Class 1"
Xold-style UUCP ! routing only. We assume that the host understands
Xlocal user names:
X.DS I
Xrmail user
X.DE
Xand bang paths
X.DS I
Xrmail host1!host2!user
X.DE
Xbut we assume nothing more about the host. If we have no information about
Xa host, we can treat it as class 1 with no problems, since we make no
Xassumptions about how it will handle hybrid addresses.
X.LI "Class 2"
XOld style UUCP ! routing, and 4.2BSD style domain parsing. We
Xassume the capabilities of class 2, plus the ability to understand
X.DS I
Xrmail user@domain
X.DE
Xif the ``domain'' is one outside the UUCP zone which the host knows about.
XClass 2 hosts do not necessarily understand domain!user or have routers.
XHosts in
Xnon-UUCP RFC920 domains are considered class 2, even though they may
Xnot understand host!user.
X.LI "Class 3"
XAll class 1 and 2 features are present. In addition, class 3
Xhosts must be able to route UUCP mail for hosts that are not immediately
Xadjacent and also understand the syntax
X.DS I
Xrmail domain!user
X.DE
Xas described above.
XAll gateways into UUCP must be class 3.
X.LE
X.P
XThis document describes what class 3 hosts must be able to process.
XClasses 1 and 2 already exist, and will continue to exist for a long
Xtime, but are viewed as ``older systems'' that may eventually be upgraded
Xto class 3 status.
X.H 1 "Algorithm"
X.P
XThe algorithm for delivering a message to an address ``user@domain''
Xover UUCP links can be summarized as follows:
X.AL a
X.LI
XIf the address is actually of the form @domain1:user@domain2,
Xthe ``domain'' used for the remainder should be ``domain1'' instead
Xof ``domain2'', and the bang form reads domain1!domain2!user.
X.LI
XDetermine d: the most specific part of ``domain'' that is recognized locally.
XThis part will be a suffix of ``domain''. This can be done by scanning
Xthrough a table with entries that go from specific to general, comparing
Xentries with ``domain'' to see if the entries are at the tail of ``domain''.
XFor example, with the address ``mark@osgd.cb.att.com'', if the local
Xhost recognizes ``uucp'' and ``att.com'', d would be ``att.com''.
XThe final entry in the table will be the null string, matching any
Xcompletely unrecognized domain.
X.LI
XLook in the found table entry for g: the name of the ``gateway'', and
Xfor r: a UUCP !-style route to reach g. G is not necessarily directly
Xconnected to the local host, but should be viewed as a gateway into
Xthe d domain. (The values of g and r for a given d may be different
Xon different hosts, although g will often be the same.)
X.LI
XLook at the beginning of r to find the ``next hop'' host n. N will
Xalways be directly connected to the local host.
X.LI
XDetermine, if possible, the class of g and n.
X.LI
XCreate an appropriate destination string s to be interpreted by n.
X(See below.)
X.LI
XPass the message off to n with destination information s.
X.LE
X.P
XIn an environment with other types of networks that do not use UUCP !
Xparsing, the table will probably contain additional information, such
Xas which type of link to use. The path information may be replaced in
Xother environments by information specific to the network.
X.P
XThe first entries in the table mentioned in part (b) are normally very
Xspecific, and allow well known routes to be constructed directly instead
Xof routing through the domain tree. The domain tree should be reserved
Xfor cases where no better information is available, or where traffic is
Xvery light, or where the default route is the best available. If a better
Xroute is available, that information can be put in the table. If a host
Xhas any significant amount of traffic sent to a second host, it is normally
Xexpected that the two hosts will set up a direct UUCP link and make an
Xentry in their tables to send mail directly, even if they are in separate
Xdomains. Routing tables should be constructed to try to keep paths short
Xand inexpensive for as much traffic as possible.
X.P
XHere are some hints for the construction of the destination string n
X(step f above.) The ``envelope recipient'' information (the argument(s)
Xto rmail) may be in either domain ! form (host.com!user) or domain @
Xform (user@host.com) as long as the sending site is sure the next hop
Xis class 3. If the next hop is not class 3, or the sending site is
Xnot sure, the ! form should be used, if possible, since it is hard
Xto predict what the next hop would do with a hybrid address.
X.P
XIf the gateway is known to be class 3, domain ! form may be
Xused, but if the sending site is not sure, and the entire destination
Xstring was matched in the lookup (rather than some parent domain),
Xthe 6 letter ! form should be used: r!user,
Xfor example: dumbhost!host!user.
XIf the gateway appears to actually be
Xa gateway for a subdomain,
Xe.g. because a parent domain was matched,
X(such as the address user@host.gateway.com,
Xwhere host.gateway.com was not found but gateway.com was)
Xit can be assumed to be at class 3.
XThis allows routes such as
Xdumbhost!domain!host.domain.com!user to be used with a reasonable
Xdegree of safety.
XIf a direct link exists to the destination host, the user@domain syntax
Xor the domain!user syntax may be used.
X.P
XAll hosts conforming to this standard are class 3, and all
Xsubdomain gateways must be class 3 hosts.
X.H 1 "Example"
X.P
XSuppose host A.D.COM sends mail to host C.D.COM.
XLet's suppose that the 6 letter names for these hosts are aname and dname,
Xand that the intermediate host to be routed through has name bname.
X.P
XThe user on A types
X.DS I
Xmail user@c.d.com
X.DE
XThe user interface creates a file such as
X.DS I
XDate: 9 Jan 1985 8:39 EST
XFrom: myname@A.D.COM (My Name)
XSubject: sample message
XTo: user@c.d.com
X
XThis is a sample message
X.DE
Xand passes it to the transport mechanism with a command such as
X.DS I
Xsendmail user@c.d.com < file
X.DE
XThe transport mechanism looks up a route to c.d.com.
XIt does not find c.d.com in its database, so it
Xlooks up d.com, and finds that the
Xpath is bname!dname!%s, and that c.d.com is a class 3 host.
XPlugging in c.d.com!user, it gets the path bname!dname!c.d.com!user.
X(If it had found c.d.com with path bname!cname!%s, it would have
Xomitted the domain from the resulting path: bname!cname!user, since
Xit is not sure whether the destination host is class 1, 2, or 3.)
X.P
XIt prepends a From_ line and passes it to uux:
X.DS I
Xuux - bname!rmail dname!c.d.com!user < file2
X.DE
Xwhere file2 contains
X.DS I
XFrom A.D.COM!user Wed Jan 9 12:43:35 1985 remote from aname
XDate: 9 Jan 1985 8:39 EST
XFrom: myname@A.D.COM (My Name)
XSubject: sample message
XTo: user@c.d.com
X
XThis is a sample message
X
X.DE
X(Note the blank line at the end of the message - at least one blank
Xline is required.)
XThis results in the command
X.DS I
Xrmail dname!c.d.com!user
X.DE
Xrunning on B. B prepends its own from line and passes the mail along:
X.DS I
Xuux - dname!rmail c.d.com!user < file3
X.DE
Xwhere file3 contains
X.DS I
XFrom nuucp Wed Jan 9 12:43:35 1985 remote from bname
X>From A.D.COM!user Wed Jan 9 11:21:48 1985 remote from aname
XDate: 9 Jan 1985 8:39 EST
XFrom: myname@A.D.COM (My Name)
XSubject: sample message
XTo: user@c.d.com
X
XThis is a sample message
X
X.DE
X.P
XThe command
X.DS I
Xrmail c.d.com!user
X.DE
Xis run on C, which stacks the From_ lines
X.DS I
XFrom bname!aname!A.D.COM!user Wed Jan 9 12:43:35 1985
XDate: 9 Jan 1985 8:39 EST
XFrom: myname@A.D.COM (My Name)
XSubject: sample message
XTo: user@c.d.com
X
XThis is a sample message
X
X.DE
Xand stores the message locally, probably in this same format.
X.H 1 "Summary"
X.P
XHosts conforming to this standard should accept all of the following
Xforms:
X.DS I
X.ta 3i
Xrmail localuser (no !%@ in user)
Xrmail hosta!hostb!user (no !%@ in user)
Xrmail user@domain (only . in domain)
Xrmail domain!user (at least 1 . in domain)
Xrmail domain.!user (in case domain has no dots)
X.DE
X.P
XThe ``envelope'' portion of the message (``From_'' lines) should
Xconform to existing conventions, using ! routing.
XThe ``heading'' portion of the message (the Word: lines such as Date:,
XFrom:, To:, and Subject:) must conform to RFC822.
XAll header addresses must
Xbe in the @ form. The originating site should ensure that the addresses
Xconform to 822, since no requirement is placed on forwarding sites or
Xgateways to transform addresses into legal 822 format.
X(Such forwarding sites and gateways should NOT, however, change a legal
X822 address such as user@domain into an illegal 822 address such as
Xgateway!user@domain, even if forwarding to a class 1 UUCP host.)
X.nf
X#
X# @(#)rfc976.mm 2.1 smail 12/14/86
X#
@//E*O*F doc/rfc976.mm//
if test 21687 -ne "`wc -c <'doc/rfc976.mm'`"; then
echo shar: error transmitting "'doc/rfc976.mm'" '(should have been 21687 characters)'
fi
fi # end of overwriting check
echo shar: extracting "'src/patchlevel'" '(12 characters)'
if test -f 'src/patchlevel' ; then
echo shar: will not over-write existing file "'src/patchlevel'"
else
sed 's/^X//' >src/patchlevel <<'@//E*O*F src/patchlevel//'
XPatch #: 02
@//E*O*F src/patchlevel//
if test 12 -ne "`wc -c <'src/patchlevel'`"; then
echo shar: error transmitting "'src/patchlevel'" '(should have been 12 characters)'
fi
fi # end of overwriting check
echo shar: extracting "'MANIFEST'" '(1198 characters)'
if test -f 'MANIFEST' ; then
echo shar: will not over-write existing file "'MANIFEST'"
else
sed 's/^X//' >MANIFEST <<'@//E*O*F MANIFEST//'
X File Name Kit # Description
X-----------------------------------------------------------
X MANIFEST 2 This shipping list
X doc 1
X doc/Contacts 1
X doc/Domains 1
X doc/Flow.Diagram 1
X doc/Install 1
X doc/Read.Me 1
X doc/Registry 1
X doc/Trouble 1
X doc/aliases.8 1
X doc/domain.mm 2
X doc/lcasep.8 1
X doc/pathproc.8 1
X doc/paths.8 2
X doc/rfc920.txt 3
X doc/rfc976.mm 2
X doc/smail.8 2
X src 1
X src/Makefile 1
X src/alias.c 3
X src/defs.h 3
X src/deliver.c 4
X src/getopt.c 3
X src/getpath.c 3
X src/headers.c 4
X src/lcasep.c 3
X src/main.c 4
X src/make.cf.sh 4
X src/map.c 4
X src/misc.c 4
X src/patchlevel 2
X src/pathproc.sh 3
X src/resolve.c 4
X src/smail.prompt 4
X src/svbinmail.c 4
X src/sysexits.h 4
X src/template.cf 5
@//E*O*F MANIFEST//
if test 1198 -ne "`wc -c <'MANIFEST'`"; then
echo shar: error transmitting "'MANIFEST'" '(should have been 1198 characters)'
fi
fi # end of overwriting check
echo shar: "End of shell archive."
exit 0