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.

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.

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.