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)

On 18/11/2025 23:15, Daniel James 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?

Oh. I designed a board with

- a Pi Pico W.
- a three pin temperature sensor ( TMP36) to monitor outside temperature
- an ultrasonic transmitter/receiver ( HCRS04) on it
- a nano power timer that (Was a sparkfun nano power switch TPL5110
until I blew it up and replaced it with a sub-board with an Adafruit
TPL5110 Low Power Timer ) wakes up every 2 hours, tries to make contact
with the wifi, sends a short message to the server, and then commits
suicide and shuts the timer down again.

Board designs all available if you want.

Also source code, suitably modified to remove my wifi password

At the far end is a Pi Zero with a very simple daemon running under
inetd, to listen to the call and write the data to a file in a ramdisk.

A web server then parses that data and calculates the oil level and
displays it. (along with room temps and central heating states which it
also controls)

The intention is to run code under cron as well, and send warning emails.

I may not bother to fix the DNS problem since it seems to resend the
mail within the hours successfully.

--
No Apple devices were knowingly used in the preparation of this post.


--- 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)