Re: A bunch of problems with zmailer

[Matti Aarnio <mea@nic.funet.fi>]

> Swen Thuemmler <swen@uni-paderborn.de>
> > Well, I would appreciate even little improvement. Maildelivery is
> > centralized on one host in our departement, so the mentioned problems
> > might not occur for us. Could you give me hints, how to do it?
> 
> Grep for 'db flush expansions' in cf/*.cf, read the comments around
> them, and do it.  Now, here's a problem.  I saw, now and then, illegal
> spool files, probably connected to the duplicate elimination.

	One of the "problems" at the duplicate elimination is that
	the quad of the recipient address is taken as is, and if
	it is as:
		(local list1 recipient g7)
		(local list2 recipient g7)
	now picking those as a key will yield epansion db keys:
		"locallist1recipientg7"
		"locallist2recipientg7"
	which are not the same...

	Furthermore, when the message is delivered, each has (most
	likely) different senders, for example:
			list1-owner
			list2-owner
	and thus they must be written with separate delivery addresses..
	(With the usual sendmail aliasing via forking of separate
	 sub-sendmail to handle the list, and giving it the  -f -option
	 does not eliminate the duplicates in this manner either.)

	You can look into the comments at the aliases.cf: routeuser()
	----------------------------------------------------------------
	# get rid of the attribute tag for alias loop prevention
	a=$quad
	mxh=$(setf $(last $a) ())
	key="$(elements $a)"
	#key="$(channel $a)$(user $a)$(attributes $a)"
	didexpand=$(expansions "$key")
	----------------------------------------------------------------
	now choosing that alternate "key" definition might eliminate
	some of your duplicates...

> These files had two recipient addresses in them, one valid, one empty,
> which would cause the scheduler to dump core on startup.  I'm not in
> the habit of restarting zmailer, so I didn't notice.  When I finally
> realized that there might be a connection between the two, I didn't
> use that elimination any more.
> 
> I believe I sent Matti a message about this some time ago.

	Yes you did.  Now the scheduler does not crash on them.
	(But they should not be generated either.. a bug at the router)

> --Arnt

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