Bug 451575

With the old network scripts sendmail is working if you are connected over a ppp
line where resolv.conf gets changed. Therefore this is not a sendmail problem.

Assigning to NetworkManager.

It turned out that nscd hadn't started (or had crashed?). Restarting that one
fixed things. Should this be thrown at the glibc maintainer?

Sorry, wrong alarm. A few mails seemed to make it through, but I had to restart
sendmail anyway.

Now on x86_64, same thing

sendmail-8.14.3-1.fc10.x86_64
glibc-2.8.90-9.x86_64
glibc-2.8.90-9.i686
NetworkManager-0.7.0-0.11.svn3846.fc10.x86_64

is this still an issue with latest rawhide NetworkManager?

Yep, checked yesterday (rawhide up to date).

Horst, is nscd enabled on your machine?  What do you get for '/sbin/chkconfig --list | grep nscd'?  And if it is running when DNS changes, does doing '/usr/sbin/nscd -i hosts' as root work for you?

I'm also thinking that NM should do a "nscd -i hosts" when DNS changes (or perhaps nscd should monitor /etc/resolv.conf and automatically flush when it changes?).  Problem I'm seeing here is laptops moving from home to/from work and accessing the wrong (public vs. private) IP address for services.  Thunderbird seems particularly affected.

NetworkManager-0.7.0-0.11.svn4229.fc10.x86_64, freshly booted. Still the same problem.

# /sbin/chkconfig --list | grep nscd
nscd           	0:off	1:off	2:off	3:off	4:off	5:off	6:off

Moving off of preview target, not a preview blocker.

Horst, nscd needs to run if you want things to notice network config changes.  Try booting with the service enabled and see if it resolves your issue.

(In reply to comment #8)
> I'm also thinking that NM should do a "nscd -i hosts" when DNS changes (or
> perhaps nscd should monitor /etc/resolv.conf and automatically flush when it
> changes?).  Problem I'm seeing here is laptops moving from home to/from work
> and accessing the wrong (public vs. private) IP address for services. 
> Thunderbird seems particularly affected.

NM does both 'nscd -i hosts' and a condrestart of nscd when DNS information changes.

I think the problem is that sendmail uses res_querydomain() to resolve names and does not check to see if /etc/resolv.conf has changed.  sendmail is started before a working /etc/resolv.conf is in place and seems to be stuck with that information.  So, either:

1) sendmail should monitor resolv.conf and call res_init() if needed, or simply call res_init() before querying names (this is what fetchmail does).

2) NM should condrestart sendmail.

3) sendmail should use something other than res_querydomain() (is that possible since it looks for AAAA, A, then MX records?)

I'm thinking #1,  though I may have to do #2 with a dispatch script as a workaround.

Here's an strace snippet of the sendmail daemon processing an incoming mail:

2442  write(1, "dns_getcanonname: trying test.cor"..., 52) = 52
2442  socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
2442  connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("0.0.0.0")}, 28) = 0

Note how it tries to connect to a dns server at 0.0.0.0.

See also: http://sources.redhat.com/bugzilla/show_bug.cgi?id=3675 for the glibc perspective.

This feels like something we'll want to fix post-F10, as it would be a somewhat interesting change to sendmail.  I'm dropping it off the list.  I think for sendmail users, they can just set the setting in /etc/sysconfig/network to wait for NM to fully bring up the device before continuing on with startup scripts.

Given comment 12, it's more of a sendmail package problem.  NM can't contain scripts to restart every service under the sun, thus the sendmail package would have to have one.  Or it grows the ability to requery /etc/resolv.conf...  -> sendmail

(In reply to comment #13)
> This feels like something we'll want to fix post-F10, as it would be a somewhat
> interesting change to sendmail.  I'm dropping it off the list.  I think for
> sendmail users, they can just set the setting in /etc/sysconfig/network to wait
> for NM to fully bring up the device before continuing on with startup scripts.

This doesn't help if you have sendmail running so you can send off (really queue) mail even when there is no network.

(In reply to comment #15)
> This doesn't help if you have sendmail running so you can send off (really
> queue) mail even when there is no network.

I have to say, I'm getting much more reliable delivery of system messages from our laptops now that I'm restarting sendmail in my NM dispatcher script and the queue is processed as soon as the network is up.  But again, the proper fix is in sendmail calling res_init().

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fixing version to align with rawhide again.  Sorry for the noise.

*** Bug 460122 has been marked as a duplicate of this bug. ***

A NM dispatcher script added in sendmail-8.14.3-2.fc11.

sendmail-8.14.3-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/sendmail-8.14.3-2.fc10

sendmail-8.14.3-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/sendmail-8.14.3-3.fc10

*** Bug 477548 has been marked as a duplicate of this bug. ***

It seems #20 fixed this for me (rawhide x86_64). Should it be closed? Backport fix to Fedora 9 and 10?

Hi folks, I come from ticket #477548 (same problem). Is it possible
that somebody corrects the typo in the summary, so that other people
have a chance to find this ticket when they search for "sendmail"
(and not "sedndmail" ;-)

Fixed.

Sorry, my typo.

*** Bug 479107 has been marked as a duplicate of this bug. ***

sendmail-8.14.3-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

we had the problem on Fedora 11:
- 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
- NetworkManager-0.7.1-4.git20090414.fc11.x86_64
- sendmail-8.14.3-5.fc11.x86_64

system logfiles said this almost all the time:
reject=451 4.1.8 Domain of sender address example does not resolve

- we solved this issue by disabling NetworkManager init process ( chkconfig  NetworkManager off ) and using the standard network config files ( /etc/sysconfig/network-scripts/ifcfg* )

if this is already known, sorry for reporting, we wont do again :)