4.3BSD/usr/src/usr.lib/sendmail/adm/TODO

SHORT TERM TASKS

  * Elevate "vacation" to a real release program -- check man pages,
    install in /usr/ucb, etc.  May need some work -- it's still a bit
    tricky to use.

  * Throw in "smart UUCP" mailer that knows about neighbors that can
    handle more than one recipient at once.  This is easy and should
    be very useful for certain sites.  Configuration files should
    default to "dumb" however.

  * Clean up configuration on releases -- send out fewer Berkeley and
    more basic configs (e.g., BLI).

  * Verify that new name server doesn't confuse sendmail.

  * Only add Message-Id: if message is locally generated (???).

  * Improve documentation describing how to create a config file --
    probably means putting more configs on distrib.

  * Listen in UNIX domain (as well as INET)?

  * A way to mark addresses in the queue as you process them as "done" --
    probably by appending lines to the cf* file.  The point here is to
    avoid duplicate messages to large lists if a crash occurs during
    processing.  This is hard.



LONG TERM TASKS

  * Break up sendmail into several smaller programs:

	queueup -- insert message into mail queue; call runqueue when
		done -- called by user, smtpserver, cleanqueue (to return
		expired messages), etc.
	runqueue -- process queue entries -- take optional job name list
		to run only those jobs -- called by queueup and by cron
		to push the queue.
	printqueue -- print mail queue.
	cleanqueue -- return expired messages; basic consistency
		checking.
	smtpserver -- process smtp connections, pass to queueup -- this
		can probably become a simple service a la /etc/inetd.
	addrtest -- essentially "-bt" mode.
	verifyaddr -- verify an address list -- "-bv" mode -- needs a
		"noisy" and a "silent" mode (exit status only).  This
		should be the same code as smtpserver and queueup use
		to verify addresses.
			[This may want "shallow" and "deep" modes, where
			deep mode tries to connect to the remote site if
			on SMTP and issue a "VRFY" command.]
	newaliases -- build alias file -- should not be part of sendmail
		proper.  (See editalias below -- that would probably
		preempt -- although a text form will be critical for
		interchange.)

    It may be better to make runqueue a daemon on 4.2 and have queueup
    poke it (using a datagram).  This guarantees single threading (is this
    an advantage? -- long jobs can block the queue) and minimizes
    gratuituous forks/execs.  However, I feel strongly that portability
    is important -- the fork/exec method should still be included.

  * New programs:

	editalias -- front end to modify alias database, including
		"ownership" (so that people can modify lists that they
		own, but not other lists) -- see Grapevine papers --
		distributed????
	rmqueue -- remove a job from the queue.  Usual ownership rules
		should apply of course.

  * Change config file to be more understandable -- yacc grammar probably.
    Perhaps defaults should be compiled in whenever possible.

  * Only use rewriting rules to go to and from canonical format.  Other
    resolution should be defined by the name server (See MMDF).

  * Perhaps there should be a "compiled format" for the configuration
    file, something between a yacc-style config and the freeze file; very
    quick to read w/ low overhead.  [Suggest a struct with "char *" being
    index into a buffer area; these can be mapped internal <==> external
    easily.]

  * Move functionality:

	[]  Currently sendmail will rewrite "To: miriam mckusick" to
	    "To: miriam, mckusick" unless some "special" characters
	    are used (e.g.,  ()<>,;  -- characters specific to RFC822).
	    This should be moved to the user agent (Mail, rmail, MH,
	    etc.).  Big job because all user agents must be modified.
	[]  Would be nice if UUCP shit-format was handled by UUCP
	    itself.  This has serious performance implications unless
	    actually built into UUCP.

  * Non-sendmail related changes:

	[]  UUCP routing code (part of the name server really) -- can
	    the work that Peter Honeyman or others have done be useful?
	    [A significant point is making this work given incomplete
	    information -- yum yum.  Some database work in this area.]
	[]  Reply code in ucbMail has little relation to current mail
	    software.  "Smarts" should be stripped out.