ml>>>>>> field... my mailer doesn't pull connect info from the
 ml>>>>>> location field or the system name field because those
 ml>>         ^^^^^^^^^^^^^^        ^^^^^^^^^^^^^^^^^
 ml>>>>>> fields do not contain connection info... ;)

 DD>>>>> so... the whole world must bend just to accommodate your
 DD>>>>> kludged mailer?

 ml>>>> nope... instead the "whole world" must bend
to a kludged nodelist and
 ml>>>> kludged software to retrieve information that is in
places where it
 ml>>>> shouldn't be...

 DD>>> You think nodelist flags are a kludge?

 ml>> that is not what i said... the points i was going after are still quoted
 ml>> in my original statement above... they are now pointed to, too...

 DD> Maybe you could just use the utility provided to move the
 DD> contact info to a field that you kludged mailer can
 DD> locate.....

"the utility provided"?? there's no such utility provided with my
mailer or any other software that i currently run... perhaps you are
speaking of the utility that mvdv wrote? if so, it still breaks my setup in
that i loose some connectivity with (other) dualy connected nodes...

in other words, i prefer to have both capabilities available if possible
where IP is the preferred method and POTS the secondary... this _only_ due
to cost considerations...

to clarify, my setup uses two control files for those systems that are
"overridden" for IP capabilities... one control file is for their
possible POTS capabilities and contains their POTS number or a go nowhere
number (ie: 800-555-0100) if they have no POTS capabilities... (i've not
tested trying to put "-Unpublished-" into an override to see how
that works...)

the other control file contains their IP info if they have telnet connectivity...

these two control files are processed by the system and the data is stored
in environment variables based on the capabilities of my nodes (ie: my POTS
nodes use the POTS control file and my IP nodes use the IP control file)...

currently IBN (binkp) connections are manually processed and added to my
binkp setup only if i need to contact a binkp-only system via direct
means... otherwise, my systems route mail to them via my normal routing
channels...

so, all in all, for mvdv's utility to work in my case, it would need to do
a tad bit more than it currently does... FWIW: i would welcome his utility
for those systems are are strictly ITN capable... but i've not enough info
at this time (or from the past) to determine if it would also effect dualy
connected ITN systems and i've had no time for any testing to see for
myself :(

i'd love to see a util that would, in one run, create the files that my
system currently needs to operate as it currently does... unfortunately,
i've very little time to actually develop this util even though i have
spent some time creating "flow charts" and psuedo code (sorry,
this info is in "kittyese" and not available to those that do not
speak "kittyese")... however, some translation *may* be available
if desired...

)\/(ark