To:  "Gary Brown" <brown@cis.santarosa.edu>,
     "Lloyd Onyett" <Onyett_Lloyd/SRJC_01@odie>,
     "Dave Johnston" <dave@cs.santarosa.edu>,
     "Dane Jasper" <jasper@bcl.santarosa.edu>,
     "Peter Crayne" <pcrayne>,
     "Scott Doty" <scott@cs.santarosa.edu>,
     "Rich Abrahams" <Abrahams_Rich/SRJC_01@odie>,
     "Jay Field" <Field_Jay/SRJC_01@odie>,
     "John Hemenway" <Hemenway_John/SRJC_01@odie>
From: "Scott Doty" <sdoty@NERMAL.SANTAROSA.EDU>
Organization: Santa Rosa Junior College
Date:         16 Oct 92 03:50:00 PDT
Subject:      Nermal: report for 8 sep 92 - 15 oct 92.
Reply-To:     scott@cs.santarosa.edu
X-Pmrqc:      1
X-Pmlist:     Project nermal

The following is archived on nermal under:  /usr/adm/nermal/worklog.6
____________________________________________________________________
Objective 2:  User application installation (from source)   (6 Nov)
Objective 3:  Management under user loading, campus-wide
               message base.                                (11 Dec)

Task                                         Status
-----------------------------------------------------
Software installation (system/user binaries) Pending Mail system (1)
Software installation (user apps fm/sources) Pending (2)
-----------------------------------------------------

(1)  New System binaries:  ("*" denotes compiled on site.)
	  smtpout (*), smtpd (*), mail(*) [See Remarks (a)]
	  Active network services:
          smtp, telnet, ftp, finger, discard, daytime, chargen.

(2)  New User Applications:
	  hytelnet (*) [See Remarks (b)]

Remarks:

(A) (even more) Fun with mail

                        Incoming mail --works--!

The smsmtp package runs like a top!  I'm very happy with it.
Here's the breakdown on nermal's mail system:
Overall system:
  there is now a "mail" uid -- this is how /bin/mail figures
  out that a message originated on a remote system.

Incoming mail: (the blow-by-blow)
  1) When inetd detects an incoming mail connection, it spawns smtpd.
  (smtpd, when invoked, sets effective user id and effective group id
  to "mail")
  2) I have modified smtpd, so that the message originator in the
  "MAIL FROM: " command is saved in an environment variable.
  3) smtpd calls /bin/[r]mail to deliver the message.
  4) When /bin/mail sets the message originator (for the "From " line
  in the header), it checks to see if it was invoked by the mail
  agent.  If so, it reads the environment variable set in step 2,
  and uses *that* as the originator.
  5) Also, /bin/mail used to write a duplicate "To: " line in the
  header.  (Remote mail already contains the "To: " line.)  I have
  corrected this.
  6) The /bin/mail command then proceeds just as if the mail was
  sent locally.  If an error occurs, the error is passed to smtpd,
  which passes it to the remote connection (still in progress.)  Otherwise,
  smtpd send "ok", and the connection closes.  (Or, if the remote system
  has more mail, smtpd accepts *that*...and so on.)

Outgoing mail: (just general stuff)
  I've modified smtp to act like /bin/mail -- it now accepts multiple
  arguments on the command line.  I've named the revised program,
  "smtpout," and I've put it in the /bin directory.  /bin/mail will
  eventually use this as it's remote mailer.
  /bin/mail doesn't yet know about smtpout.  This will soon change.  :)
  /bin/smtpout accepts multiple recipients in the same way /bin/mail
  does.  For instance:
  "/bin/smtpout sdoty@odie dave@cs.santarosa.edu < message"
  would transmit the file "message" to user "sdoty" on host "odie," as
  well as "dave" on host "cs.santarosa.edu."  (This is how this message
  was distributed, by the way...)  Fortunately, users don't have
  to deal with this syntax -- Elm (the mail user interface) and /bin/mail
  take care of it for them.

Mail bugs:
  /bin/mail was written by Ed Carp for uucp mail.  While it does its
  job quite nicely, it's not very informative with error codes.  smtpd
  expects particular error codes for particular errors.  Thus, if something
  goes wrong, smtpd probably won't tell the remote system much more than
  "that didn't work."  The solution:  I need to go through all of
  /bin/mail's modules and replace the silly error codes with the
  descriptive codes that smtpd expects.  smtpd came with a header file
  with *extremely* descriptive comments on which error belongs with
  which condition, so hopefully this won't be too much of a problem.

(B) Curses!  Hytelnet!  :)
Dave sent me the new Hytelnet (which he is also putting on odie) -- it
now resides on nermal in /usr/local/hytelnet.

"Curses" is a generic terminal interface for Unix, and is used by
Hytelnet.  Apparently, the curses "getch()" routine has a problem when
stdin is an AF_INET socket.  So, for the moment, Hytelnet works only
on nermal's dialup line.  (I've noticed this problem with other
programs, and gopher is one of them.  Time for more research...)

Coming up next:
	  Mail system modifications:
		 /bin/mail to work better with smtpd (error codes)
		 /bin/mail to invoke /bin/smtpout
				...which will conclude the mail system.
     Network news reader debugging (rn)
     Manual system augmentation (groff)
	  Minor patches to file transfer system (ftpd)
	  Curses!
_____________________________________________________________________
= Scott Doty, KB6ZLX                      Santa Rosa Junior College =
= Technician, Campus Data & Hardware      1501 Mendocino Ave.       =
= Internet: Scott@cs.santarosa.edu        Santa Rosa, CA  95401     =