Known/suspected bugs/Missing Features on current Zmailer sources

- Need to add the  sdbm ( support/sdbm/ ), and the new BSD db into
  the choices of DBM formats..

- autoconfig detection of DBMs is partial;
	- ndbm, gdbm  are ok
	- dbm (that OLD one!) does not work (SunOS 4.1)
	- sdbm -- never tested
	- BSD (new) db -- never tested

- multi-level subdirectories for the transport, and possibly for
  the queue -- and of course  /var/mail/x/x/x/username -mailboxes.
  Now having thousands of mailboxes in same directory does mean
  helluva slow access speeds..  (and same with transports directory)

- router/rfc822.c:  sequencer()
	Consider providing some data/function/whatever telling to
	the configuration script how many "Received:" headers there
	are so that the message can be trapped for a loop-prevention
	in the script, and not hardwired in the sequencer() code.
	(Now has a global variable that gets the count of "Received:"
	 headers, but the loop-count exceeded trap is done in the
	 C-code without calling the scripts...)

- scheduler/resources.c:
	full autoconfigurability of things is needed!

- Need a program to verify that given configuration is ok, checks
  for things like:
	- "nobody" userid
	- scheduler's resource control working to the maximum
	  extend that system supports
	- mmap() correct operation  (GNU autoconf did this)

- Need a program to run thru various file permission checks:
	- $MAILVAR/db/ -dir, and files in it
	- $MAILVAR/lists/ -dir, and files in it
	- ~/.forward -files (and home directories)

- Changes on 2.98/2.99 scrambled the list-expansion error-redirection
  mechanism somewhat.   The goal is to have there a separate auto-generated
  "Errors-To:" header for all addresses expanded from some list -- each
  list its own version.   It requires some more sorting in the sequencer,
  when the addresses are put in order, and then adding those to the
  transporter file, AND using individual "e"-entries for each recipient
  group on transport too!  (Now there is one global..)
	(fixed on 2.99.15 at scheduler with sub-optimal way)

- Manuals leave a lot to desire.. Especially a good users/administrators
  manual is in need

- transporters: Truly full-scale MIME-conversion facilities are in need!

- transporters: When decoding MIME-QP the final line MAY be of
		".....=", which means there is no final NEWLINE.
	Fixed on SMTP, must fix on MAILBOX, and SM!  (4-Jan-95)
	(Prepared to do it, however only on SMTP it is fatal -- I think..)

- "error" -channel uses MIMEoid message wrapping, and should consider
  seriously (let user to configure) what to "Cc:" to postmaster.
  Some say the Postmaster should not get error message's body..
  (Error channel appears partly inside(!)  the codes of  'router'
  (in the rfc822.c), and 'scheduler' (in the msgerror.c), and partly
  as an external program  transports/errormail/errormail.c)

  IETF has a NOTARY-wg whose charter is to standardize Delivery Status
  Notification reporting.   For a copy of specs drafts, see:
		doc/draft-ietf-notary-*
  On  940829  the system has IETF-NOTARY support on SMTP, MAILBOX, and
  ERRORMAIL channels.  Others (SM, HOLD?) will follow someday...

  Finetunings are needed on returned codes. ALPHA quality ?
  (router/rfc822.c DOES NOT (yet) follow IETF-NOTARY format!)

  NOTARY demands, that "Rcpt:" entry on the returned message MUST
  contain FQDN address.  Plain userid is not enough..  (BUG!)

  *** 9412: ERROR HANDLING NEEDS TO BE UPGRADED INTO THE NEW IETF DRAFTS ***


- Configuration files, esp.   cf/aliases.cf   has controversy in it.
  Many people think it is broken (I tend to agree) - 940614/mea

- Canned error messages are abysmal -- they need more complete ways to
  configure what is told and how, whole error facility needs an overhaul
  in fact..  (See mention above about: IETF NOTARY)

- Sometimes incoming SMTP can be a hellish load, need to introduce
  a load-limited incoming SMTP acceptor (smtpserver/smtpserver.c)
  (Rayan wrote it, but never released it..)
	13-Dec-94:  It exists for Linux ....
	23-Dec-94:  Pulled bits from "top" -program.  Now it
		    exists also for Suns..

  A discussion on the ZMailer -list revealed that the acceptance blocking
  is a BIG can of worms, and that even the  BSD-sendmail has had a long
  journey along the rocky path to "get it right"...  (5-Jan-95)

  Hmm.. Perhaps we could do a ``single process doing multi-stream reception ?''
  it would require fairly large rewrite of the SMTP-server..

- Alias processing by "newaliases" (printaliases: run_praliases)
  is "interesting" -- if sysadm wants to add an alias like:
	"Example Name": realname
  That just doesn't work..  (jeah, sure I want to use such aliases :)  )

- Processing of several headers is questionable/lack of:
	From: <>  -- should be valid! --- now is (940626/mea)
	Return-Path: <> -- as well ?
		
	Generic: header wrapping within N chars (like to 80-chars
		 space of BITNET) and also infinite wide systems,
		 like News.. (transports/libta/writeheaders.c ?)

	Generic: RFC-1342 aka. non-US-ASCII chars in the headers..
		 Auto-conversion and wrapping

- Zmailer script-language, ZMsh, could benefit from internal
  (simplified) version of  /bin/expr:
	a=$(/bin/expr "$home" : "\(/.*\)//*[^/]*/*") || return 99
  (Likely the new  ssift -construction can be used for this ?)

- On the zmailer@nic.funet.fi -list there has been also talk about
  a desire to replace the zmsh with some other language, like Scheme..
  I am not sure a lispish language is good one -- should postmasters
  be Lisp-Hackers to configure the ZMailer ?
