On 18/11/2025 16:19, David Higton wrote:

In message <10fhnjv$1gvnc$5@dont-email.me>
The Natural Philosopher <tnp@invalid.invalid> wrote:

As part of my enhancements to the home controller, I want to send email
warnings of low heating oil level.

Have a look at Pushover to see if it would be an alternative way to
meet your needs. I use it to alert myself of problems in my heating
system.

David

my system is tailored to my needs. It works perfectly. I just need to
extend it a little. Nothing I can buy suited, so I rolled my own with
Pis and Picos.

Its actually one of the best bits of hardware and software I have ever done.

BUT it seems that the Pi will retry the queued mail and get it right on
the second attempt, so I may just leave it...

--
?A leader is best When people barely know he exists. Of a good leader,
who talks little,When his work is done, his aim fulfilled,They will say,
?We did this ourselves.?

? Lao Tzu, Tao Te Ching


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 18/11/2025 21:08, Computer Nerd Kev wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270:
message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270:
from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270:
to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name
not found. Name service error for name=vps.templar.co.uk type=MX: Host
not found, try again)

If it's the only network activity the thing does regularly, maybe
the WiFi interface has gone into some sort of sleep mode and the DNS
resolver isn't waiting for it to wake up. If you leave ping running
(eg. "nohup ping -s 1 vps.templar.co.uk &") to keep the interface
active, maybe it will work the first time?

I was logged in over ssh at the time, so that hound don't hunt :-(

Or if it doesn't change, you could set the IP address for
vps.templar.co.uk in /etc/hosts.

That could be a workaround. Good idea


--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.



--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The Natural Philosopher <tnp@invalid.invalid> wrote:

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270: message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270: from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38, delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name
not found. Name service error for name=vps.templar.co.uk type=MX: Host
not found, try again)

If it's the only network activity the thing does regularly, maybe
the WiFi interface has gone into some sort of sleep mode and the DNS
resolver isn't waiting for it to wake up. If you leave ping running
(eg. "nohup ping -s 1 vps.templar.co.uk &") to keep the interface
active, maybe it will work the first time?

Or if it doesn't change, you could set the IP address for
vps.templar.co.uk in /etc/hosts.

--
__ __
#_ < |\| |< _#

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In message <10fhnjv$1gvnc$5@dont-email.me>
The Natural Philosopher <tnp@invalid.invalid> wrote:

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

Have a look at Pushover to see if it would be an alternative way to
meet your needs. I use it to alert myself of problems in my heating
system.

David

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The Natural Philosopher <tnp@invalid.invalid> wrote:

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

So I removed exim which was too much like hard work, installed PostFix
and all is well...,except it isn't.

If I send a mail out of the blue after a a few hours delay, the mail immediately *always* gets stuck in the queue with a message about being unable to determine the IP address of the SMTP relay.

If I send another message everything Just Works, and indeed the h mail
queue gets flushed eventually as well with a successful delivery.

'Greylisting'? SMTP servers often delay mail from unrecognised senders as a spam block - spammers tend not come back when told to try again later.

Also the message needs to be correct to match SFP/DKIM/DMARC rules,
otherwise it may get delayed or discarded. It may also be delayed/discarded due to sending from a 'consumer' IP.

Perhaps by the time the second message arrives the spamfilter has decided you're ok and to let the message straight through.

I would not be doing direct SMTP in this day and age - send using an SMTP account (with username/password) at the company who runs the SMTP server for the sender's mail domain.

If the SMTP relay is indeed your domain's mail server, perhaps the first
time DNS lookup is too slow?

Theo

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

So I removed exim which was too much like hard work, installed PostFix
and all is well...,except it isn't.

If I send a mail out of the blue after a a few hours delay, the mail immediately *always* gets stuck in the queue with a message about being
unable to determine the IP address of the SMTP relay.

If I send another message everything Just Works, and indeed the h mail
queue gets flushed eventually as well with a successful delivery.

I have looked on line but not found this exact behaviour mentioned
anywhere..

I am not sure what is running DNS on that Zero W right now. But its
clo9ck is up to date with the internet...,




--
Future generations will wonder in bemused amazement that the early twenty-first century?s developed world went into hysterical panic over a globally average temperature increase of a few tenths of a degree, and,
on the basis of gross exaggerations of highly uncertain computer
projections combined into implausible chains of inference, proceeded to contemplate a rollback of the industrial age.

