[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2.99.48+p1 compile
> 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
*.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.
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.
foo.mail.somebody.com. IN A 184.108.40.206
bar.mail.somebody.com. IN A 220.127.116.11
bat.mail.somebody.com. IN A 18.104.22.168
(yes, I have seen even this!)
And propably I saw also this:
*.mail.somebody.com. IN A 22.214.171.124
(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...)
> Daryle A. Tilroe ------------- Thin Film & System Admin ----- firstname.lastname@example.org
> Alberta Microelectronic Centre ------------------------ http://www.amc.ab.ca