diplodocus.org Git - nmh/blob - docs/historical/mh-jun-1982/progs/UUCP.MEMO

   1       Several changes have been made recently, primarily to
   2 adrparse.c, adrformat.c, deliver.c, rmail.c,  and repl.c.
   3 These changes permit MH messages to flow between the host
   4 machine, the Arpanet, and the UUCP system.  A description
   5 of how all this works is included here.
   6
   7 A. SENDING MAIL
   8
   9 1) Arpanet mail.  When a message is destined for the Arpanet,
  10    a single copy of that message is placed in /usr/spool/netmail,
  11    headed by a list of remote recipients.  A mailer daemon
  12    picks these up and delivers them via the FTP "MAIL" command.
  13    If the local site is NOT an Arpanet site, the Arpanet address
  14    is simply considered as a local address.  One could, conceivably,
  15    have a local user named "a@ucla-s", after all.
  16
  17 2) UUCP mail.  As DELIVER is processing the message, it is producing
  18    a SECOND copy of the message in /usr/tmp/mh/uu*.  This copy
  19    differs from the normally-delivered copy in that no "format"
  20    operation is ever done, and in that no "From: " line is
  21    added to the header (the user may still have one if he
  22    thinks he knows what he's doing).  For each message destined
  23    for a UUCP site, say "site!person", a header is prepended
  24    of the form "From <local-user> <date> remote from <local-site>".
  25    This message is then given as standard input to a command
  26    like "uux - site!rmail person".  Note that "person" may not
  27    contain blanks.  If it contains additional uucp routing,
  28    the form is "uux - site!rmail (more!person)".  Evidently,
  29    without the parens, Uux considers "more!person" to be
  30    the name of a remote file.
  31
  32 B. RECEIVING MAIL
  33
  34 1) Arpanet Mail.  Mail from the Arpanet is received by the
  35    FTP Server daemon via the MAIL (or MLFL) command.  At
  36    present, this server invokes the "rmail" program, which
  37    purports to be the name of the standard Unix remote mail
  38    program.  Supposedly, this would even work on a system
  39    not running MH or anything special.  Right.  Anyhow,
  40    the Rmail associated with MH copies its input into a
  41    file and gives that file to Deliver, with the special
  42    option, "-deliverto <recipient>".  This option is
  43    reserved to the super-user and members of Uucp's
  44    group (constant DAEMON_GROUP in deliver.c .  It varies
  45    between the /45 and the Vax, unfortunately).  If
  46    it were not so restricted, anybody could send mail
  47    with forged signatures ("From: " lines).  When
  48    Deliver is given that option, it does nothing but
  49    deliver the file as it sees it to the specified
  50    recipient, be it local or remote.  No formatting
  51    or additional "From:" or "Date" processing is
  52    performed, although Uucp "From" lines ARE added if needed.
  53
  54 2) UUCP mail.  As noted, Uucp mail happens when some
  55    remote site executes Rmail via Uux.  Out there
  56    in the real world, the only thing you can expect
  57    a message to have is one of those "From <user> <date>"
  58    lines at the beginning.  Perhaps several, if
  59    it's been through this process before.  Rmail is
  60    able to take these lines and turn them into
  61    a sensible line like "From: site1!site2!site3!person".
  62    If a reasonable Arpa header follows (and it's pretty
  63    crude about "reasonable"), Rmail just prepends that
  64    From: line and copies the input into a file and
  65    gives it to Deliver as in the Arpanet case.  If not,
  66    it adds an extra blank line, thus leaving you
  67    with a header consisting of just the From: line.
  68    Deliver then sends the formatted-as-best-we-could
  69    message to the specified recipient.
  70    In the special case in which the destination is
  71    another Uucp site (rmail sitex!person), NO processing
  72    is done before invoking Deliver; Deliver will
  73    add the obligatory extra "From" line at the beginning
  74    of the Uucp output.
  75
  76 KNOWN problems.
  77
  78    When mail is going to somewhere like "graphics!person",
  79    and there are "cc:" lines, these "cc:" lines are not
  80    formatted in such a way as to allow automatic replies.
  81    Note that they would have to be different for local
  82    users than they would be for the remote user.
  83
  84    Similarly, when a message gets sent to someone like
  85    "graphics!mike@ucla-s", the "To: " line is going to
  86    contain that "graphics!" when it gets to the remote
  87    Arpanet site.  This will be wrong, there.  Note again
  88    that local users getting a carbon copy will want
  89    that information to appear.
  90
  91    When a message comes from the Arpanet and gets forwarded
  92    to Uucp, it arrives at the destination site with
  93    a Uucp-style "From xxx remote from yyy" line at the
  94    beginning, and an ARPA-style "From: " line which was
  95    generated at the original site.  Rmail will cause
  96    you to end up with two Arpa-style From lines,
  97    "From: yyy!xxx" and the original one.  Repl will be
  98    able to start up OK, and will try to reply to both.
  99    Unfortunately, NEITHER will be right.  This is rather
 100    difficult to fix without modifying the original Arpa
 101    header.  Impossible, in fact.
 102
 103    You can send messages to graphics!person@host.  However
 104    if you try to send it to "graphics!person at host", you
 105    will indeed execute "graphics!rmail person at host".
 106    This will cause Rmail to choke (too many args).  You never
 107    get to hear about it when Uux chokes.
 108
 109    In general, Rmail should make a better effort to see if
 110    things went OK, and send a return message if they didn't.
 111    Similarly, the FTP server should make sure Rmail died
 112    happy, and reply with a failure code (412 or something,
 113    isn't it?)  when things don't run smoothly.  The
 114    Arpanet Mailer, by the way, is pretty good about reporting
 115    its failures.
 116
 117    Replying to messages from various sources works pretty well.
 118    However, people who try to invoke the "-format" option
 119    when no Arpanet is present currently get a screwy result
 120    like "at (local)" getting glued to the end of addresses.
 121    Frankly, the "format" option should be completely disabled
 122    at non-Arpa sites, as near as I can tell.  This applies
 123    both to "repl" as well as "send" (deliver).
 124
 125    While "Ali" has been changed to understand that Uucp and
 126    Arpanet addresses should not be checked for validity,
 127    there are common subroutines in Ali and Deliver which
 128    are Very Similar, though their calling sequences and
 129    usages vary somewhat.  It would be Aesthetically Preferable
 130    to break these routines out and put them in "subs".
 131
 132         Mike Urban
 133         3/81