Richard Lindzen

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 18/11/2025 14:37, Theo wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

As part of my enhancements to the home controller, I want to send email
warnings of low heating oil level.

So I removed exim which was too much like hard work, installed PostFix
and all is well...,except it isn't.

If I send a mail out of the blue after a a few hours delay, the mail
immediately *always* gets stuck in the queue with a message about being
unable to determine the IP address of the SMTP relay.

If I send another message everything Just Works, and indeed the h mail
queue gets flushed eventually as well with a successful delivery.

'Greylisting'? SMTP servers often delay mail from unrecognised senders as a spam block - spammers tend not come back when told to try again later.

Its my smtp server. Sorry I didn't make that clear. No greylisting that
I am aware of

Also the message needs to be correct to match SFP/DKIM/DMARC rules,
otherwise it may get delayed or discarded. It may also be delayed/discarded due to sending from a 'consumer' IP.

Again, there is no issue as its set to accept any mail from anywhere
that is addressed to my home network.

Perhaps by the time the second message arrives the spamfilter has decided you're ok and to let the message straight through.

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270: message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270: from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name
not found. Name service error for name=vps.templar.co.uk type=MX: Host
not found, try again)
Nov 18 10:56:42 heating-controller postfix/qmgr[1295]: CC05B1F270: from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:56:43 heating-controller postfix/smtp[10697]: CC05B1F270: to=<superroot@templar.co.uk>,
relay=vps.templar.co.uk[185.113.128.151]:25, delay=587, delays=586/0.22/0.64/0.08, dsn=2.0.0, status=sent (250 OK
id=1vLJO7-0000r9-GS)
Nov 18 10:56:43 heating-controller postfix/qmgr[1295]: CC05B1F270: removed

I would not be doing direct SMTP in this day and age - send using an SMTP account (with username/password) at the company who runs the SMTP server for the sender's mail domain.

Sigh. I do for mail outward bound, but this is actually inward boiund.

If the SMTP relay is indeed your domain's mail server, perhaps the first
time DNS lookup is too slow?

Its something like that.

Let me say that all other boxes inside the network that are equipped for
mail work fine

Theo

--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 18 Nov 2025 15:27:01 +0000, The Natural Philosopher wrote:

Seriously,m its not the server, its the DNS.

What are you running as your DNS server?

Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38, delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain
name not found. Name service error for name=vps.templar.co.uk
type=MX: Host not found, try again)

You could try doing a lookup (using host or dig) to your DNS server
from the Raspberry pi at the same time as the MTA is reporting
problems, and see if your manual query reports the same problem.

Does your /etc/resolv.conf contain the right info? Is it a symlink to
somewhere else?

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 18/11/2025 12:08, The Natural Philosopher wrote:

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

This sounds rather like something I have been planning to do. AAMOI how
are you measuring the oil level?

--
Cheers,
Daniel.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19/11/2025 10:47, Andy Burns wrote:

The Natural Philosopher wrote:

Indicating a 5 minute delay between being queued and being sent...

grep 300 /etc/postfix/main.cf
maybe tweak smtpd_timeout=nn if that matches

Ah. That file actually exists.

Now can you see anything in this section that is odd?

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = heating-controller
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, heating-controller, localhost.localdomain, localhost
relayhost = vps.templar.co.uk
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = all

--

When plunder becomes a way of life for a group of men in a society, over
the course of time they create for themselves a legal system that
authorizes it and a moral code that glorifies it.

Fr‚d‚ric Bastiat


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19/11/2025 08:50, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

On 18/11/2025 21:08, Computer Nerd Kev wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270: >>>> message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270:
from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active) >>>> Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270:
to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name >>>> not found. Name service error for name=vps.templar.co.uk type=MX: Host >>>> not found, try again)

If it's the only network activity the thing does regularly, maybe
the WiFi interface has gone into some sort of sleep mode and the DNS
resolver isn't waiting for it to wake up. If you leave ping running
(eg. "nohup ping -s 1 vps.templar.co.uk &") to keep the interface
active, maybe it will work the first time?

I was logged in over ssh at the time, so that hound don't hunt :-(

Was the SSH session actually doing anything? An idle SSH session doesn?t
have to exchange any packets at all.

