Sendmaail, resolv.conf, DNS

[Mike Spencer]

Not limited to Slackware but as a long-time Slackware user, this group
seems more like home to me...

Given sendmail 8.17.1 running as daemon:

/usr/sbin/sendmail -L sm-mta -bd -q25m
/usr/sbin/sendmail -L sm-msp-queue -Ac -q25m

is there a way to query the daemon to learn what nameserver(s) it is
using?

Why do I ask?

AFAICT, unlike some other programs which appear to query
/etc/rsolv.conf each time they use DNS, sendmail reads
/etc/resolv.conf when it starts and stores the IP addresses of
nameservers internally. If /etc/resolv.conf changes, that change is
not noted by sendmail. The result is a prolonged, fruitless attempt
to resolve a hostname from nameservers that will no longer respond to
the request from the then-current net-facing IP address of localhost.

Details

My usual setup is a desktop cabled to a router that is in turn cabled
to a gateway device using ISP "A".

The sendmail daemon's only task is to deliver outgoing mail to a
smarthost with TLS and AUTH.

At times, using wicd, I disconnect from the router and reconnect via
wi-fi, using a cell phone served by ISP "B" as an access point. Wicd
replaces /etc/resolv.conf with one that references the nameservers of
ISP "B". Apps such as a web browser and Usenet news proceed as
expected after the change but sendmail fails to deliver messages to
the remote smarthost.

Restarting sendmail fixes this.

It would be convenient to be able to query the sendmail daemon to see
what it was using as nameservers and avoid a restart if one isn't
needed.

I have the Bat Book but don't find an answer there.

A way to do this or enlightenment of ignorance on my part -- things I
don't know I don't know :-) -- welcome.

[Rich]

Post by Mike Spencer
The sendmail daemon's only task is to deliver outgoing mail to a
smarthost with TLS and AUTH.
At times, using wicd, I disconnect from the router and reconnect via
wi-fi, using a cell phone served by ISP "B" as an access point. Wicd
replaces /etc/resolv.conf with one that references the nameservers of
ISP "B". Apps such as a web browser and Usenet news proceed as
expected after the change but sendmail fails to deliver messages to
the remote smarthost.
Restarting sendmail fixes this.
It would be convenient to be able to query the sendmail daemon to see
what it was using as nameservers and avoid a restart if one isn't
needed.

Not sure that is possible. Sendmail (and mail servers in general) are
going to assume stable, static IP values, and so it is very doubtful
there is any official way to ask the daemon what nameservers it is
using. Reason being that in a static environment, there's no need to
ever bother doing so.

But, if the sendmail daemon's only task is to deliver outgoing mail to
a smarthost, what about configuring sendmail with the IP address of the
smart host? Then it won't need to do a DNS lookup to get the smart
host's IP, and changing resolv.conf won't matter to it. All that will
matter is that it can connect to that IP address via the current in use
network path.

[Mike Spencer]

Post by Rich

Post by Mike Spencer
It would be convenient to be able to query the sendmail daemon to see
what it was using as nameservers and avoid a restart if one isn't
needed.

Not sure that is possible. Sendmail (and mail servers in general) are
going to assume stable, static IP values, and so it is very doubtful
there is any official way to ask the daemon what nameservers it is
using. Reason being that in a static environment, there's no need to
ever bother doing so.
But, if the sendmail daemon's only task is to deliver outgoing mail to
a smarthost, what about configuring sendmail with the IP address of the
smart host? Then it won't need to do a DNS lookup to get the smart
host's IP, and changing resolv.conf won't matter to it. All that will
matter is that it can connect to that IP address via the current in use
network path.

That's a good idea. I'm using the mailertable mechanism which, AIUI, is
distinct from the smarthost one. But I could put the IP address in
the mailertable & authinfo files, rebuild the corresponding .db files
and see if the problem goes away. Don't have to mess with sendmail.cf.

My mail provider is a mom&pop ISP that seems to jockey IP addresses
around from time to time but I can stay alert to that.

