home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / r / rfc976.zip / RFC976.TXT < prev   
Text File  |  1987-04-19  |  27KB  |  685 lines
  1.  
  2.  
  3. Network Working Group                                    Mark. R. Horton
  4. Request for Comments: 976                              Bell Laboratories
  5.                                                            February 1986
  6.  
  7.                  UUCP Mail Interchange Format Standard
  8.  
  9.  
  10. Status of This Memo
  11.  
  12.    In response to the need for maintenance of current information about
  13.    the status and progress of various projects in the ARPA-Internet
  14.    community, this RFC is issued for the benefit of community members.
  15.    The information contained in this document is accurate as of the date
  16.    of publication, but is subject to change. Subsequent RFCs will
  17.    reflect such changes.
  18.  
  19.    This document defines the standard format for the transmission of
  20.    mail messages between machines in the UUCP Project.  It does not
  21.    address the format for storage of messages on one machine, nor the
  22.    lower level transport mechanisms used to get the data from one
  23.    machine to the next.  It represents a standard for conformance by
  24.    hosts in the UUCP zone.  Distribution of this memo is unlimited.
  25.  
  26. 1.  Introduction
  27.  
  28.    This document is intended to define the standard format for the
  29.    transmission of mail messages between machines in the UUCP Project.
  30.    It does not address the format for storage of messages on one
  31.    machine, nor the lower level transport mechanisms used to get the
  32.    data from one machine to the next.  We assume remote execution of the
  33.    rmail command (or equivalent) as the UUCP network primitive
  34.    operation.
  35.  
  36.    The general philosophy is that, if we were to invent a new standard,
  37.    we would make ourselves incompatible with existing systems.  There
  38.    are already too many (incompatible) standards in the world, resulting
  39.    in ambiguities such as a!b@c.d which is parsed a!(b@c.d) in the old
  40.    UUCP world, and (a!b)@c.d in the Internet world.  (Neither standard
  41.    allows parentheses, and in adding them we would be compatible with
  42.    neither.  There would also be serious problems with the shell and
  43.    with the UUCP transport mechanism.)
  44.  
  45.    Having an established, well documented, and extensible family of
  46.    standards already defined by the ARPA community, we choose to adopt
  47.    these standards for the UUCP zone as well.  (The UUCP zone is that
  48.    subset of the community connected by UUCP which chooses to register
  49.    with the UUCP project.  It represents an administrative entity.)
  50.    While the actual transport mechanism is up to the two hosts to
  51.    arrange, and might include UUCP, SMTP, MMDF, or some other facility,
  52.    we adopt RFC-920 (domains) and RFC-822 (mail format) as UUCP zone
  53.    standards.  All mail transmitted between systems should conform to
  54.  
  55.  
  56. Horton                                                          [Page 1]
  57.  
  58.  
  59.  
  60. RFC 976                                                    February 1986
  61. UUCP Mail Interchange Format Standard
  62.  
  63.  
  64.    those two standards.  In addition, should the ARPA community change
  65.    these standards at a later time, we intend to change our standards to
  66.    remain compatible with theirs, given a reasonable time to upgrade
  67.    software.
  68.  
  69.    This document specifies an interpretation of RFC-822 and RFC-920 in
  70.    the UUCP world.  It shows how the envelope should be encoded, and how
  71.    UUCP routing is accomplished in an environment of mixed
  72.    implementations.
  73.  
  74. 2.  Basics
  75.  
  76.    Messages can be divided into two parts: the envelope and the message.
  77.    The envelope contains information needed by the mail transport
  78.    services, and the message contains information useful to the sender
  79.    and receiver.  The message is divided into the header and the body.
  80.    Sometimes an intermediate host will add to the message (e.g. a
  81.    Received line) but, except in the case of a gateway which must
  82.    translate formats, it is not expected that intermediate hosts will
  83.    change the message itself.  In the UUCP world, the envelope consists
  84.    of the "destination addresses" (normally represented as the argument
  85.    or arguments to the rmail command) and the "source path" (normally
  86.    represented in one or more lines at the beginning of the message
  87.    beginning either "From " or ">From ", sometimes called "From_
  88.    lines".)  The RFC-822 header lines (including "From:" and "To:") are
  89.    part of the message, as is the text of the message body itself.
  90.  
  91.    UUCP uses short host names, such as "ucbvax", at and below the
  92.    transport layer.  We refer to these names as "6 letter names",
  93.    because all implementations of UUCP consider at least the first 6
  94.    letters significant.  (Some consider the first 7 or the first 14
  95.    significant, but we must use the lowest common denominator.) UUCP
  96.    names may be longer than 6 characters, but all such names much be
  97.    unique in their first 6 letters.  RFC-920 domain names, such as
  98.    "ucbvax.Berkeley.EDU", are called "domain names." The two names are
  99.    different.  Upper and lower case are usually considered different in
  100.    6 letter names, but are considered equivalent in domain names.  Names
  101.    such as "ucbvax.UUCP", consisting of a 6 letter name followed by
  102.    ".UUCP", previously were domain style references to a host with a
  103.    given 6 letter name.  Such names are being phased out in favor of
  104.    organizational domain names such as "ucbvax.Berkeley.EDU"
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Horton                                                          [Page 2]
  114.  
  115.  
  116.  
  117. RFC 976                                                    February 1986
  118. UUCP Mail Interchange Format Standard
  119.  
  120.  
  121. 2.1  Hybrid Addresses
  122.  
  123.    There are (among others) two major kinds of mailing address syntax
  124.    used in the UUCP world.  The a!b!c!user ("bang paths") is used by
  125.    older UUCP software to explicitly route mail to the destination.  The
  126.    user@domain ("domain") syntax is used in conformance to RFC-822.
  127.    Under most circumstances, it is possible to look at a given address
  128.    and determine which sort of address it is.  However, a hybrid address
  129.    with a ! to the left of an @, such as a!b@c, is ambiguous: it could
  130.    be interpreted as (a!b)@c.d or a!(b@c.d).  Both interpretations can
  131.    be useful.  The first interpretation is required by RFC-822, the
  132.    second is a de-facto standard in the UUCP software.
  133.  
  134.    Because of the confusion surrounding hybrid addresses, we recommend
  135.    that all transport layer software avoid the use of hybrid addresses
  136.    at all times.  A pure bang syntax can be used to disambiguate, being
  137.    written c.d!a!b in the first case above, and a!c.d!b in the second.
  138.    We recommend that all implementations use this "bang domain" syntax
  139.    unless they are sure of what is running on the next machine.
  140.  
  141.    In conformance with RFC-822 and the AT&T Message Transfer
  142.    Architecture, we recommand that any host that accepts hybrid
  143.    addresses apply the (a!b)@c.d interpretation.
  144.  
  145. 2.2  Transport
  146.  
  147.    Since SMTP is not available to much of the UUCP domain, we define the
  148.    method to be used for "remote execution" based transport mechanisms.
  149.    The command to be "remotely executed" should read
  150.  
  151.       rmail user@domain ...
  152.  
  153.    with the message on the standard input of the command.  The
  154.    "user@domain" argument must conform to RFC-920 and RFC-822.  More
  155.    than one address argument is allowed, in order to save transmission
  156.    costs for multiple recipients of the same message.
  157.  
  158.    An alternative form that may be used is
  159.  
  160.       rmail domain!user
  161.  
  162.    where "domain" contains at least one period and no !'s.  This is to
  163.    be interpreted exactly the same as user@domain, and can be used to
  164.    transport a message across old UUCP hosts without fear that they
  165.    might change the address.  The "user" string can contain any
  166.    characters except "@".  This character is forbidden because it is
  167.    unknown what an intermediate host might do to it. (It is also
  168.  
  169.  
  170. Horton                                                          [Page 3]
  171.  
  172.  
  173.  
  174. RFC 976                                                    February 1986
  175. UUCP Mail Interchange Format Standard
  176.  
  177.  
  178.    recommended that the "%" character be avoided, since some hosts treat
  179.    "%" as a synonym for "@".) However, to route across hosts that don't
  180.    understand domains, the following is possible
  181.  
  182.       rmail a!b!c!domain!user
  183.  
  184.    A "domain" can be distinguished from a 6 letter UUCP site name
  185.    because a domain will contain at least one period.  (In the case of
  186.    single level domains with no periods, a period should be added to the
  187.    end, e.g. Mark.Horton@att becomes "att.!Mark.Horton".  A translator
  188.    from ! to @ format should remove a trailing dot at the end of the
  189.    domain, if one is present.) We don't expect this to happen, except
  190.    for local networks using addresses like "user@host".
  191.  
  192.    A simple implementation can always generate domain!user syntax
  193.    (rather than user@domain) since it is safe to assume that gateways
  194.    are class 3 (Classes are explained in section 3.5).
  195.  
  196. 2.3  Batch SMTP
  197.  
  198.    Standard conforming implementations may optionally support a protocol
  199.    called "Batch SMTP".  SMTP (Simple Mail Transfer Protocol) is the
  200.    ARPA community standard mail transfer protocol (RFC-821). It is also
  201.    used on BITNET and Mailnet.  While SMTP was designed to be
  202.    interactive, it is possible to batch up a series of commands and send
  203.    them off to a remote machine for batch execution.  This is used on
  204.    BITNET, and is appropriate for UUCP.  One advantage to BSMTP is that
  205.    the UNIX shell does not get involved in the interpretation of
  206.    messages, so it becomes possible to include special characters such
  207.    as space and parentheses in electronic messages.  (Such characters
  208.    are expected to be popular in X.400 addresses.)
  209.  
  210.    To support BSMTP on UNIX, a conforming host should arrange that mail
  211.    to the user "b-smtp" is interpreted as Batch SMTP commands.  (We use
  212.    b-smtp instead of bsmtp because bsmtp might conflict with a login
  213.    name.) Since many mail systems treat lines consisting of a single
  214.    period as an "end of file" flag, and since SMTP uses the period as a
  215.    required end of file flag, and to strip off headers, we put an extra
  216.    "#" at the beginning of each BSMTP line.  On a sendmail system, an
  217.    easy way to implement this is to include the alias
  218.  
  219.       b-smtp: "|egrep '^#' | sed 's/^#//' | /usr/lib/sendmail -bs"
  220.  
  221.    which will feed the commands to an SMTP interpreter.  A better
  222.    solution would appropriately check for errors and send back an error
  223.    message to the sender.
  224.  
  225.  
  226.  
  227. Horton                                                          [Page 4]
  228.  
  229.  
  230.  
  231. RFC 976                                                    February 1986
  232. UUCP Mail Interchange Format Standard
  233.  
  234.  
  235.    An example BSMTP message from seismo.CSS.GOV to cbosgd.ATT.COM is
  236.    shown here.  This sample is the file shipped over the UUCP link for
  237.    in put to the command "rmail b-smtp".  Note that the RFC- 822 message
  238.    is between the DATA line and the period line.  The envelope
  239.    information is passed in the MAIL FROM and RCPT TO lines.  The name
  240.    of the sending system is in the HELO line.  The actual envelope
  241.    information (above the # lines) is ignored and need not be present.
  242.  
  243.       From foo!bar Sun Jan 12 23:59:00 1986 remote from seismo Date:
  244.       Tue, 18 Feb 86 13:07:36 EST
  245.       From: mark@ucbvax.Berkeley.EDU
  246.       Message-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU> To:
  247.       b-smtp@cbosgd.ATT.COM
  248.  
  249.       #HELO seismo.CSS.GOV
  250.       #MAIL FROM:<mark@ucbvax.Berkeley.EDU>
  251.       #RCPT TO:<mark@cbosgd.ATT.COM>
  252.       #DATA
  253.       #Date: Tue, 18 Feb 86 13:07:36 EST
  254.       #From: mark@ucbvax.Berkeley.EDU
  255.       #Message-Id: <8602181807.AA10228@mark@ucbvax.Berkeley.EDU> #To:
  256.       mark@cbosgd.ATT.COM
  257.       #
  258.       #This is a sample message.
  259.       #.
  260.       #QUIT
  261.  
  262. 2.4  Envelope
  263.  
  264.    The standard input of the command should begin with a single line
  265.  
  266.       From domain!user date remote from system
  267.  
  268.    followed immediately by the RFC-822 format headers and body of the
  269.    message.  It is possible that there will be additional From_ lines
  270.    preceding this line - these lines may be added, one line for each
  271.    system the message passes through.  It is also possible that the
  272.    "system" fields will be stacked into a single line, with many !'s in
  273.    the "user" string.  The ">" character may precede the "From".  In
  274.    general, this is the "envelope" information, and should follow the
  275.    same conventions that previous UUCP mail has followed.  The primary
  276.    difference is that, when the system names are stacked up, if
  277.    previously the result would have been a!b!c!mysys!me, the new result
  278.    will be a!b!c!mysys!domain!me, where domain will contain at least one
  279.    period, and "mysys" is often the 6 letter UUCP name for the same
  280.  
  281.  
  282.  
  283.  
  284. Horton                                                          [Page 5]
  285.  
  286.  
  287.  
  288. RFC 976                                                    February 1986
  289. UUCP Mail Interchange Format Standard
  290.  
  291.  
  292.    system named by "domain".  If the "domain!" is redundant, it may be
  293.    omitted from the envelope, either in the source path or in the
  294.    destination address.
  295.  
  296.    The receiving system may discard extra "From_" lines if it folds the
  297.    information into a a single From_ line. It passes the
  298.    path!domain!user along as the "envelope" information containing the
  299.    address of the sender of the message, and possibly preserves the
  300.    forwarding date and system in a newly generated header line, such as
  301.    Received or Sent-By.  (Adding Received using this information is
  302.    discouraged, since the line appears to have been added on a different
  303.    system than the one actually adding it.  That other system may have
  304.    actually included a Received line too! The Sent-By line is similar to
  305.    Received, but the date need not be converted into RFC-822 format, and
  306.    the line is not claimed to have been added by the system whose name
  307.    is mentioned.)
  308.  
  309.    If the receiving system passes the message along to another system,
  310.    it will add a "From_" line to the front, giving the same user@domain
  311.    address for the sender, and its own name for the system.  If the
  312.    receiving system stores the message in a local mailbox, it is
  313.    recommended that a single "From_" line be generated at the front of
  314.    the message, keeping the date (in the same format, since certain mail
  315.    reading programs are sensitive to this format), and not using the
  316.    "remote from system" syntax.
  317.  
  318.    Note - if an intermediate system adds text such as "system!" to the
  319.    front of a "user@domain" syntax address, either in the envelope or
  320.    the body, this is a violation of this standard and of RFC-822.
  321.  
  322. 2.5  Routing
  323.  
  324.    In order to properly route mail, it is sometimes necessary to know
  325.    what software a destination or intermediate machine is running, or
  326.    what conventions it follows.  We have tried to minimize the amount of
  327.    this information that is necessary, but the support of subdomains may
  328.    require that different methods are used in different situations.  For
  329.    purposes of predicting the behavior of other hosts, we divide hosts
  330.    into three classes. These classes are:
  331.  
  332.    Class 1   old-style UUCP ! routing only.  We assume that the host
  333.              understands local user names:
  334.  
  335.                   rmail user
  336.  
  337.  
  338.  
  339.  
  340.  
  341. Horton                                                          [Page 6]
  342.  
  343.  
  344.  
  345. RFC 976                                                    February 1986
  346. UUCP Mail Interchange Format Standard
  347.  
  348.  
  349.              and bang paths
  350.  
  351.                   rmail host1!host2!user
  352.  
  353.              but we assume nothing more about the host.  If we have
  354.              no information about a host, we can treat it as class 1
  355.              with no problems, since we make no assumptions about
  356.              how it will handle hybrid addresses.
  357.  
  358.    Class 2   Old style UUCP ! routing, and 4.2BSD style domain
  359.              parsing.  We assume the capabilities of class 1, plus
  360.              the ability to understand
  361.  
  362.                   rmail user@domain
  363.  
  364.              if the "domain" is one outside the UUCP zone which
  365.              the host knows about.  Class 2 hosts do not necessarily
  366.              understand domain!user or have routers.  Hosts in non-
  367.  
  368.              UUCP RFC-920 domains are considered class 2, even though
  369.              they may not understand host!user.
  370.  
  371.    Class 3   All class 1 and 2 features are present.  In addition,
  372.              class 3 hosts must be able to route UUCP mail for hosts
  373.              that are not immediately adjacent and also understand
  374.              the syntax
  375.  
  376.                   rmail domain!user
  377.  
  378.              as described above.  All gateways into UUCP must be
  379.              class 3.
  380.  
  381.    This document describes what class 3 hosts must be able to process.
  382.    Classes 1 and 2 already exist, and will continue to exist for a long
  383.    time, but are viewed as "older systems" that may eventually be
  384.    upgraded to class 3 status.
  385.  
  386. 3.  Algorithm
  387.  
  388.    The algorithm for delivering a message to an address "user@domain"
  389.    over UUCP links can be summarized as follows:
  390.  
  391.       a.  If the address is actually of the form @domain1:user@domain2,
  392.           the "domain" used for the remainder should be "domain1"
  393.           instead of "domain2", and the bang form reads
  394.           domain1!domain2!user.
  395.  
  396.  
  397.  
  398. Horton                                                          [Page 7]
  399.  
  400.  
  401.  
  402. RFC 976                                                    February 1986
  403. UUCP Mail Interchange Format Standard
  404.  
  405.  
  406.       b.  Determine d: the most specific part of "domain" that is
  407.           recognized locally.  This part will be a suffix of "domain".
  408.           This can be done by scanning through a table with entries that
  409.           go from specific to general, comparing entries with "domain"
  410.           to see if the entries are at the tail of "domain".  For
  411.           example, with the address "mark@osgd.cb.att.com", if the local
  412.           host recognizes "uucp" and "att.com", d would be "att.com".
  413.           The final entry in the table will be the null string, matching
  414.           any completely unrecognized domain.
  415.  
  416.       c.  Look in the found table entry for g: the name of the
  417.           "gateway", and for r: a UUCP !-style route to reach g.  G is
  418.           not necessarily directly connected to the local host, but
  419.           should be viewed as a gateway into the d domain.  (The values
  420.           of g and r for a given d may be different on different hosts,
  421.           although g will often be the same.)
  422.  
  423.       d.  Look at the beginning of r to find the "next hop" host n. N
  424.           will always be directly connected to the local host.
  425.  
  426.       e.  Determine, if possible, the class of g and n.
  427.  
  428.       f.  Create an appropriate destination string s to be interpreted
  429.           by n.  (See below.)
  430.  
  431.       g.  Pass the message off to n with destination information s.
  432.  
  433.       In an environment with other types of networks that do not use
  434.       UUCP !  parsing, the table will probably contain additional
  435.       information, such as which type of link to use.  The path
  436.       information may be replaced in other environments by information
  437.       specific to the network.
  438.  
  439.       The first entries in the table mentioned in part (b) are normally
  440.       very specific, and allow well known routes to be constructed
  441.       directly instead of routing through the domain tree.  The domain
  442.       tree should be reserved for cases where no better information is
  443.       available, or where traffic is very light, or where the default
  444.       route is the best available.  If a better route is available, that
  445.       information can be put in the table.  If a host has any
  446.       significant amount of traffic sent to a second host, it is
  447.       normally expected that the two hosts will set up a direct UUCP
  448.       link and make an entry in their tables to send mail directly, even
  449.       if they are in separate domains.  Routing tables should be
  450.       constructed to try to keep paths short and inexpensive for as much
  451.       traffic as possible.
  452.  
  453.  
  454.  
  455. Horton                                                          [Page 8]
  456.  
  457.  
  458.  
  459. RFC 976                                                    February 1986
  460. UUCP Mail Interchange Format Standard
  461.  
  462.  
  463.       Here are some hints for the construction of the destination string
  464.       n (step f above.) The "envelope recipient" information (the
  465.       argument(s) to rmail) may be in either domain ! form
  466.       (host.com!user) or domain @ form (user@host.com) as long as the
  467.       sending site is sure the next hop is class 3.  If the next hop is
  468.       not class 3, or the sending site is not sure, the ! form should be
  469.       used, if possible, since it is hard to predict what the next hop
  470.       would do with a hybrid address.
  471.  
  472.       If the gateway is known to be class 3, domain ! form may be used,
  473.       but if the sending site is not sure, and the entire destination
  474.       string was matched in the lookup (rather than some parent domain),
  475.       the 6 letter ! form should be used: r!user, for example:
  476.       dumbhost!host!user.  If the gateway appears to actually be a
  477.       gateway for a subdomain, e.g. because a parent domain was matched,
  478.       (such as the address user@host.gateway.com, where host.gateway.com
  479.       was not found but gateway.com was) it can be assumed to be at
  480.       class 3.  This allows routes such as
  481.       dumbhost!domain!host.domain.com!user to be used with a reasonable
  482.       degree of safety.  If a direct link exists to the destination
  483.       host, the user@domain syntax or the domain!user syntax may be
  484.       used.
  485.  
  486.       All hosts conforming to this standard are class 3, and all
  487.       subdomain gateways must be class 3 hosts.
  488.  
  489. 4.  Example
  490.  
  491.    Suppose host A.D.COM sends mail to host C.D.COM.  Let's suppose that
  492.    the 6 letter names for these hosts are aname and dname, and that the
  493.    intermediate host to be routed through has name bname.
  494.  
  495.    The user on A types
  496.  
  497.       mail user@c.d.com
  498.  
  499.    The user interface creates a file such as
  500.  
  501.       Date:  9 Jan 1985   8:39 EST
  502.       From: myname@A.D.COM (My Name)
  503.       Subject: sample message
  504.       To: user@c.d.com
  505.  
  506.       This is a sample message
  507.  
  508.    and passes it to the transport mechanism with a command such as
  509.  
  510.  
  511.  
  512. Horton                                                          [Page 9]
  513.  
  514.  
  515.  
  516. RFC 976                                                    February 1986
  517. UUCP Mail Interchange Format Standard
  518.  
  519.  
  520.       sendmail user@c.d.com < file
  521.  
  522.    The transport mechanism looks up a route to c.d.com.  It does not
  523.    find c.d.com in its database, so it looks up d.com, and finds that
  524.    the path is bname!dname!%s, and that c.d.com is a class 3 host.
  525.    Plugging in c.d.com!user, it gets the path bname!dname!c.d.com!user.
  526.    (If it had found c.d.com with path bname!cname!%s, it would have
  527.    omitted the domain from the resulting path: bname!cname!user, since
  528.    it is not sure whether the destination host is class 1, 2, or 3.)
  529.  
  530.    It prepends a From_ line and passes it to uux:
  531.  
  532.       uux - bname!rmail dname!c.d.com!user < file2
  533.  
  534.    where file2 contains
  535.  
  536.       From A.D.COM!user Wed Jan  9 12:43:35 1985 remote from aname Date:
  537.       9 Jan 1985   8:39 EST
  538.       From: myname@A.D.COM (My Name)
  539.       Subject: sample message
  540.       To: user@c.d.com
  541.  
  542.       This is a sample message
  543.  
  544.    (Note the blank line at the end of the message - at least one blank
  545.    line is required.) This results in the command
  546.  
  547.       rmail dname!c.d.com!user
  548.  
  549.    running on B.  B prepends its own from line and passes the mail
  550.    along:
  551.  
  552.       uux - dname!rmail c.d.com!user < file3
  553.  
  554.    where file3 contains
  555.  
  556.       From nuucp Wed Jan  9 12:43:35 1985 remote from bname >From
  557.       A.D.COM!user Wed Jan  9 11:21:48 1985 remote from aname Date:  9
  558.       Jan 1985   8:39 EST
  559.       From: myname@A.D.COM (My Name)
  560.       Subject: sample message
  561.       To: user@c.d.com
  562.  
  563.       This is a sample message
  564.  
  565.  
  566.  
  567.  
  568.  
  569. Horton                                                         [Page 10]
  570.  
  571.  
  572.  
  573. RFC 976                                                    February 1986
  574. UUCP Mail Interchange Format Standard
  575.  
  576.  
  577.    The command
  578.  
  579.       rmail c.d.com!user
  580.  
  581.    is run on C, which stacks the From_ lines
  582.  
  583.       From bname!aname!A.D.COM!user Wed Jan  9 12:43:35 1985 Date:  9
  584.       Jan 1985   8:39 EST
  585.       From: myname@A.D.COM (My Name)
  586.       Subject: sample message
  587.       To: user@c.d.com
  588.  
  589.       This is a sample message
  590.  
  591.    and stores the message locally, probably in this same format.
  592.  
  593. 5.  Summary
  594.  
  595.    Hosts conforming to this standard should accept all of the following
  596.    forms:
  597.  
  598.       rmail localuser               (no !%@ in user)
  599.       rmail hosta!hostb!user        (no !%@ in user)
  600.       rmail user@domain             (only . in domain)
  601.       rmail domain!user             (at least 1 . in domain)
  602.       rmail domain.!user            (in case domain has no dots)
  603.  
  604.    The "envelope" portion of the message ("From_" lines) should conform
  605.    to existing conventions, using ! routing.  The "heading" portion of
  606.    the message (the Word: lines such as Date:, From:, To:, and Subject:)
  607.    must conform to RFC-822.  All header addresses must be in the @ form.
  608.    The originating site should ensure that the addresses conform to
  609.    RFC-822, since no requirement is placed on forwarding sites or
  610.    gateways to transform addresses into legal RFC-822 format.  (Such
  611.    forwarding sites and gateways should NOT, however, change a legal
  612.    RFC-822 address such as user@domain into an illegal RFC-822 address
  613.    such as gateway!user@domain, even if forwarding to a class 1 UUCP
  614.    host.)
  615.  
  616. 6.  References
  617.  
  618.    [1]  Postel, J., "Simple Mail Transfer Protocol", RFC-821,
  619.         USC/Information Sciences Institute, August, 1982.
  620.  
  621.    [2]  Crocker, D., "Standard for the Format of ARPA Internet Text
  622.         Messages", RFC-822, Department of Electrical Engineering,
  623.         University of Delaware, August, 1982.
  624.  
  625.  
  626. Horton                                                         [Page 11]
  627.  
  628.  
  629.  
  630. RFC 976                                                    February 1986
  631. UUCP Mail Interchange Format Standard
  632.  
  633.  
  634.    [3]  Postel, J., and J. K. Reynolds, "Domain Requirements", RFC-920,
  635.         USC/Information Sciences Institute, October, 1984.
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683. Horton                                                         [Page 12]
  684.  
  685.