I used it to compose and send the mail...from the command line

But ?it?s always DNS? is a pretty reliable starting point for network debugging, and I think it?s the right one here.

What are you using as a name server? i.e. what is in resolv.conf on this machine?

Stuff that apparently isn't used.
It was set to 127.0.0.1 and IIRC dnsmasq was running.
I set it to my internal servers that run BIND but I dont think its
actually using them

Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38, delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain
name not found. Name service error for name=vps.templar.co.uk type=MX:
Host not found, try again)
^^^^^^^^^^^^^^^^^^^^^^^^^

It?s a temporary failure, ?TRY_AGAIN? ultimately from something in
resolv.h or netdb.h, but with a lot of Postfix-specific DNS code around
it.

Well I figured that it was temporary by the way the thing turns up a few minutes later...

vps.templar.co.uk. 3600 IN MX 5 vps.templar.co.uk.

Your MX record has 1-hour TTL, so an hour after the last successful
query, your local (or ISP-provided) name server will have to ask domaincontrol.com again. That may explain why ?a few hours delay? brings
the condition back.

Ah, cache timed out. But local servers contacting that address to fetch
mail every few minutes, so the local dns servers will always have it.
Question is whether the pi is actually using them

When I tried to discover what was being used it turns out that there are
(at least) three possible mechanisms in use whose config files did not
match anything on the Pi. Usual 'lets change it all for this release' stuff.

So no, I don't know what it is now using as a DNS client.

Its very odd. I just did this...

# dig vps.templar.co.uk

; <<>> DiG 9.16.50-Raspbian <<>> vps.templar.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24512
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7f7ca1b95493f5c601000000691d9a18750f0123b174788b (good)
;; QUESTION SECTION:
;vps.templar.co.uk. IN A

;; ANSWER SECTION:
vps.templar.co.uk. 3726 IN A 185.113.128.151

;; Query time: 9 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Wed Nov 19 10:21:12 GMT 2025
;; MSG SIZE rcvd: 90
...then this...
root@heating-controller:/var/ramlog# echo "This is more bollox isn't
it?" | mail -a "From: oil-monitor@heating-controller" -s "another
message" superroot@templar.co.uk
...and this...
root@heating-controller:/var/ramlog# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
C459D1FE2E 387 Wed Nov 19 10:21:48 oil-monitor@heating-controller
(Host or domain name not found. Name service error for
name=vps.templar.co.uk type=MX: Host not found, try again)
superroot@templar.co.uk

-- 0 Kbytes in 1 Request.

Now unless dig is using some other means than postfix to look up DNS, it
looks like the problem is in postfix somehow.

I don't know how to work that out.

Maybe I should forget postfix and code up a simple SMTP client

Just like the old days....:-)

and finally a few minutes later...

# mailq
Mail queue is empty

...so it finally figured out how to send it..

Curiously the headers reveal this

Received: from [212.69.38.60] (helo=heating-controller)
by vps.templar.co.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.72)
(envelope-from <oil-monitor@heating-controller>)
id 1vLfOk-0006a6-4z
for superroot@templar.co.uk; Wed, 19 Nov 2025 10:26:50 +0000
Received: by heating-controller (Postfix, from userid 0)
id C459D1FE2E; Wed, 19 Nov 2025 10:21:48 +0000 (GMT)

Indicating a 5 minute delay between being queued and being sent...

domaincontrol.com seems to be pretty fast from here but if for whatever reason the network between you and domaincontrol is slow or unreliable,
or the name server you?re using is underprovisioned, then that could
explain the temporary failures here. By the time you send the another
message everything has caught up, explaining why it works on the second attempt.

All other machines work just fine. I wonder if in fact something is
swapped out on the zero.


--
?The urge to save humanity is almost always only a false face for the
urge to rule it.?
? H. L. Mencken


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

Do you want to run you own mail domain or do you just want to use a
freemail account for sending that out?

--
kind regards
Marco

Send spam to 1763476021muell@stinkedores.dorfdsl.de


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19/11/2025 07:56, Marco Moock wrote:

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

No. I wont. Because it is effectively private intra domain email.

Do you want to run you own mail domain or do you just want to use a
freemail account for sending that out?

As I said. I already run my own domains under half a dozen domain names
that I own.