Having an unwelcome episode of vertigo just now so I'm not going to
try typing config files through the fog. I'll get to it.

Tnx,

[Rich]

Post by Mike Spencer

Post by Rich

Post by Mike Spencer
It would be convenient to be able to query the sendmail daemon to see
what it was using as nameservers and avoid a restart if one isn't
needed.

Not sure that is possible. Sendmail (and mail servers in general) are
going to assume stable, static IP values, and so it is very doubtful
there is any official way to ask the daemon what nameservers it is
using. Reason being that in a static environment, there's no need to
ever bother doing so.
But, if the sendmail daemon's only task is to deliver outgoing mail to
a smarthost, what about configuring sendmail with the IP address of the
smart host? Then it won't need to do a DNS lookup to get the smart
host's IP, and changing resolv.conf won't matter to it. All that will
matter is that it can connect to that IP address via the current in use
network path.

That's a good idea. I'm using the mailertable mechanism which, AIUI, is
distinct from the smarthost one. But I could put the IP address in
the mailertable & authinfo files, rebuild the corresponding .db files
and see if the problem goes away. Don't have to mess with sendmail.cf.

Seems it is worth a try. It is likely your simplest item to try.

Post by Mike Spencer
My mail provider is a mom&pop ISP that seems to jockey IP addresses
around from time to time but I can stay alert to that.

Yeah, you'll have to manually follow their changes if you go this
route.

[Marco Moock]

Post by Mike Spencer
Not limited to Slackware but as a long-time Slackware user, this group
seems more like home to me...

Your question fits in comp.mail.sendmail.

IIRC for other operating systems a mechanism exists that automatically
reloads sendmail when the network changes (NetworkManager).
Maybe you can implement that in slackware too.

[Mike Spencer]

Post by Marco Moock

Post by Mike Spencer
Not limited to Slackware but as a long-time Slackware user, this group
seems more like home to me...

Your question fits in comp.mail.sendmail.

Yeah. Hacking sendmail is really above my pay grade. :-) I'll go
there if I get stuck.

Post by Marco Moock
IIRC for other operating systems a mechanism exists that automatically
reloads sendmail when the network changes (NetworkManager).
Maybe you can implement that in slackware too.

Hmm. I use wicd because NetworkManager demands a "tray" that isn't
supported by my favored window manager (twm). But wicd does seems to
do the right thing about swapping the resolv.conf files back and
forth. I'll have a closer look.

Tnx,

[Marco Moock]

Post by Mike Spencer
Hmm. I use wicd because NetworkManager demands a "tray" that isn't
supported by my favored window manager (twm).

wicd is old-ass and no longer developed.
Networkmanager can be used without a GUI and without nm-applet.
You can manage it via nmcli and nm-tui.
I run it on servery that way and this is default on RHEL/Fedora.

Post by Mike Spencer
But wicd does seems to do the right thing about swapping the
resolv.conf files back and forth. I'll have a closer look.

[Jim]

Post by Mike Spencer

Post by Marco Moock

Post by Mike Spencer
Not limited to Slackware but as a long-time Slackware user, this group
seems more like home to me...

Your question fits in comp.mail.sendmail.

Yeah. Hacking sendmail is really above my pay grade. :-) I'll go
there if I get stuck.

Post by Marco Moock
IIRC for other operating systems a mechanism exists that automatically
reloads sendmail when the network changes (NetworkManager).
Maybe you can implement that in slackware too.

Hmm. I use wicd because NetworkManager demands a "tray" that isn't
supported by my favored window manager (twm). But wicd does seems to
do the right thing about swapping the resolv.conf files back and
forth. I'll have a closer look.

I use stalonetray to get a "tray" with fvwm. Perhaps twm could use that
somehow?

Jim

[Jerry Peters]

Post by Jim

Post by Mike Spencer

Post by Marco Moock

Post by Mike Spencer
Not limited to Slackware but as a long-time Slackware user, this group
seems more like home to me...

