Known/suspected bugs/Missing Features on current Zmailer sources

- IPv6 stuff:
	- lib/selfaddrs.c: don't handle automatic IPv4/IPv6 address storage
			   for all interfaces (and subsequent comparison);
			   PERHAPS does not handle storage/indexing properly ?
	- libc/myhostname.c: don't do automatic IPv6
	- scheduler/mailq.c: don't do IPv6 connect
	- transports/hold/hold.c: incomplete NS/AAAA, no IPv6 PTR
	- transports/smtp/smtp.c: don't do IPv6 connects ?
			(Will do donnect to:  foo@[ipv6.::ffff::12.34.56.78])
	- transports/mailbox/mailbox.c: BIFF gethostbyname() ?
	- router/XXX:  need to add a builtin function to detect local
			IP addresses while processing IP-address literals.

- Autoconfig problems:
	- DNS library requirements are difficult to detect right for
	  the all cases
	- System mailbox locking schemes are sometimes non-obvious..
	- For the last PERHAPS must introduce back the host-configuring
	  by describing host-dependencies like mailbox-lock schemes

- Scheduler eats way too much memory, when some huge lists
  flow thru it -- all recipient channels/hosts PLUS the whole
  transport specifications file.  With TA's doing statistics
  logging, the scheduler should not need to keep those copies
  of the file's full TA-spec files in scheduler's core.
	4-Feb-97: Now it won't...  It is up to the transport-agents to
				   do the verbose logging on a file

- Got mail with a suggestion: (via zmailer-list)

 I suggest you to improve the 'crossbar' function of 'router'.
 It might return a list of header rewrite functions as well
 as a single function like now. So different rewrite methods
 could be applied for sender and recipient addresses.
 The crossbar() C function contains some comment that refers
 to some similar thing, but I found it unimplemented.
         /*    
          * We expect to see something like
          * (rewrite (fc fh fu) (tc th tu)) or
          * ((address-rewrite header-rewrite) (fc fh fu) (tc th tu))
          * back from the crossbar function.
          */

- Reports heard of router locking failing to acquire individualy
  a target file, and thus resulting multiple routing/delivering of
  the same message.
    (this shouldn't happen...)
  Solaris  rename() is behaving in "interesting" manner!  Occasionally
  it can fail by creating doubly named file...

- When killing previous routers/scheduler/smtpserver, should wait
  the previous process group leader to die before writing over
  the  $POSTOFFICE/.pid.KIND -file.

- Co-ordinated shutdown for the scheduler -- send a signal to it
  (SIGQUIT), and it sends out newlines to all processes still
  receiving anything from the scheduler, and shuts the feed channels
  down from the scheduler to the transporters.  Then it will spend
  some time (infinity?) to get responces from the transporters.
  When all childs are dead, it can exit.
	20-Jan-97: Sort of facility exists now..

- DSN (Delivery Status Notification) mechanism does not (yet) report
  on "SUCCESS" or "DELAY", only noticing "NEVER", and reacting as if
  "FAILURE" is always given...
	7-Nov-96:  All except DELAY should now work

- BUG! mailbox has a file creation failure window:
        - mailbox1 tests to see if the mailbox exists, and it does not
        - mailbox2 tests to see if the mailbox exists, and it does not
        - mailbox1 tries to do exclusive file creation (and succeeds)
        - mailbox2 tries to do exclusive file creation (and fails)
  Time in between test, and creation is milliseconds, but if system
  process scheduling hits in between, both believe to be acting in void.
  This can propably be triggered by NOT having the target file in existence,
  and sending a message with two addresses, one straight to the recipient
  mailbox, and another via some alias.  System starts TWO mailbox programs
  to feed the messages.  Try it enough times, and it will occur.
	(18 Aug 1996 -- Fixed ? By allowing 'EEXIST' return from file
	 creation, and understanding it as a result from a race above.))

- Want to have more interactivity at the scheduler status and control
  mechanisms.  Especially thinking a new two-way system where there
  can be multiple manager interfaces acting at the scheduler ``mailq''
  port issueing commands (queries), and receiving responces.
  With authentication, could do queue purges, rerouteing commands, etc.

- Need to add the  sdbm ( support/sdbm/ )  in NDBM compability mode to
  the system in case the system does not have  <ndbm.h>  in it, nor
  libdbm.a -- low priotity..

- autoconfig detection of DBMs is partial;
	- dbm (that OLD one!) does not work (SunOS 4.1)
	- sdbm -- never tested

- Add LDAP databases to router!
	(sendmail-8.8.x has/will get LDAP)

- 'channel error' detection is partial at places;
	transporters: hold, errormail

- 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
	 same C-code without calling the scripts...)

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

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

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

  Also: What to do when there are more incoming SMTP sessions than the
  process can have open file descriptors ?  Two for each way of SMTP (for
  stdio library!) channel, one for each spool file in active use at the
  input phase, and one for log. (The stdio is used only for SMTP responses,
  and for spooling out the accumulated message.  Thus there SHOULD be enough
  resources for all uses -- except when the system runs out of FDs per any
  individual process..)

- 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 :)  )
	29-1-97: Now it works :) (2.99.46b)

- Processing of several headers is questionable/lack of:
	From: <>  -- should be valid! --- now is (940626/mea)
	Return-Path: <> -- ANYTHING ACCEPTED -- header removed! (961114/mea)
		
	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 ?
