[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a Z-mailer question

> On Fri, 20 Mar 1998, Roy C Bixler wrote:
> > Yes, but the machine I installed the latest snapshot on was not
> > 'press-gopher', so it still seems to me that the $orgdomain suffix
> > business stopped working somewhere after 2.99.49p9.
> OK, I found that if I change the bit of code below, my earlier problem
> disappears:

	Ah, my skull is thick... but given enough time something may
	diffuse thru.

	Your fix is suboptimal -- it halts the system rather well
	for doing DNS lookups all the time.  (I am thinking on what
	it would affect nic.funet.fi which acts as fanout server for
	vger.rutgers.edu, and thus gets a lot of non-local domains..)

	I rewrote the canonical() to be:

canonical (host) {
	local tmp
#  Now a big question:
#	Do you want to put your system to hold for the DNS lookups at
#	the router, or will you let the SMTP transport agents to handle
#	such things in much more parallel fashion as they can under the
#	scheduler.  If you want to do the holding, use $(canon ..) version.
#	If you don't do $(canon ..), this MTA will not rewrite remote
#	hostname CNAME mappings.  (Which IMO isn't all that bad [mea])

	tmp="$(deliver "$host")" && return "$tmp"

	# Not locally known, is it multi-component domain with
	# known toplevel ?   If not, lets do $(canon ..) anyway!
	tsift "$host" in
		[ $(istoplevel "\1") ] && return "$host"
	tmp="$(canon "$host")" && return "$tmp"

	return "$host"

> So is the behaviour I described earlier ('press-gopher' is not recognised
> as being the same as 'press-gopher.uchicago.edu' from another machine with
> latest Z-mailer snapshot in the same domain - in fact, the delivery to
> 'press-gopher' fails while 'press-gopher.uchicago.edu' succeeds) an
> intentional side-effect of using the new default code? 

	This rewritten version behaves as expected, and will optimize
	things a bit by skipping canonicalization of those domains which
	have known top-level field.

	Although, specifications tell us that given a CNAME domain, we
	should rewrite that domain to the value of CNAME -- but that
	needs DNS lookups at the router, and means serious slowdown..
	(.. ergo, I have chosen to ignore that rule..)

> ---
> Roy Bixler
> The University of Chicago Press
> rcb@press-gopher.uchicago.edu

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