Your question fits in comp.mail.sendmail.

Yeah. Hacking sendmail is really above my pay grade. :-) I'll go
there if I get stuck.

Post by Marco Moock
IIRC for other operating systems a mechanism exists that automatically
reloads sendmail when the network changes (NetworkManager).
Maybe you can implement that in slackware too.

Hmm. I use wicd because NetworkManager demands a "tray" that isn't
supported by my favored window manager (twm). But wicd does seems to
do the right thing about swapping the resolv.conf files back and
forth. I'll have a closer look.

I use stalonetray to get a "tray" with fvwm. Perhaps twm could use that
somehow?
Jim

There's also wmsystemtray, which I use with fvwm.

Jerry

[Lew Pitcher]

Post by Mike Spencer
Not limited to Slackware but as a long-time Slackware user, this group
seems more like home to me...
/usr/sbin/sendmail -L sm-mta -bd -q25m
/usr/sbin/sendmail -L sm-msp-queue -Ac -q25m
is there a way to query the daemon to learn what nameserver(s) it is
using?

[snip]

Post by Mike Spencer
My usual setup is a desktop cabled to a router that is in turn cabled
to a gateway device using ISP "A".
The sendmail daemon's only task is to deliver outgoing mail to a
smarthost with TLS and AUTH.
At times, using wicd, I disconnect from the router and reconnect via
wi-fi, using a cell phone served by ISP "B" as an access point. Wicd
replaces /etc/resolv.conf with one that references the nameservers of
ISP "B". Apps such as a web browser and Usenet news proceed as
expected after the change but sendmail fails to deliver messages to
the remote smarthost.
Restarting sendmail fixes this.

[snip]

I think that you are trying to solve the wrong problem. The problem isn't
that sendmail caches the address of the DNS server, but that you are
using a DNS server who's address may change over time.

You could just run a caching nameserver on your slackware box, and
resolve /all/ DNS queries against that server. This way, the DNS
server maintains a fixed address (perhaps, "localhost", in your case)
and sendmail doesn't have to fish about for DNS resolution.

A caching DNS server adds very little to the system overhead, and,
beyond the initial setup, needs little or no maintenance. It gives
the added benefit of adding a bit more security to your DNS queries,
in that your ISP /does not/ handle the queries, /can't/ log or track
them, and /can't/ substitute their own sponsored/edited/redirected
answers.

[Mike Spencer]

Post by Lew Pitcher

Post by Mike Spencer
At times, using wicd, I disconnect from the router and reconnect via
wi-fi, using a cell phone served by ISP "B" as an access point. Wicd
replaces /etc/resolv.conf with one that references the nameservers of
ISP "B". Apps such as a web browser and Usenet news proceed as
expected after the change but sendmail fails to deliver messages to
the remote smarthost.
Restarting sendmail fixes this.

[snip]
I think that you are trying to solve the wrong problem. The problem isn't
that sendmail caches the address of the DNS server, but that you are
using a DNS server who's address may change over time.
You could just run a caching nameserver on your slackware box, and
resolve /all/ DNS queries against that server. This way, the DNS
server maintains a fixed address (perhaps, "localhost", in your case)
and sendmail doesn't have to fish about for DNS resolution.

I never thought of that. The caching nameserver would have to be able
to go to the right remote nameserver to update itself but that might
be handled correctly. One more thing to maintain kinda contravenes my
preference for KISS but I'll have a look at that.

Post by Lew Pitcher
A caching DNS server adds very little to the system overhead, and,
beyond the initial setup, needs little or no maintenance. It gives
the added benefit of adding a bit more security to your DNS queries,
in that your ISP /does not/ handle the queries, /can't/ log or track
them, and /can't/ substitute their own sponsored/edited/redirected
answers.

A potential problem, yeah. IIRC, I've only seen it happen twice, once
using somebody's wi-fi where their router did DNS weirdly. I forget
the details of the other case but it became publicly known and went
away after public protest.

Tnx,

[Lew Pitcher]

