Known/suspected bugs/Missing Features on current Zmailer sources

- transports/smtp/smtp:
	If it breaks the connection however neatly, it will do
	a connection re-open -- and after EHLO/HELO a QUIT.
	(harmless? but cosmetic bug..)

- Changes on 2.98/2.99 scrambled the list-expansion error-redirection
  mechanism.  Essentially the old  errors_to -variable got removed,
  but the new address attribute bound data is not yet online.

- Should use GNU Autoconfig to figure system facilities

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

- Usage of GDBM must be verified -- the interfaces have changed since
  router/libdb/gdbm.c was written, and the butchery on it in 9411xx was
  not done with GDBM documents at hand...

- Makefiles require a serious overhaul..
  ( -> GNU Autoconfig )

- Security expects "NOBODY" with value "-2", no other can be used!
  (Hmm..  It appears some others may work as well, why I didn't
   succeed with others ? /mea)
  Ok, perhaps I am scared to stiff about it, even USERNAME will do:
		nobody
  if your  /etc/passwd  has such..

  No, actually that is dependent of the system UID_T, when it is
  the classical  u_short, "-2" works, however SVR4 uses long, which
  means, it must be a positive number (60001 usually).


- Transporters should propably be able to down- AND upconvert
  headers (and bodies) when it comes to MIME-headers..
  For example it may be better to feed QP-decoded in 8-bit smtp
  to a server claiming it can receive 8BITMIME, even though it
  doesn't implement the thing in a truly kosher way..
  (One email->news gateway machine comes to mind..)
  This dual-translation applies to   smtp,  and  sm.  Just 8-bit
  decode applies to  mailbox, and errormail
    28-Oct-94: errormail does no decode QP, multipart processing is
	       still lacking some fine grains..
    Nov/Dec-94: There are a bunch of solutions starting from using
	        "-8" on the channels (except errormail..) to the
		use of header: "Content-Conversion: prohibited"

- MIME facilities are half-cooked (but work for the most of the time)

- "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..

- 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..

- 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

- Router could benefit from having several of its databases read
  in-core -- perhaps mmap()ed in..
  At least small (but plenty of used) databases, like "routes"
  would benefit a lot!  Every access thru them could be reduced
  to a fstat() call to verify that the original file has not changed..
	12-Dec-94:  now  ordered  and  unordered  databases can be
		    mapped into the memory via mmap() facility.
		    "ordered" does an in-core line index database
		    for itself, and uses it.

- Scheduler apparently can loose its mind -- if a hold-channel
  entry keeps failing (at first), and then succeeds, scheduler
  (at the moment) doesn't recognize the situation!
  Restart of the scheduler fixes that, but is not elegant..

  Propably this relates to the messages that scheduler gets from it
  children:
	smtpclient: Cannot open control file "local/174102" from "/var/spool/postoffice/scheduler" as uid 0! (m)

  THOSE are due to a mistaken deletion of the spool-file line which is
  in use on other channel/host...  Running "scheduler -s" does remedy
  it somewhat.

- 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 ?)

- ZMsh "sift"-structure matches at present on TOKENS, but on
  several cases it would be better, if it matched on STRINGS..
  Shall there be TWO  sifts ?  "ssift" for STRINGS, and "sift"
  for TOKENS ?
	13-Dec-94: Just pondering it...
	17-Dec-94: ssift/tfiss for STRINGS,  sift/tfis for TOKENS ???
	20-Dec-94: ssift/tfiss for STRINGS,  tsift+sift/tfis+tfist for TOKENS
