AWS install. Exim SMTP HELO banner incorrect

Whew, so I just moved a hestia install from a regular server over to AWS. It wasn’t too bad, but once mail moved over we had a problem with sending emails.

When sending through exim (to another Hestia server as it happens), the server reported itself through HELO as "ip-1-2-3-4-ap-southeast-1.compute.internal when it was talking to the recipient server, and the mail was rejected. I couldn’t figure out where exim was getting this.
hostname -f was fine
PTR record was set OK.
/etc/hosts and /etc/hostname were correct
/etc/mailname was OK although that doesn’t seem to be used.
I tried creating a /etc/exim/mailhelo.conf but that didn’t seem to do anything.

I looked through the config and started changing various settings smtp_banner and a few others. The one that actually had an effect was this one, found in the remote_smtp Transport:
helo_data = ${lookup dnsdb{>: defer_never,ptr=$sending_ip_address}{${listextract{1}{$value}}}{$primary_hostname}}
Setting that to instead of the lookup allowed the server to send mails correctly.

So it seems what is happening is that the lookup finds the PTR record for the AWS local IP address, and uses that to incorrectly set the HELO name. Instead of using the PTR record for the public IP address, which is set correctly.

Is this a bug, or do I need to set an IP somewhere to allow the lookup to work. I originally had to install the server using a temp domain name, as the domain was in use on the old server until I transferred the mail over last night.

You can set sending ip:


We might need to some testing on AWS server…

I’m not sure that was the fix I was looking for. After changing the /etc/exim4/domains/ file to read as the PUBLIC ip (it was set to the private AWS 172.x.x.x one), it seemed that exim was unable to send mails to any external domains. It looked like what was happening was that it tried to look up the domain and failed. However the host server was able to resolve dns with no problems.
I reverted the config so that the ip file holds the private address for now, and as a temporary measure I still have helo_data = set in the remote_smtp transport until I can figure this out.

Any other ideas?

Current installation sucks a bit. It loops trough all ips in /etc/netplan/ / what ever and picks the order that is in.

We probally need to modify to check what is a public / private ip and block the private ips “somehow”

Hmm. Well during install it correctly got the public IP and its listed in v-list-sys-ips

For exim, it obviously needs to use this public IP address in the HELO, as that’s what the PTR is set to. But I don’t immediately see a way for exim to do a DB lookup on Hestia data.

In netplan on this AWS box it’s told to get its IP by DHCP, so the IP didn’t come directly from that file either.

There should be multiple ips added I am correct… And I think by default it picks the wrong one… It is strange behaviour need to look into it…

Just a random thought. I recall it installed OK on some AWS installs last year, but those were Ubuntu 20.04. This one was 22.04, so uses a different exim version and config. Wondering if that’s something to do with it …

Same here, with VM on OCI Oracle Cloud. helo banner with private ip resolution not good reputation. I change in exim4.config helo_data not efect and smtp_active_hostname change
with fqd and restart exim, changed de helo banner ok.