Struggling to send anything from Exim4

Hi guys, I’m still struggling to send anything from Exim4…

Do you have any ideas?

2020-08-03 15:43:43 Start queue run: pid=7882
2020-08-03 15:43:44 1k2Zsk-00012B-Tq [] Invalid argument
2020-08-03 15:43:44 1k2Zsk-00012B-Tq == [email protected] R=dnslookup T=remote_smtp defer (22): Invalid argument


[email protected]:/etc/exim4# cat mailhelo.conf

What the contents is…

Looks ok to me?

Needs to point to the public facing name of your server not localhost.

Run the hostname command to see what that is

@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?

I’ll get back to you… most of this works but I’ll do a proper test and share… FYI, emails have been sent from this machine successfully before…

@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?

Ok, this is where I’ve got to…

The mailhelo.conf file seems ok having changed it from above…

[email protected]:~$ cat /etc/exim4/mailhelo.conf
[email protected]:~$ hostname

Also have you set up the reverse DNS for your server correctly?

It looks good to me, here’s the results from mxtoolbox…

Test	Result
	SMTP Reverse DNS Mismatch	OK - resolves to
	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

Where are you trying to send to?

A gsuite domain ( and a personal server (

where is the dns hosted?


Did you run dig against your domain to see if it’s configured properly?

Yes, this seems fine?

;; ANSWER SECTION:    300     IN      A

Did you run a telnet test to get more information?

Yeah… I can connect to gmail on port 25

[email protected]:~$ telnet 25
Connected to
Escape character is '^]'.
220 ESMTP t20sm1961435pjg.21 - gsmtp

I’ve also updated the /usr/local/hestia/func/ file but I think it had already been updated as per this pull request

Any help gratefully received!

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.

220 [627 ms]
EHLO Hello localhost []

The last line should read something like Hello []

Until you fix this you/we are not going to get anywhere!

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?

1 Like

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…

I’ve just run another test at MXToolbox on your domain and got a different mail server response

220 [630 ms]
EHLO Hello localhost []

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 your mailhelo.conf file should look like

I’ve assumed hestiacp is the same box

Please sort hestiacp host (if needed) and try this version of mailhelo.conf and report back

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…

So this is what I have in mailhelo.conf

But still gives the same localhost error?

You’re obviously working on the server right now as MXToolbox is timing out on your domain.

But a couple of points:

  1. If hestiacp is now your hostname you need to add it to mailhelo.conf and point it to itself (as the hostname)

  2. change every instance of mail.* to the right of the colons to hestiacp.* (or whatever you end up having as the hostname)

  3. 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? :wink:

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 which is set via LXD’s default bridge… The VM is on 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: connect=tcp: 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

NAT IP. 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?