Post by Mike Spencer

Post by Lew Pitcher

Post by Mike Spencer
At times, using wicd, I disconnect from the router and reconnect via
wi-fi, using a cell phone served by ISP "B" as an access point. Wicd
replaces /etc/resolv.conf with one that references the nameservers of
ISP "B". Apps such as a web browser and Usenet news proceed as
expected after the change but sendmail fails to deliver messages to
the remote smarthost.
Restarting sendmail fixes this.

[snip]
I think that you are trying to solve the wrong problem. The problem isn't
that sendmail caches the address of the DNS server, but that you are
using a DNS server who's address may change over time.
You could just run a caching nameserver on your slackware box, and
resolve /all/ DNS queries against that server. This way, the DNS
server maintains a fixed address (perhaps, "localhost", in your case)
and sendmail doesn't have to fish about for DNS resolution.

I never thought of that. The caching nameserver would have to be able
to go to the right remote nameserver to update itself but that might
be handled correctly.

Unless you configure it incorrectly, a caching nameserver "climbs the
tree" of domains for you, starting at the root servers, and working
its way up from the TLD to the full hostname. It definitely /would/
"go to the right remote nameserver" for any hostname available to
a public DNS query.

Post by Mike Spencer
One more thing to maintain kinda contravenes my preference for
KISS but I'll have a look at that.

I guess that it depends on your definition of "simple". If "simple"
means finding some random hack to sendmail to make it stop caching
DNS query results, then, I guess, a sendmail hack satisfies your
KISS principle.

But, if the addition of a single, standard, low maintenance process
to your current configuration is simpler than a sendmail hack, then
a caching nameserver is the ticket.

I've run one for years, with no maintenance issues at all.

But, that's me. :-)

Post by Mike Spencer

Post by Lew Pitcher
A caching DNS server adds very little to the system overhead, and,
beyond the initial setup, needs little or no maintenance. It gives
the added benefit of adding a bit more security to your DNS queries,
in that your ISP /does not/ handle the queries, /can't/ log or track
them, and /can't/ substitute their own sponsored/edited/redirected
answers.

A potential problem, yeah. IIRC, I've only seen it happen twice, once
using somebody's wi-fi where their router did DNS weirdly. I forget
the details of the other case but it became publicly known and went
away after public protest.

My GF has cable internet, and her ISP sometimes "redirects" her away
from the websites she asks for to sites that the ISP deems more
"suitable", using altered DNS reply values. But, then again, that ISP
also "injects" its own (sometimes sponsored) HTML into web pages she
views. She (thinks that she) has no choice but to tolerate this
corporate antisocial behaviour. :-(

Luck be with you.

[Rich]

Post by Mike Spencer

Post by Lew Pitcher
You could just run a caching nameserver on your slackware box, and
resolve /all/ DNS queries against that server. This way, the DNS
server maintains a fixed address (perhaps, "localhost", in your case)
and sendmail doesn't have to fish about for DNS resolution.

I never thought of that. The caching nameserver would have to be able
to go to the right remote nameserver to update itself but that might
be handled correctly. One more thing to maintain kinda contravenes my
preference for KISS but I'll have a look at that.

Slack 15 ships with bind config files suitable for running a caching
nameserver yourself. You likely only need to turn on /etc/rc.d/rc.bind
(make it executable) to gain a local caching nameserver on the next
boot.

If you don't want to reboot just to get named started, then just make
rc.bind executable and then launch it as "rc.bind start" while you are
root.

[Mike Spencer]

Post by Rich
Slack 15 ships with bind config files suitable for running a caching
nameserver yourself. You likely only need to turn on /etc/rc.d/rc.bind
(make it executable) to gain a local caching nameserver on the next
boot.
If you don't want to reboot just to get named started, then just make
rc.bind executable and then launch it as "rc.bind start" while you are
root.

Interesting. More stuff I didn't know. When I get past the very
annoying episode of persistent vertigo, I'll have a look at that.

Tnx,