Re: Hm... .forward-related problem in s4

[<mea@nic.funet.fi>]

> This is not a bug report.  It's an anecdote.
> 
> I don't really know what happened.  Here I was, happily switching from
> a 49p9 with a few hacks of my own to 50s4, when suddenly this message
> caused the router to segfault and I couldn't make head or tail of it.
> 
> It turned out that the router died if local user "sharon" was
> forwarded to an off-site address using .forward, but everything worked
> smoothly when I added her to the aliases file.

	That is a bug in  lappend  function, I found out about it
	myself yesterday.  It doesn't do proper work at adding to
	the end of empty list:
		al=()
		lappend al $newvalue

	Of course I had tested it only with pre-filled list:
		al=(a b)
		lappend al (c d)
		grind $al

	I will do today a Snap5 where these (and a few other things)
	have been fixed.  At the end you can find diff in between my
	current ChangeLog, and that of Snap4.

> Unfortunately, I don't have a debugger that can manage the router in
> -d mode, so I didn't see -where- the router segfaulted.

	You mean "-g" mode ?

> However, if anyone else runs into the sudden death problems, have a
> look at .forward, and try to figure out what happens.
> 
> Btw, I noticed some oddnesses while I was looking at this.
> 
> During startup, router did:
> 
> stat("/var/spool/mail/agulbra", {st_mode=S_IFREG|0600, st_size=2460, ...}) = 0
> 
> Why?

	ZMSH is a shell, and it also looks for environment
	variable MAIL to tell you that you do have new email...  :-)
	(Not that router has much use for it, though..)

> access("./exec", X_OK)                  = -1 ENOENT (No such file or directory)
> access("/local/zmailer/cf/exec", X_OK)  = -1 ENOENT (No such file or directory)
> access("/local/zmailer/bin/bin/exec", X_OK) = -1 ENOENT (No such file or directory)
> 
> What's this?  looking for exec as a file, and in bin/bin?

	Hmm...  In 'standard.cf' there are a few invocations of
	'exec' with various I/O redirection parameters.
	Their desired effect seems to happen, though..

	It is using PATH (ZMailer's zmsh shell's PATH, that is)
	to find out where the command to be executed can be found.

	I guess it should be added into libsh/builtins.c for
	"proper" functionality.

> The router also read some new(?) files in db, otherservers,
> msgidfilter.zmsh and localnames.zmsh, that look interesting.  I
> suppose it's time to read that latex.

	Sorry, not explained there.  See  'standard.cf'  script.
	Those are different ways to load in configuration data.

	The *.zmsh variants are scripts produced by running
	script  utils/make-incore.sh  on the source database.
	It is usefull stuff for things that don't need change;
	or at which change you can restart the router.
	The 'incore' databases are fast to use, but are not good
	for LARGE databases, or in case you want to be able to
	modify DB contents frequently.

> --Arnt

/Matti Aarnio <mea@nic.funet.fi>


diff -u -r zmailer-2-99.50-s4/ChangeLog zmailer-2-cvs/ChangeLog
--- zmailer-2-99.50-s4/ChangeLog	Mon May 25 11:51:49 1998
+++ zmailer-2-cvs/ChangeLog	Tue Jun  2 02:10:08 1998
@@ -1,3 +1,64 @@
+1998-06-02  Matti Aarnio  <mea@mea.tmt.tele.fi>
+
+	* router/rfc822.c:
+	    More gymnastics on getting the possibly missing "From: "
+	    header generated in all possible situations.
+
+1998-06-01  Matti Aarnio  <mea@mea.tmt.tele.fi>
+
+	* proto/newaliases.in, proto/newdb.in, proto/cf/i-routes.cf,
+	  proto/cf/standard.cf, proto/newfqdnaliases.in:
+	    Synced 'newdb' usages to supply explicite '-l' option,
+	    Modified scripts to require /bin/sh, not MAILBIN/router !
+
+	* router/rfc822.c:
+	    If the message had no 'From: ' header, generate one for it.
+
+	* proto/cf/standard.cf:
+	    Add "bitnet" and "uucp" into the default toplevels list.
+
+	* proto/cf/rrouter.cf, proto/cf/i-bitnet.cf:
+	    Updated BITNET routing rules;  nic.funet.fi  is Finland's
+	    *only* BITNET host these days, and works as BITNET-bound
+	    email gateway.
+
+	* libsh/builtins.c, proto/cf/aliases.cf, proto/cf/aliases-new.cf:
+	    Whoops, two mistakes in  aliases.cf -- wrong name at
+	    lappend parameter, and lappend internal functionality
+	    at empty target variable content was faulty (SIGSEGV..)
+
+	* configure.in, libc/setregid.c, libc/Makefile.in,
+	  transports/mailbox/mailbox.c:
+	    Within mailbox.c there is one instance of fork(), and
+	    following it are some setgid()/setuid() statements.
+	    Setting real-uid/real-gid is not sufficient for systems
+	    with NFS-mounted home directories...
+
+	    Changed those calls to be  setregid() and setreuid(),
+	    which should work far better, but I have no idea about
+	    its portability to for example  SunOS 4.1.*  series.
+	
+	* proto/Makefile.in, proto/cf/SMTP.cf.in, configure.in:
+	    Default router.cf is altered to have protocols 'routes',
+	    and 'smtp'.  Per default the system install will not
+	    have UUCP in routing stage anymore.
+
+	* smtpserver/smtpdata.c:
+	    Oops: At DATA processing the content-policy was tested
+	    only if the last RCPT policy analysis yielded All-OK (0)
+	    status.
+
+1998-05-26  Matti Aarnio  <mea@mea.tmt.tele.fi>
+
+	* proto/newdb.in:
+	    The script is in fact pure /bin/sh script, don't ask for
+	    running the router on it.
+
+	* proto/cf/aliases.cf, proto/cf/consist.cf, proto/cf/crossbar.cf,
+	  proto/cf/aliases-new.cf:
+	    Replaced all uses of 'setf' with  'lappend' and 'lreplace',
+	    where appropriate.
+