Re: router -i

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

> > BTW, from my (much older) ZMailer:
> > 
> > 61 relay:/zmailer/db>router -i
> > ZMailer router (2.99.10mea       #1: Fri Jan 20 11:04:46 MST 1995)
> >   PostMaster@Phys.UAlberta.CA:/ZMdev/zmailer-2.99.10
> > Copyright 1992 Rayan S. Zachariassen
> > Copyright 1992,1993,1994 Matti Aarnio
> > 
> > z$ router davidn@sdev.blaze.net.au
> > <jmack.interactive@relay.Phys.UAlberta.CA>: address: davidn@sdev.blaze.net.au
> > (((smtp sdev.blaze.net.au davidn@sdev.blaze.net.au default_attributes)))
> > 
> > so it's not unique to the newer ZMail version.
> 
> I was *sure* this used to work as I had expected it to. Someone else
> mentioned in email that it has always worked as above also. My
> recollection is obviously faulty.

	If    sdev   had been a CNAME, then it would have been rewritten,
	not othervice.

> > Perhaps there is just some discrepency between the db's on your
> > nameservers.
> 
> Nup, they're all working ok, and as I mentioned, delivery works ok
> as well although resolution of the MX apparently occurs in the scheduler 
> (if the mail -v output is anything to go by). I actually tested this on
> the same physical machine on which the nameserver runs which is free of
> any other specific routings for the machines involved.

	The USE of MX resolved data occurs at smtp channel program,
	not before. (Like I mentioned in my first reply)

> Oh well, perhaps I'm just imagining things that it used to show the true
> target. Could also be that my much hacked .cf files I ran previously (most
> of the bugs in which have since been fixed bar one (that is, attempting to
> send to the current machine via name@[x.x.x.x] still does not work without
> applying a correction to rrouter.cf).

	In theory, the change is rather simple -- we must add recognition
	of local bracketed address into that place, however practical test
	a moment ago at my Linux machine gave rather mystic results :-(

	... Oh yes, I forgot the expansion cache flushing (duplicate remover)
	code I tested on that machine.

z# router "fii@[130.232.1.11]"
<mea.interactive@mea.utu.fi>: address: fii@[130.232.1.11]
(((local fii@[130.232.1.11] fii default_attributes)))
z# router "foo@[130.232.1.1]"
<mea.interactive@mea.utu.fi>: address: foo@[130.232.1.1]
(((smtp [130.232.1.1] foo@polaris.cc.utu.fi default_attributes)))

	That latter form is illegal in local system -- polaris does
	not have mailer at all, and this form does not use MXes to
	find the right host..  (mailhost.utu.fi)

-------------  $MAILSHARE/cf/rrouter.cf --------------
.....
	(.*)<@\[(.)\]>(.*)
		# numeric internet spec
		if [ $(deliver "[\2]") ]; then
			address="\1<@>\3"
		else
			return (((smtp "[\2]" "\1@$(gethostbyaddr \2)\3" $A)))
		fi
		;;
.....
------------------------------------------------------

	This requires (of course) that you add your host numeric address(es)
	in brackets to  $MAILSHARE/db/localnames -database:

	.....
		[130.232.1.11]	mea.cc.utu.fi
	.....


	This becomes rather lengthy, when the machine has multiple (virtual)
	addresses..  (like nic.funet.fi has 8 or so..)

>   And that's also the reason I
> installed with a completely fresh set. That and the occasional corruption
> of the domain portion of some addresses which now seems to be completely
> cured. (actually, I think this latter problem was due to a misconfiguration;
> we're running Linux 1.2.13 on the ISP box, and the default Linux hostenv
> configuration includes mmap() by default. This works fine in later 1.3.x
> kernels, but not 1.2.x).

	True, I should add big banners on some things of this type
	to Linux configuration package -- I use the bleeding edge
	kernels, compilers, and libraries, and don't always remember
	that others might be more conservative..

> FWIW, I just did some testing later with sendmail 8.6.12, and it does show
> the correct MX target. Perhaps that's what I'm remembering.

	sendmail is monolithic, and there seeing the difference of
	routeing phase, and delivery phase is a bit difficult..

> Regards,

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