The SMTP server will accept anything so long as it is addressed to one
of my domains. And is not from a blacklisted domain.


--
I would rather have questions that cannot be answered...
...than to have answers that cannot be questioned

Richard Feynman




--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Daniel James <daniel@me.invalid> wrote:

On 18/11/2025 12:08, The Natural Philosopher wrote:

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

This sounds rather like something I have been planning to do. AAMOI how
are you measuring the oil level?

FWIW I had one of those Watchman ultrasonic oil tank sensors and I could
pick up the reading via rtl_433 and a cheap RTL2832-based DVB TV dongle.
(as well as the tyres on the car, and various other gizmos locally).

Perhaps a wires-free option if you already have such a sensor?

Theo

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19/11/2025 10:34, Theo wrote:

Daniel James <daniel@me.invalid> wrote:

On 18/11/2025 12:08, The Natural Philosopher wrote:

As part of my enhancements to the home controller, I want to send email
warnings of low heating oil level.

This sounds rather like something I have been planning to do. AAMOI how
are you measuring the oil level?

FWIW I had one of those Watchman ultrasonic oil tank sensors and I could
pick up the reading via rtl_433 and a cheap RTL2832-based DVB TV dongle.
(as well as the tyres on the car, and various other gizmos locally).

Perhaps a wires-free option if you already have such a sensor?

Theo

I do indeed and its utter failure to provide a reliable link is the main reason I am building this one.

I thought about doing what you mention but the 433MHz never talked
reliably to the house., ever. And then when I started playing with Pico
Pi Ws it seems sane to use the same technology as I had already sort of
- if not mastered - at least got working, for the thermostats.

The problem is that the tank is fairly remote - between 15 and 40 metres
from various bits of the house and 433MHz never quite was reliable.
Especially in the wind or rain. And it never reliably told me the
battery was low either. Or that all the oil in the tank had been stolen,
or run out.

Whereas I can do wifi to a particular wifi point at a reliable -90dbm or
so from the tank location as far as I have tested it.

I with I could monitor the oil quality somehow. I always order premium
but the last lot exploded the Aga last night blowing soot everywhere.
Sigh. Another strip down and clean...

That what happens when you run out and order stuff in a hurry. They
disregard the order and deliver whatever shit is on the tanker.

Hence why the oil sensor project is top priority.

Anyway, wrench time.
Cy'all later...

--
If you tell a lie big enough and keep repeating it, people will
eventually come to believe it. The lie can be maintained only for such
time as the State can shield the people from the political, economic
and/or military consequences of the lie. It thus becomes vitally
important for the State to use all of its powers to repress dissent, for
the truth is the mortal enemy of the lie, and thus by extension, the
truth is the greatest enemy of the State.

Joseph Goebbels





--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The Natural Philosopher <tnp@invalid.invalid> writes:

On 18/11/2025 21:08, Computer Nerd Kev wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270:
message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270:
from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270:
to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name >>> not found. Name service error for name=vps.templar.co.uk type=MX: Host
not found, try again)

If it's the only network activity the thing does regularly, maybe
the WiFi interface has gone into some sort of sleep mode and the DNS
resolver isn't waiting for it to wake up. If you leave ping running
(eg. "nohup ping -s 1 vps.templar.co.uk &") to keep the interface
active, maybe it will work the first time?

I was logged in over ssh at the time, so that hound don't hunt :-(

Was the SSH session actually doing anything? An idle SSH session doesn?t
have to exchange any packets at all.

But ?it?s always DNS? is a pretty reliable starting point for network debugging, and I think it?s the right one here.

What are you using as a name server? i.e. what is in resolv.conf on this machine?

Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain
name not found. Name service error for name=vps.templar.co.uk type=MX:
Host not found, try again)
^^^^^^^^^^^^^^^^^^^^^^^^^

It?s a temporary failure, ?TRY_AGAIN? ultimately from something in
resolv.h or netdb.h, but with a lot of Postfix-specific DNS code around
it.

vps.templar.co.uk. 3600 IN MX 5 vps.templar.co.uk.

Your MX record has 1-hour TTL, so an hour after the last successful
query, your local (or ISP-provided) name server will have to ask domaincontrol.com again. That may explain why ?a few hours delay? brings
the condition back.

