On my new host, if I send an email using Roundcube - the “Sending message” pop up stays for 30s and then says “Message sent sucessfully”. This is consistent.
Even using telnet to port 25 - it takes 30s or so to present the SMTP banner.
Operating system- Ubuntu Linux 18.04.4
Perl version - 5.026001
BIND version - 9.11 - disabled and not running
Postfix version - 3.3.0
Apache version - 2.4.29
PHP versions - 7.2.24
MySQL version - 5.7.30-0ubuntu0.18.04.1
Roundcube - 1.4.5
Going thru the Postfix configuration between this host and the old one (which sends instantly and presents the SMTP banner almost instantly) - nothing jumps out that’s different.
Both hosts use spamc instead of the standalone spamassassin.
I’ve reloaded Postfix & restarted it a few times since altering resolv.conf (removing 127.0.0.1 and adding external ones in - same as my other working host).
Even telnet’ing to the FQDN or the IP on port 25 - still takes about 30s for the 220 banner to appear.
I do wonder if the 30s for the banner to appear and the 30s it takes for Roundcube to send are related.
Server & client (broadband connection at home) both have the correct PTR records and revolve both ways. Checked it with nslookup.
DNS servers in resolv.conf - they are the same as the working host (which has no issues and telnet’ing to the FQDN\IP on port 25, the banner 220 response is instant). Don’t really know what else to look at.
I’ve gone looking round in a few places - /etc/resolv.conf & in /var/spool/postfix/etc/resolv.conf - and they just had the 127.0.0.1 entry, not the multiple nameserver entries that the working server has and the ones I’d entered in Webmin >> Network Configuration >> Hostname & DNS Client.
So altered the pair to be what I think they should be (the same as the working server), saved them and restarted Postfix.
Now I constantly get a
postfix/postfix-script[16785]: warning: /var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ
message in /var/log/mail.log even tho both files are identical. Any suggestions?
You’re running postfix chrooted. I don’t remember how to make it update its chroot, as I don’t run it in a chroot (and I seem to recall the author not recommending doing so), and we don’t normally set it up that way unless it’s already chrooted when the install runs.
In all fairness - I just ran the installer for Virtualmin as in the docs. Will have to Google about the chroot. Thanks for the suggestion on where to look.
It’s possible that the default package option is to chroot it, but I don’t think that’s the case. I feel like it requires being told to do so. But, if postfix was already pre-installed on your VM or something it could have been chrooted. I think Virtualmin/Webmin can work with it in a chroot, but it’s unnecessary complexity for questionable benefits (chroot theoretically improves security, but it potentially opens up new attack vectors, so it’s usually a wash…and the added complexity is a cost, too).
At the moment I’m just trying to get /etc/resolv.conf to stick. By that I mean, add the entries for the external name servers, removing the 127.0.0.53 entry and have it persist over a reboot.
The VPS is a Linode one and I’ve disabled their Network Helper which modifies that file.
The changes aren’t persisting no matter what I do (at the moment).
Just realised on Ubuntu 18.04 etc/resolve.conf isn’t “used” or updated. Netplan seems to be used.
So a step back in trying to figure out why I’m getting a 30s delay in emails sending and the 220 banner response when telnet’ing into port 25 on the server.
It’s chroot’d by default. A quick look in /etc/postfix.master.cf (on new problematic server and the old fine one) shows smtp with a “y” under the Chroot column.
Not any wiser as to the 30s delay but still learning. LOL
Dibs
p.s. During the install (via the script in the docs - wasn’t asked if I wanted it chroot’d. Or don’t recall so.)
We’re doing test installs on 20.04 this week, so I’ll try to remember to have a look at whether it defaults to chroot. If it is, I probably want to unchroot it. It’s a source of confusion for a lot of users and for no real benefit. It is definitely not chrooted by default on CentOS (the default I’m talking about would be a package decision, nothing to do with Virtualmin, as we don’t provide the postfix package).
Unless gethostbyname is netplan-aware I’m pretty sure resolv.conf is still how software figures out how to resolve domain names. Netplan is a network configuration tool, it is not replacing the whole Linux network stack.
Nonetheless, your problem remains DNS isn’t configured right.
Thankfully I have an existing (working) server to compare with.
Going thru /etc/postfix/main.cf and /etc/postfix/master.cf there wasn’t much different between them.
Main.cf (new server) had the additional entries for milter - DKIM is enabled on the server - whilst the existing one didn’t.
The one key difference between them in main.cf is
New Server - inet_protocols = all
Old server - inet_protocols = ipv4
So I changed the new server to inet_protocols = ipv4.
Reloaded the config and stopped and started postfix for good measure - nothing amiss in the mail.log, so sent an email from new server to old server - it spat an error out about authentication.
Jun 9 23:11:50 host2 postfix/smtpd[12610]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
Jun 9 23:11:50 host2 postfix/smtpd[12610]: warning: localhost[127.0.0.1]: SASL LOGIN authentication failed: generic failure
So set the chroot option back from n to y in master.cf (new server) - I has changed it in an attempt to get it out of the chroot.
Reloaded config and stopped & started postfix for good measure - nothing amiss during startup in mail.log.
So opened up a telnet session on port 25 (new server) and the 220 banner came back instantly. Held back the urge to celebrate and opened up Roundcube (new server) and sent an email to an account on the old server - and YES it went instantly.
I suspect Postfix was trying a DNS or other network related query on IPv6 but IPv6 is disabled.
So on with setting DMARC tomorrow and then moving domains\virtual servers from old server. Probably more problems waiting there. LOL
