@bruce78 that log entry is by far not enough information…
where are you trying to send to? where is the dns hosted? did you run dig against your domain to see if it’s configured properly? did you run a telnet test to get more information?
@bruce78 Your mailhelo.conf file is wrong. See my reply above. If receiving mail servers see “localhost” in reply to the EHLO question, they will reject the response - at least Google and GMX do in my tests when I was trying to debug this issue.
Also have you set up the reverse DNS for your server correctly?
Also have you set up the reverse DNS for your server correctly?
It looks good to me, here’s the results from mxtoolbox…
220 mail.emailfourgroups.com
Test Result
SMTP Reverse DNS Mismatch OK - 204.15.77.205 resolves to mail.emailfourgroups.com
SMTP Valid Hostname OK - Reverse DNS is a valid Hostname
SMTP Banner Check OK - Reverse DNS matches SMTP Banner
SMTP TLS OK - Supports TLS.
SMTP Connection Time 0.758 seconds - Good on Connection time
SMTP Open Relay OK - Not an open relay.
SMTP Transaction Time 2.983 seconds - Good on Transaction Time
Did you run dig against your domain to see if it’s configured properly?
Yes, this seems fine?
dig emailfourgroups.com
...
;; ANSWER SECTION:
emailfourgroups.com. 300 IN A 204.15.77.205
Did you run a telnet test to get more information?
Yeah… I can connect to gmail on port 25
debian@mail:~$ telnet smtp.gmail.com 25
Trying 74.125.20.109...
Connected to smtp.gmail.com.
Escape character is '^]'.
220 smtp.gmail.com ESMTP t20sm1961435pjg.21 - gsmtp
I’ve also updated the /usr/local/hestia/func/ip.sh file but I think it had already been updated as per this pull request https://github.com/hestiacp/hestiacp/pull/924/files
Really silly question but when you updated the mailhelo.conf file, did you restart exim?
I’ve just run the SuperTool test on your server at MXToolbox and your EHLO setup is still pointing to localhost as you can see below, hence my question above.
hmm, so what is the real problem then? the initial log entry does not say much. you should get a full error code from the rejecting mail server or see something like rejected…
the message above seems more like from a queue retry or something like that? did you check the mailqueue and eventually clean it up?
are you forwarding mails? or are you really missing mails this very server tries to send?
forwarding is whole different topic and often fails because you will run into troubles with SPF records because the source does not match after the forward anymore or all spam that gots forwarded as well is deferred and creates stuck mails in the queue or even backscatter, double bounces etc.
mail problems can be tricky… so to analyze this better we’d need a full example of log entries or return codes regarding a mail that could not be sent from your server. aka how can you reproduce the issue if a telnet connection properly works?
Thank you @brackenhill-mob, this gives me something to google… I’ve updated mailhelo.conf and restarted exim and done some reboots but I get the same message as you get above…
Where has this hestiscp host appeared from? If it is the same box that we are trying to debug, you must not make additional changes without telling us otherwise we’re shooting in the dark!! If it’s a different server you need to pair everything back so we are working on a single box to fix.
Anyway something is not right with your mailhelo.conf. In your messages yesterday there was only one entry in it for your domain. There should be as many entries as there are mail domains in Hestia PLUS the name of the host itself (which is used for cronjob messages etc).
So I’ve reinstalled Hestia, hence the different hostname…
I’ll try that new mailconf setting too… I’m also wondering if running Hestia in an LXD container isn’t playing a part here as well? I’m currently investigating…
You’re obviously working on the server right now as MXToolbox is timing out on your domain.
But a couple of points:
If hestiacp is now your hostname you need to add it to mailhelo.conf and point it to itself (as the hostname)
change every instance of mail.* to the right of the colons to hestiacp.* (or whatever you end up having as the hostname)
You must set up the reverse DNS so that it matches the hostname
I’ve got no experience of running containers so I can’t help on that on. But another silly question - when you make changes to config files, how do you get them to take effect? Do you run sys(tem)ctl or do you reboot? If the former, I know from experience how easy it is to forget to run one of the required system calls when trying different options so a reboot might be an idea to force everything to come up correctly (or otherwise!!)
if reinstalling isn’t a problem, that’s the way to go. there should be no need to manually fiddle with the mailhelo.conf file at all.
just make sure you setup your box properly before, with a hostname and/or hosts entries. dns should resolve properly etc. as you are speaking of an LXC container - is this by any chance a NATted box?
I’ve reinstalled and have tweaked things like etc/hosts but no joy yet…
I was sending emails from the system in early July and all was well, so I’m wondering if this upgrade hasn’t had an impact?
is this by any chance a NATted box?
I’m not sure what you mean here exactly… It’s a simple VPS with Debian 9 on the host and Debian 10 in the LXC container… but I’m thinking that something is going awry between the host and/or inside the container, even though all of the standard tests above seem to work fine…
by that question about NAT I mean: does that guest container has it’s own dedicated IP address or is it sharing the hosts one and has only a private/local IP?
can you try sending a mail from a fully added mail-account in hestia to whatever receipient (gmail?) either via your local client or webmail… and post the full part of the logfiles that matches this exact timestamp?
So the LXD container is on 10.154.223.108 which is set via LXD’s default bridge… The VM is on 204.15.77.205 and a bunch of ports are forwarded from the LXD host to the cotainer via the lxc config device add efg-email myport25 proxy listen=tcp:0.0.0.0:25 connect=tcp:127.0.0.1:25 style command, one for each port…
As above, I’ve run this system on exactly the same host and inside an LXD container and been able to send emails fine until the 1.2 upgrade or similar…
can you try sending a mail from a fully added mail-account in hestia to whatever receipient (gmail?) either via your local client or webmail… and post the full part of the logfiles that matches this exact timestamp?
Sure, where are the detailed logs for exim4 when I send? var/log/exim4/mainlog doesn’t seem detailed enough?
Ok, so I’ve learnt that in re-installing and re-configuring that I need to add a new IP address in order to access new domains and get Lets Encrypt to issue certificates…
The details of the new IP are
IP.
127.0.0.1
Netmask.
225.225.225.0
Interface.
eth0
NAT IP.
204.15.77.205 or whatever is being used
Once that is done and assigned to the domains, they load up and get ssl certificates fine…
So I’m wondering if this new IP setting isn’t getting picked up by Exim?