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...,
Didn't find your answer? Ask the community — no account required.
T
Theo
'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
T
The Natural Philosopher
Its my smtp server. Sorry I didn't make that clear. No greylisting that I am aware of
Again, there is no issue as its set to accept any mail from anywhere that is addressed to my home network.
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= snipped-for-privacy@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= snipped-for-privacy@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
Sigh. I do for mail outward bound, but this is actually inward boiund.
Its something like that.
Let me say that all other boxes inside the network that are equipped for mail work fine
D
David Higton
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
T
The Natural Philosopher
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...
C
Computer Nerd Kev
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.
T
The Natural Philosopher
I was logged in over ssh at the time, so that hound don't hunt :-(
That could be a workaround. Good idea
D
Daniel James
This sounds rather like something I have been planning to do. AAMOI how are you measuring the oil level?
L
Lawrence D’Oliveiro
What are you running as your DNS server?
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?
M
Marco Moock
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?
R
Richard Kettlewell
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= snipped-for-privacy@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.
T
The Natural Philosopher
No. I wont. Because it is effectively private intra domain email.
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.
T
The Natural Philosopher
I used it to compose and send the mail...from the command line
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
Well I figured that it was temporary by the way the thing turns up a few minutes later...
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.
;; 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" snipped-for-privacy@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) snipped-for-privacy@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 snipped-for-privacy@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...
All other machines work just fine. I wonder if in fact something is swapped out on the zero.
T
Theo
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
A
Andy Burns
grep 300 /etc/postfix/main.cf maybe tweak smtpd_timeout=nn if that matches
T
The Natural Philosopher
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 s*it is on the tanker.
Hence why the oil sensor project is top priority.
Anyway, wrench time. Cy'all later...
T
The Natural Philosopher
Ah. That file actually exists.
Now can you see anything in this section that is odd?
-- 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.
M
Mike Scott
Hmm, interesting, the result depends, it seems, on the dns server: