[I posted a similar question a couple of months back, but mistakenly thought I had resolved the issue]
One of my F40 systems fails to deliver local, system-generated e-mails (logfiles and such) UNTIL it gets rebooted.
sendmail-8.18.1-1.fc40.x86_64 is installed for local e-mail handling.
On reboot, SOME of the accumulated messages--along with failure warning messages that have been generated--get delivered to local mailbox (/var/spool/mail/username). Other messages remain in the queue.
Today, I noted at the end of a dnf update, the following:
Reload daemon failed: Transport endpoint is not connected Failed to start jobs: Transport endpoint is not connected
No indication of which daemon being referred to, so it's not clear if this is referring to the sendmail daemon.
Journalctl reports (after rebooting):
Jul 03 09:45:04 kestrel (sendmail)[1524]: sendmail.service: Referenced but unset environment variable evaluates to an empty string: SENDMAIL_OPTARG Jul 03 09:45:04 kestrel sendmail[1525]: starting daemon (8.18.1): SMTP+queueing@ 01:00:00 Jul 03 09:45:04 kestrel systemd[1]: sendmail.service: Can't open PID file /run/sendmail.pid (yet?) after start: No such file or directory
And then, a batch of these, corresponding to the undelivered e-mails:
Jul 03 09:45:07 kestrel sendmail[1526]: 45T7V2ou003307: to=root@kestrel.tkevans.com, delay=4+06:14:04, xdelay=00:00:00, mailer=esmtp, pri=9500566, relay=kestrel.mynetworksettings.com., dsn=4.4.1, stat=Deferred: Connection refused by kestrel.mynetworksettings.com.
Even so, SOME the queued messages were in fact delivered after the reboot completed. Others remain in the queue, for example:
# mailq /var/spool/mqueue (9 requests) -----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------- 4627Lrpw008404 3884 Tue Jul 2 03:21 root@kestrel.tkevans.com (Deferred: Connection refused by kestrel.mynetworksettings.co) tkevans@kestrel.tkevans.com
I do not know where the bogus domain name "mynetworksettings.com" comes from, as the system has a proper hostname.
My other F40 systems do not have this issue, as local e-mail is delivered properly.
Suggestions for further digging? Thanks.
On Wed, 3 Jul 2024 10:04:30 -0400 Tim Evans wrote:
Suggestions for further digging? Thanks.
Probably not really helpful, but sendmail is utterly cryptic, I started using postfix years ago because it was easier to configure.
Maybe run as root:
fgrep -R mynetworksettings /etc
to see if it can find the cryptic bit laying around somewhere?
On Wed, Jul 3, 2024 at 11:43 AM Tom Horsley horsley1953@gmail.com wrote:
On Wed, 3 Jul 2024 10:04:30 -0400 Tim Evans wrote:
Suggestions for further digging? Thanks.
Probably not really helpful, but sendmail is utterly cryptic, I started using postfix years ago because it was easier to configure.
I did the same. A web search for <mynetworksettings.com> suggests it is a Verizon thing.
On Wed, Jul 3, 2024 at 12:16 PM George N. White III gnwiii@gmail.com wrote:
On Wed, Jul 3, 2024 at 11:43 AM Tom Horsley horsley1953@gmail.com wrote:
On Wed, 3 Jul 2024 10:04:30 -0400 Tim Evans wrote:
Suggestions for further digging? Thanks.
Probably not really helpful, but sendmail is utterly cryptic, I started using postfix years ago because it was easier to configure.
I did the same. A web search for <mynetworksettings.com> suggests it is a Verizon thing.
Found
https://www.verizon.com/content/dam/support/pdf/user_guide/Verizon-Internet-... In "CONFIGURE the VERIZON INTERNET GATEWAY", it says you can use 192.168.1.1 for <mynetworksettings.com> http://mynetworksettings.com!
On 7/3/24 11:25 AM, George N. White III wrote:
On Wed, Jul 3, 2024 at 12:16 PM George N. White III <gnwiii@gmail.com mailto:gnwiii@gmail.com> wrote:
On Wed, Jul 3, 2024 at 11:43 AM Tom Horsley <horsley1953@gmail.com <mailto:horsley1953@gmail.com>> wrote: On Wed, 3 Jul 2024 10:04:30 -0400 Tim Evans wrote: > Suggestions for further digging? Thanks. Probably not really helpful, but sendmail is utterly cryptic, I started using postfix years ago because it was easier to configure. I did the same. A web search for <mynetworksettings.com <http://mynetworksettings.com>> suggests it is a Verizon thing.Found https://www.verizon.com/content/dam/support/pdf/user_guide/Verizon-Internet-... https://www.verizon.com/content/dam/support/pdf/user_guide/Verizon-Internet-Gateway-(ASK-NCM1100)-User-Manual-v1.pdf In "CONFIGURE the VERIZON INTERNET GATEWAY", it says you can use 192.168.1.1 for <mynetworksettings.com> http://mynetworksettings.com!
Well, this suggests the system is trying to relay its LOCAL e-mail via Verizon's router, as this system is my network's firewall/router. (Other F40 systems on the internal network don't show this behavior, and local e-mail is delivered properly.)
On Wed, 2024-07-03 at 10:04 -0400, Tim Evans wrote:
Jul 03 09:45:07 kestrel sendmail[1526]: 45T7V2ou003307: to=root@kestrel.tkevans.com, delay=4+06:14:04, xdelay=00:00:00, mailer=esmtp, pri=9500566, relay=kestrel.mynetworksettings.com., dsn=4.4.1, stat=Deferred: Connection refused by kestrel.mynetworksettings.com.
Is your computer's network configured by DHCP? And is your ISP router the DHCP server? And is it your DNS server, too?
On 7/3/24 4:10 PM, Tim via users wrote:
On Wed, 2024-07-03 at 10:04 -0400, Tim Evans wrote:
Jul 03 09:45:07 kestrel sendmail[1526]: 45T7V2ou003307: to=root@kestrel.tkevans.com, delay=4+06:14:04, xdelay=00:00:00, mailer=esmtp, pri=9500566, relay=kestrel.mynetworksettings.com., dsn=4.4.1, stat=Deferred: Connection refused by kestrel.mynetworksettings.com.
Is your computer's network configured by DHCP? And is your ISP router the DHCP server? And is it your DNS server, too?
Thanks, your questions have led me to an apparent solution.
This system is my firwall/router, dual homed, on the protected internal network and the DMZ. Its internal network IP addresses is manually assigned; its external address gets its address via DHCP from the Verizon router. DNS is the auto-gobbledegook F40 uses, which point the system to itself. /etc/resolve.conf contains:
nameserver 127.0.0.53 options edns0 trust-ad search mynetworksettings.com
Se, we find where the bogus domain name comes from. AND, changing it to my actual domain name, then running the sendmail queue clears everything out of the queue.
On Wed, 3 Jul 2024 16:45:30 -0400 Tim Evans wrote:
Se, we find where the bogus domain name comes from. AND, changing it to my actual domain name, then running the sendmail queue clears everything out of the queue.
But will the network software put back the bogus resolv.conf behind your back so the problem will just return? :-).
On 7/3/24 5:52 PM, Tom Horsley wrote:
On Wed, 3 Jul 2024 16:45:30 -0400 Tim Evans wrote:
Se, we find where the bogus domain name comes from. AND, changing it to my actual domain name, then running the sendmail queue clears everything out of the queue.
But will the network software put back the bogus resolv.conf behind your back so the problem will just return? :-).
I expect that--will see on next reboot--but at least will know where to look next time.
On Wed, Jul 3, 2024 at 4:47 PM Tim Evans tkevans@tkevans.com wrote:
On 7/3/24 4:10 PM, Tim via users wrote:
On Wed, 2024-07-03 at 10:04 -0400, Tim Evans wrote:
Jul 03 09:45:07 kestrel sendmail[1526]: 45T7V2ou003307: to=root@kestrel.tkevans.com, delay=4+06:14:04, xdelay=00:00:00, mailer=esmtp, pri=9500566, relay=kestrel.mynetworksettings.com., dsn=4.4.1, stat=Deferred: Connection refused by kestrel.mynetworksettings.com.
Is your computer's network configured by DHCP? And is your ISP router the DHCP server? And is it your DNS server, too?
Thanks, your questions have led me to an apparent solution.
This system is my firwall/router, dual homed, on the protected internal network and the DMZ. Its internal network IP addresses is manually assigned; its external address gets its address via DHCP from the Verizon router. DNS is the auto-gobbledegook F40 uses, which point the system to itself. /etc/resolve.conf contains:
nameserver 127.0.0.53 options edns0 trust-ad search mynetworksettings.com
Se, we find where the bogus domain name comes from. AND, changing it to my actual domain name, then running the sendmail queue clears everything out of the queue.
mynetworksettings.com smells very fishy.
Does `sudo grep -IR 'mynetworksettings.com' /etc` reveal any interesting hits?
Jeff
On 3 Jul 2024, at 21:47, Tim Evans tkevans@tkevans.com wrote:
DNS is the auto-gobbledegook F40 uses, which point the system to itself.
The resolv.conf file is created on each boot.
Configure how dns works with the /etc/systemd/resolve.conf and networkmanager to ignore the search from dhcp. Then it will stop turning up.
You van use resolvectl to see what is going on.
Barry
-
Barry -
George N. White III -
Jeffrey Walton -
Mike Wright -
Tim -
Tim Evans -
Tom Horsley