Things to do:

1).  When doing a REPLY, the "To" line you get from MAIL is empty.  Currently
     this causes a blank X-VMS-Mail-To: field.  Should I check for this and
     chuck that field completely?
  *  Done... (consider it chucked)

2).  Need to use ARPA RFC-822 standardized dates.  Yuck!  Only problem is
     how do I make up the time zone?????
  *  Done....  Needed system wide logical name for time-zone. Should get
               an algorithm to calculate savings versus daylight time for
               a given zone.

3).  Obviously this whole thing needs testing.  There have to be some nasty
     bugs lurking around in it somewhere!
  *  Looks pretty good after 6 months!

4).  Need to test in conjunction with DECnet.  Can I get mail from other
     DECnet nodes to/from UUCP cleanly?  How about caveats and addressing
     issues?
  *  Done...  At least I know what I have to do.  See number 6.

5).  Need to do error handling, etc...  Maybe return undeliverable mail
     and other nasty stuff.  This is hard.

6).  Need to convert DECnet addresses into another form.  Will need file
     of reachable systems and how to get to them:

	fvax	decnet
	ymir	uucp
	cit-vax	uucp
	scgvaxd	smtp

     then:  when building from, convert anything like host::user into
     host!user.  When making to, convert host!user and host::user and
     user@host into one of:

	smtp%"user@host"
	uucp%"host!user"
	host::user

     or error "unknown system".

7).  Once having sent a UUCP message, MAIL cannot get SYSPRV to deliver
     local messages.   grrrrrrrrrrr!   Have to exit mail and reenter
     to send local mail.  This is simple.  Just need to NOT modify privs
     if process already has the priv.  Exactly what MAIL does internally.
     Will hack this in tonight.
  *  Done...

8).  When sending to a list of users, if the list begins with a local
     (or DECnet) address, then MAIL may use BLOCK_IO on the message
     file.  UUCP then breaks in GET_LINE with an "operation invalid
     for record type..." error from RMS.  This is because I only ever
     use record I/O.   Have to, need to read records to parse headers.
     I think this is a bug in MAIL.  After all, if the list begins
     with a UUCP address, it opens it for record I/O.
  *  Fixed, thanks to Ned Freed.  We just reconnect the RAB allowing
     either block or record IO.

9).  Need to rethink the way the _OUT_bound code decides if mail is originating
     here or routing through so it knows whether to make up headers or not.
     Currently it says "if the message has headers, it's probably not
     originating here so act like it's routing.  If not then make up headers
     like it came from here".   This is too stupid.  It gets confused too
     easily.  One thing I'm thinking about is in the _OUT_ code I get the
     address of who the message is FROM.  If it's from someone like UUCP%".."
     then it's obviously being routed.  If not then it needs headers.  I think
     that'll be a smarter way of doing it.
  -  Have rethought this one.  Now that MAIL isn't mapping the code in twice,
     I can use a global flag to indicate if the message going out also came in
     and hence needs header-munging, not header-making.  Not implemented yet.

10). Lines starting with "$" screw up incoming mail messages.  Something to
     do with the fact that that stupid subprocess that RMAIL spawns has
     the message coming from SYS$COMMAND.  Everything from the "$" line
     on is missing.
   * Done...  I wanted input from SYS$INPUT instead of SYS$COMMAND.  Problem
              was that SYS$INPUT was only a user mode logical, so was getting
              trashed by the SET PROC/PRIV command.  I now save P1 by doing
              an F$PARSE of it into itself.  This uncovered a bug in which
              UUCP_MAIL.PAS was not opening the file READONLY, so I got file
              locked errors.  Fixed that and now everything is just fine.

11). Had all sorts of problems with messages getting bounced because of
     long lines confusing Pascal IO.
   * Fixed.  Added very large max record lengths to WRITE statements.
	     Also made debug informational writes ignore IO errors.

12). Made the code use the RFC-822 "From:" field preferentially over the
     UUCP "From ... remote from ..." line because more and more people
     support reasonable message headers and they tend to ignore getting
     the UUCP header lines to work.  Can't say I blame them.