Re: 2.99.48+p1 compile

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

> I finally had a chance to give compiling zmailer under my
> SunOS 4.1.3_U1 system another whirl.  It seems to compile with the
> following two kludges in dnsgetrr.c:
> 
> At the beginning:
> 
> #define       HFIXEDSZ        12
> #define NETDB_SUCCESS   0
> #define NETDB_INTERNAL  -1

	Solaris 2.5(.0) did need the first of these three, the
	Solaris 2.5.1 has them all.

> and in the gethostbyname2_rz function:
> 
>         /*if (!strchr(name, '.') && (cp = __hostalias(name)))*/
>         if (!strchr(name, '.') )
>                 name = cp;

	Ok, I have to look deeper into the code.  Solaris 2.5.1 didn't
	complain about it, because it apparently has  bind 4.9.x resolver
	library with  __hostalias()  routine..

> Now my question is should I go ahead and install this (other than the
> standard risks associated with a pre-release version)?  Are these changes
> going to impact anything other than future "hooks" which are not
> currently used?

	These routines should not be affected with anything I will
	introduce latter.  And I am logging your notes for mergeing
	into my developement source.

	The use I have in mind:

	I will introduce an internal shared db-based DNS cache, which
	the scheduler, and the transport agents can use coherently.
	Also it will be able to retain (until timeout) the data, and
	not at all to query the DNS while it has valid data.

	Previously it was possible to run  smtp  with '-e' mode, alias
	'expensive' which selected all target addresses that can be
	delivered to same MX host.

	However the current 'thread grouping' gets the scheduler, and
	the transporters rather confused on what is going on, if the
	smtp runs on '-e' mode.

	Therefore I am looking for ways to get MX information back to
	the scheduler without compromising scheduler's  speed by
	querying DNS...

	Consider:
		*.inet.fi.	IN MX 10 mta.inet.fi.
				IN MX 20 smtp.inet.fi.
				IN MX 30 smtp.tele.fi.
	(Ok, '*' in the DNS is rather serious offence on sanity, but it
	 is a hack that the people can live with -- and are successfull!)

	Now all kinds of (mail-)domains don't need explicitely registered
	DNS entry can be routed to the mailbox service.

	Another example:
		foo.mail.somebody.com. IN MX 10 mailgw.somebody.com.
		bar.mail.somebody.com. IN MX 10 mailgw.somebody.com.
		bat.mail.somebody.com. IN MX 10 mailgw.somebody.com.

	Another example:
		foo.mail.somebody.com. IN A 1.2.3.4
		bar.mail.somebody.com. IN A 1.2.3.4
		bat.mail.somebody.com. IN A 1.2.3.4
	(yes, I have seen even this!)
	And propably I saw also this:
		*.mail.somebody.com. IN A 1.2.3.4
	(no MX, just wildcarded plain A..)

	In both cases the 'channel'+'host' selection that the scheduler
	uses at the moment causes it to run parallel smtp sessions that
	end up connecting to the same server.

	I don't like that type of parallellism, when this would work
	far better by sending all mail thru same (single) transport-agent.

	I even got a report from one of you that there are SMTP-servers
	out there that can do only ONE smtp-session at any time, and still
	they have several MXes pointing to them..


	Problem spins around of questions on how to get the MX info
	(trivial), how to modify the queues per that info (not trivial?)
	and how to run the smtp-ta-programs with that in most efficient
	manner (with least SMTP reconnects/least parallel runners with
	connections to same remote server.)

> Further can anything be done about this in the future for systems that do
> not use the libresolv that is distributed with zmailer?  And finally will
> these future hooks be compatable with the stock resolver stuff or will I
> have to go to another OS to run zmailer as a mailserver?  

	Yes, SPARC Linux is most viable alternate :)
	You can run (propably) all SunOS binaries, most Solaris binaries,
	and of course have native SparcLinux binaries :)

	Seriously, this kind of problems surface just because I don't
	anymore have SunOS 4.1.x available for development.
	(Same applies to any other OS that I don't test before release...)

> Thanks!
> 
> Daryle A. Tilroe ------------- Thin Film & System Admin ----- data@amc.ab.ca
> Alberta Microelectronic Centre ------------------------ http://www.amc.ab.ca

	/Matti Aarnio