domaincontrol.com seems to be pretty fast from here but if for whatever
reason the network between you and domaincontrol is slow or unreliable,
or the name server you?re using is underprovisioned, then that could
explain the temporary failures here. By the time you send the another
message everything has caught up, explaining why it works on the second attempt.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19/11/2025 12:18, The Natural Philosopher wrote:

On 19/11/2025 11:13, Mike Scott wrote:

On 19/11/2025 10:33, The Natural Philosopher wrote:

# dig vps.templar.co.uk

dig -t any .......

essentially the same result, but thanksÿ anyway...

Hmm, interesting, the result depends, it seems, on the dns server:

dig -t any vps.templar.co.uk

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> -t any vps.templar.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48113
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;vps.templar.co.uk. IN ANY

;; ANSWER SECTION:
vps.templar.co.uk. 6346 IN A 185.113.128.151

;; Query time: 7 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (TCP)
;; WHEN: Wed Nov 19 16:30:45 GMT 2025
;; MSG SIZE rcvd: 62

dig -t any @8.8.8.8 vps.templar.co.uk

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> -t any @8.8.8.8 vps.templar.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48917
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;vps.templar.co.uk. IN ANY

;; ANSWER SECTION:
vps.templar.co.uk. 8600 IN A 185.113.128.151 vps.templar.co.uk. 3600 IN MX 5 vps.templar.co.uk.

;; Query time: 37 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (TCP)
;; WHEN: Wed Nov 19 16:31:18 GMT 2025
;; MSG SIZE rcvd: 78





--
Mike Scott
Harlow, England

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19/11/2025 10:33, The Natural Philosopher wrote:

# dig vps.templar.co.uk

dig -t any .......


--
Mike Scott
Harlow, England

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 19 Nov 2025 08:56:56 +0100, Marco Moock wrote:

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

If that were the problem, then the mail would not eventually go
through. It would be blocked, and that?s that.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19/11/2025 11:13, Mike Scott wrote:

On 19/11/2025 10:33, The Natural Philosopher wrote:

# dig vps.templar.co.uk

dig -t any .......

essentially the same result, but thanks anyway...

--
Renewable energy: Expensive solutions that don't work to a problem that doesn't exist instituted by self legalising protection rackets that
don't protect, masquerading as public servants who don't serve the public.



--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19/11/2025 18:03, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

So no, I don't know what it is now using as a DNS client.

Its very odd. I just did this...

# dig vps.templar.co.uk

; <<>> DiG 9.16.50-Raspbian <<>> vps.templar.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24512
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7f7ca1b95493f5c601000000691d9a18750f0123b174788b (good)
;; QUESTION SECTION:
;vps.templar.co.uk. IN A

;; ANSWER SECTION:
vps.templar.co.uk. 3726 IN A 185.113.128.151

;; Query time: 9 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Wed Nov 19 10:21:12 GMT 2025
;; MSG SIZE rcvd: 90
...then this...
root@heating-controller:/var/ramlog# echo "This is more bollox isn't
it?" | mail -a "From: oil-monitor@heating-controller" -s "another
message" superroot@templar.co.uk
...and this...
root@heating-controller:/var/ramlog# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
C459D1FE2E 387 Wed Nov 19 10:21:48 oil-monitor@heating-controller
(Host or domain name not found. Name service error for
name=vps.templar.co.uk type=MX: Host not found, try again)
superroot@templar.co.uk

-- 0 Kbytes in 1 Request.

Now unless dig is using some other means than postfix to look up DNS,
it looks like the problem is in postfix somehow.

Maybe, but the above doesn?t prove it; you?ve asked for an A record but Postfix asks for an MX record, so your lookup won?t have populated the
cache (if there is one). (It?ll look for the A record next, but until
it?s got the MX record it doesn?t know what A record to ask for.)

If there is doubt about what name server is being used you could use
tcpdump to find out.

sudo tcpdump -np -i br0 udp port 53

Replace br0 with your own network interface. You?ll need to check at
least loopback (lo) and any real network interfaces.

Dig...mx returns instantly with the correct answer too



--
?I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most
obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which
they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives.?

? Leo Tolstoy


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19.11.2025 10:11 Uhr The Natural Philosopher wrote:

On 19/11/2025 07:56, Marco Moock wrote:

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

No. I wont. Because it is effectively private intra domain email.

