Basically, I am trying to continue on the original author's TODO file. The
ones marked with a bang (!) are the author's and the ones with a plain
asterisk are my own. Probably, my own will get first preference! :-)

... and courdesy of yours truly, my VERY OWN Comments! :^)

-- Michael <mstrates@minkirri.apana.org.au>

* spawn a /real/ editor to edit the message.
I think this needs to be done.. CAREFULLY! I don't want to break anything
or cause any security holes.

* have a basic menued UI
well.. maybe a pineish interface, where you can send messages, view
messages and the likes? I'll make it that somebody has to run msend with a
+UI switch if they want the UI.

* pretty up this code
some of the code is pretty yucky.. gotta fix it up a little. Make it
better, tighter, smaller, sexier, and BugFree(tm).

* promote it
finally msend has come out of it's shell. i'm gonna promote, promote,
promote! :-)

! add .msgfwd files
This should be done. Perhaps we can extend to a daemon which will do this?
Or maybe I might go cheap-o and just write a little bit of code which will
e-mail you remotely any messages that need to be read.. Hmm, I perfer the
latter.

! add syslog stuff
Now, I don't think this is needed. Does anybody disagree? I suppose the
daemon could write logs, but I don't think the admin gives a .tar.gz about
that sort of stuff. Anyone?

! fix broken broadcast responses
Needs to be fixed. I'm working on it.

! add support for binary file transfers
This could be an interesting feature, but then again it might be a
security hole. Other systems running other implemenations of daemons won't
be able to decypher this. I'll add it (radix-64 encoding sound alright?),
but possibly with a message first saying "Binary Send of dog.tar.gz,
Send back YES to proceed". Then, they'll have to send back a reply if they
want to get that file. Could be abused?? 

! add features to replay sent messages and remove unread messages
An idea.. Maybe?

! make runnable from inetd
Yeah.. This should happen eventually.

! some non-cron way of expiring messages
A daemon running, perhaps that triggers. Perhaps ;-) we could include this
support into the mesgd?

! expiry should be based on file size too
This will need to be done, especially if this file transfer thing gets
implemented.