must be done
Dave Nichols' MT translator should be called in two places (both marked with comments in the code): when mail in SMTP format is 
being sent to Grapevine, and when mail in GV format is being sent to the Arpanet.  At one time, use of Bob Nix's pipes seemed the 
best way to do this.  I don't know if the structure still supports this, or if an overlayed stream would be better.  [SMTPSend and 
SMTPGVSend]

The ForProcessingDemon (SMTPQueue) has been written but is commented out because the procs to do the user/domain translation have 
not been written.  All of the parsing for the SMTP side has been written and is used by SMTPRcvr to check incoming command lines.  
This "checking" code should be separated out from SMTPRcvr and put into SMTPSyntax so that it can also be used by the Processing 
procs.  I also know that there are some bugs still in this code.  It accepts most correct input (it does NOT accept a null path, 
which it should), but I have seen it hang when TelNetting incorrect syntax through MAX.  There will need to be two Processing 
procs: one to take a reverse path/ return path in SMTP/ GV format and derive both the new SMTP and GV reverse paths; the other to 
take a recipient and derive the new recipient (e.g. strip off PARC-GW) and convert (if necessary) to SMTP/ GV format (for whichever 
domain the recipient is in).  [SMTPRcvr, SMTPSyntax, SMTPQueue]

I caught it munging the message text when sending Grapevine messages to MAX, which it wasn't doing the other day.  It was dropping 
the newlines and succeeding char.  It is worth using the PrintGVBody function (through the interpreter) to ensure the body is being 
properly read from the file.  [SMTPSyntax, SMTPSend]

The server really must be more thoroughly tested before being put into service.
should be done
Responses to Grapevine poll requests should be multiply sent because they tend to get lost when going through a gateway, causing 
the server to think we are down and wait 15 mins before trying again.  [SMTPGVRcvr]

The Descriptors are currently not monitored.  Much of the mutual exclusion is done by the queue locks.  However, it might be 
possible for the two delivery demons to attempt to delete recipient hosts, or a demon and the user to update the item and store the 
changes on file at the same time.  The descriptor should be locked by the ForProcessingDemon while it is processing the reverse 
path and recipients, and by the delivery demons when they are removing recipient hosts.  I think a lock similar to that in Queue 
should be implemented so that user requests to change items can timeout if the item is locked.

The logging procs currently write to a viewer.  This should also be sent to a file.  Only the entries whose priority exceeds the 
current minimum acceptance priority are written to the viewer.  All entries should probably be written to the file.  It would be 
nice to have some functions for post processing this file.  [SMTPSupport]

The server should be converted from Cedar4.4 to Cedar5.0.  I wrote the code by looking at the 5.0 interfaces and structuring my 
code for them, then making whatever cludges to use the 4.4 interfaces.  The server will run faster in 5.0 (excluding any changes in 
Cedar speed) because I have used things like block copy and file copy in 5.0 but char copy in 4.4.  Also, I have neglected to catch 
some errors in the 4.4 code because of structural differences required to handle different errors in the two releases.  So, fewer 
things will go wrong in the 5.0 code (modulo bug differences).  Some of the code has actually been compiled for 5.0.  The best way 
to approach this is to search for occurrences of "Cedar4.4" which will be at the end of lines with 4.4 code and will have 
geographically close (usually succeeding) lines commented out giving the corresponding 5.0 code.  I'm sure I didn't catch all of 
the differences, but I would bet 90%.  I suggest commenting out the 4.4. lines and commenting in the 5.0 lines until you're through 
debugging rather than deleting the 4.4 ones.  [all modules]

The current way of naming returned mail item files (just add an "R" after the original name) is insufficient because two separate 
instances of the item may be returned (e.g. if item going to more than one host and more than one host fails the item), both having 
the same name.  [SMTPDescr]

I don't currently ensure that the maximum lengths for SMTP things like paths, lines, number of recipients, etc. are not exceeded.  
On the incoming side, no limits are imposed (I think), but they may exceeded for outgoing mail.  [SMTPRcvr, SMTPSend]

Much of the code is fairly well commented, but there are some modules, particularly those I changed in the past few weeks, which 
need more/ updated comments.
wish list
It would be nice to have a proper command viewer with menus, possibly similar to the SMTP.menu file, but with the idea of currently 
selected item/ element, and with the queue behavior dynamically displayed.

There are actually two parts to the SMTP server: the protocol stuff (SMTPDescr, SMTPRcvr, SMTPGVRcvr, SMTPSend, SMTPGVSend, and 
SMTPSyntax) and the server stuff (SMTPSupport, SMTPControl, SMTPQueue, Queue).  It would be nice to separate these.

It might be worthwhile being able to spy on SMTP conversations (via dribble streams?) for debugging.