Then make sure your postfix doesn't check that. It seems for me it does.


--
kind regards
Marco

Send spam to 1763543504muell@stinkedores.dorfdsl.de


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The Natural Philosopher <tnp@invalid.invalid> writes:

So no, I don't know what it is now using as a DNS client.

Its very odd. I just did this...

# dig vps.templar.co.uk

; <<>> DiG 9.16.50-Raspbian <<>> vps.templar.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24512
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7f7ca1b95493f5c601000000691d9a18750f0123b174788b (good)
;; QUESTION SECTION:
;vps.templar.co.uk. IN A

;; ANSWER SECTION:
vps.templar.co.uk. 3726 IN A 185.113.128.151

;; Query time: 9 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Wed Nov 19 10:21:12 GMT 2025
;; MSG SIZE rcvd: 90
...then this...
root@heating-controller:/var/ramlog# echo "This is more bollox isn't
it?" | mail -a "From: oil-monitor@heating-controller" -s "another
message" superroot@templar.co.uk
...and this...
root@heating-controller:/var/ramlog# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
C459D1FE2E 387 Wed Nov 19 10:21:48 oil-monitor@heating-controller
(Host or domain name not found. Name service error for
name=vps.templar.co.uk type=MX: Host not found, try again)
superroot@templar.co.uk

-- 0 Kbytes in 1 Request.

Now unless dig is using some other means than postfix to look up DNS,
it looks like the problem is in postfix somehow.

Maybe, but the above doesn?t prove it; you?ve asked for an A record but
Postfix asks for an MX record, so your lookup won?t have populated the
cache (if there is one). (It?ll look for the A record next, but until
it?s got the MX record it doesn?t know what A record to ask for.)

If there is doubt about what name server is being used you could use
tcpdump to find out.

sudo tcpdump -np -i br0 udp port 53

Replace br0 with your own network interface. You?ll need to check at
least loopback (lo) and any real network interfaces.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 19 Nov 2025 16:32:49 +0000, Mike Scott wrote:

On 19/11/2025 12:18, The Natural Philosopher wrote:

On 19/11/2025 11:13, Mike Scott wrote:

On 19/11/2025 10:33, The Natural Philosopher wrote:

# dig vps.templar.co.uk

dig -t any .......

essentially the same result, but thanksÿ anyway...

Hmm, interesting, the result depends, it seems, on the dns server:

Some DNS admins don?t like the idea of any kind of ?wildcard? or ?all information? queries: they want you to specifically ask for what you want,
no casual browsing permitted.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 19 Nov 2025 10:33:19 +0000, The Natural Philosopher wrote:

[/etc/resolv.conf] was set to 127.0.0.1 and IIRC dnsmasq was
running. I set it to my internal servers that run BIND but I dont
think its actually using them

dnsmasq by default uses /etc/resolv.conf, unless you point it at
another such file with the --resolv-file option -- obviously you have
to do this to avoid circularity, if dnsmasq is supposed to be the one
handling DNS requests sent to the 127.0.0.1 address.

So no, I don't know what it is now using as a DNS client.

It is normal for DNS clients to use /etc/resolv.conf. Can?t see any
reason to configure any of them to use some special setting -- apart
of course from a local caching DNS server like dnsmasq, or special DNS diagnostic tools like dig and host. In other words, everything that
just expects to use the DNS, rather than be part of administering/troubleshooting the DNS infrastructure, should just be
using /etc/resolv.conf.

Now unless dig is using some other means than postfix to look up
DNS, it looks like the problem is in postfix somehow.

dig has nothing to do with Postfix. DNS tools like dig and host
implement their own low-level DNS clients, which can be configured to
do queries in all kinds of ways, precisely to help with
troubleshooting DNS problems.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Marco Moock <mm@dorfdsl.de> writes:

On 19.11.2025 10:11 Uhr The Natural Philosopher wrote:

On 19/11/2025 07:56, Marco Moock wrote:

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

No. I wont. Because it is effectively private intra domain email.

Then make sure your postfix doesn't check that. It seems for me it does.

That is obviously not going to cause a temporary failure looking up the
MX for vps.templar.co.uk. Just look at the logfile fragment rather than guessing blindly. We know what the error is and it?s absolutely nothing
to do with source address validity.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.1
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)