Exim SMTP banner based on connecting IP (domain)

Continuing the discussion from Exim4 Outbound IP address based on web domain IP:

Is the same possible for inbound IP?

For example I have main server with hostname server.domain1.com with IP x.x.x.x.
and when I connect to a server i get:

Connecting to x.x.x.x
220 server.domain1.com [688 ms]
EHLO open.relay.hunter
250-server.domain1.com Hello open.relay.hunter

as expected,

but when I try to connect on other domain and IP (with the same rDNS) mail.domain2.com IP: y.y.y.y
I still get the primary hostname:
Connecting to y.y.y.y
220 server.domain1.com [688 ms]
EHLO open.relay.hunter
250-server.domain1.com Hello open.relay.hunter

Is it possible to change this to domain2?

My /etc/exim/conf.d/main/02_exim4-config_options are:
MAIN_SMTP_BANNER = “${primary_hostname} ESMTP Exim”
smtp_banner = $smtp_active_hostname ESMTP Exim


I’m not very sure… but I think banner takes in name from /etc/mailname.
What you want is probably customisable using “routers” in the exim conf but those are very complicated things.

/etc/mailname is used for local delivery, for simple stuff such as sendmail from shell. :slight_smile:
Exim doesn’t care about it.
Should be quite simple really, If only I’d know how to read the IP address (or a domain) that was used to connect to the server.
Maybe it’s a question for Exim forum, but HestiaCP would definately benefit if such configuration is provided out of the box, just like it did with outbound IP switch mechanism.

The ip used for incoming tcp connections is stored in $received_ip_address, for more details search for it here

Something like this might be what you want:

smtp_active_hostname = ${if eq{$received_ip_address}{}{mail.mydomain.tld}}

(add it before ACL section in /etc/exim4.conf.template)


Works beautifully! Thank you!

As I have multiple IP’s I created a file “ipdomains” within /etc/exim4 containing IP:mail.domain.pairs, then added:

smtp_active_hostname = ${lookup{$received_ip_address}lsearch{/etc/exim4/ipdomains}{$value}}

to exim4.conf.template.

I’m curious, did this change improve your email deliverability?

Well, if all your IP addressees have a good reputation, no. There is no improvement in doing this.

However, this addresses a different issue, that may have a big impact.

By doing this, I’m making sure the primary IP address of the server is not mentioned in the header “Received: from” of e-mails my clients send, thus, I’m mitigating a risk of my primary mail server IP being blacklisted in case a client does something stupid, like forward their mail (including incoming spam), creates unprotected web form, or goes overboard by sending numerous e-mails without making sure their IP reputation can take it, to g-mail, y g-mail wannabe or worse of all outl00k who will in a second blacklist any IP suspected of being a spam relay.

After this change, any stupid thing my client does affects only his IP, so my behaving clients on shared plans will not suffer a poor deliverability a blacklisting of main server can cause.

I don’t even mind blacklists. If you do something stupid, suffer. But did you ever try to fix poor deliverability issues to outl00k and affiliated services? It’s a nightmare!
First they point you to oriffice365 IP delist, then, they ask you to send a ticket to each of their services deliverability support, then they ask you to join their Junk Email something program, then their something, something Services Program. Weeks of costly fun.

The worst thing is, they act as they are solution to the spam problem, when in fact, they, as a free(mium) provider are a largest part of the cause. Funniest thing is, most of the e-mails from their support ended up in my spam folder, and I use only out of the box SA config. Poor incompetent arrogant bastards are lucky they have all the money Bill made, because if they were a startup, they would have died in a first year.

In a nutshell, SPF, DKIM and DMARC are most important. Hell. I even implemented f…in’ BIMI, although I’m all against it, as it will only benefit large corporations and will have little to no effect in real spam prevention.
But that’s all just your basic server hygiene. Everything about deliverability is REPUTATION, and this single config line is just one of the numerous attempts I make to build and keep it.

Sorry the answer turned into a rant, but I drink on Sundays, and as I forbid myself the access to my servers and social accounts during Sunday evenings, I just couldn’t help myself, and shared thse ramblings with you guys. :slight_smile:



Something has changed.
I didn’t notice it before because I kept main hostname in all SPF records, so there was no panic, but there is a new helo_data setting under transports that puts hostname to helo message and from header.

So employed the same technique. Created domain: mailserver pairs file “/etc/exim4/domainmailservers” for all domains with own IP’s and PTR’s poining to their mailservers and made helo_data look there.

helo_data = ${lookup{$sender_address_domain}lsearch*{/etc/exim4/domainmailservers}{$value}}


And this was a really bad Idea, because I ended up on CBL blacklist with explanation:

This IP is impersonating (via SMTP HELO command) being a domain we know it cannot be. No properly configured mail server does this under any circumstances.

So don’t do this at home under any circumstances. :slight_smile: