Host impersonating domain name

[mohammad6006]

I use separate mail server to send emails
I have 2 domain set on the main server
when I try to send mail from first domain :

Expected response code 250 but got code "550", with message "550 Bad HELO - Host impersonating domain name [first-domain.com] "

but there is no problem with second-domain

I also don't have problem when I try to send via local host with mail server config

what should I check and change?
I don't know this problem related to my main server or Mail server

 

[mxroute]

This occurs when the connecting server issues a HELO statement which matches a domain in /etc/virtual. This shouldn't occur because people should be using FQDNs as server hostnames, but people don't, so you can just comment out the ACL in exim.conf. This is what you'll comment out:

    deny message = HELO_IS_LOCAL_DOMAIN
        condition = ${if match_domain{$sender_helo_name}{+local_domains}{true}{false}}
        hosts = ! +relay_hosts

In my professional opinion, this ACL only exists today either due to a failure to re-evaluate it, or a desire to troll people on using FQDNs as hostnames just so you can point and laugh at people and say "Ha you did it wrong." But it's still in there by default, doesn't seem to be going anywhere.

 

[Active8]

Found a post that can help other people
------------------------------------------------------
Hi i've faced the same problem, i've solved it by editing exim.conf in the mail server like this

just after #EDIT#16
hostlist relay_hosts = net-lsearch;/etc/virtual/pophost

i've added this line

hostlist allowed_helo = net-lsearch;/etc/virtual/allowed_helo

and changed #EDIT#25 from this

# deny if the HELO pretends to be one of the domains hosted on the server
deny message = HELO_IS_LOCAL_DOMAIN
condition = ${if match_domain{$sender_helo_name}{+local_domains}{true}{false}}
hosts = ! +relay_hosts
accept

to this

# deny if the HELO pretends to be one of the domains hosted on the server
deny message = HELO_IS_LOCAL_DOMAIN
condition = ${if match_domain{$sender_helo_name}{+local_domains}{true}{false}}
hosts = ! +relay_hosts
hosts = ! +allowed_helo
accept

finally i've added the first server ip in /etc/virtual/allowed_helo and restarted exim

 

[Richard G]

In my professional opinion, this ACL only exists today either due to a failure to re-evaluate it,

No it's still in there due to protest of some people, which I was one of. As we had a lot of spammers trying to use our servers using helo of domains on ours servers. So we neede that option. There was however no need to remove this. Imho it still exist to prevent spammers abuse the system by impersonating domain names.

As people having issues with this, can easily use one of the whitelist files like whitelist_hosts_ip for example.
This is also stated in the changelog to the 4.5.30 exim.conf file:

HELO check can now use whitelist_host_ip to skip the HELO impersonation check.

When you change the exim.conf this can be overwritten and you have to either chattr the exim.conf and work with old version, or make the changes every time. So that seems not the best thing to do.

Now the thread about this was this topic:

Host impersonating domain name

i just joined reseller ship of direct admin panels. all are working fine, but when i send mail from mail server it gives an error of "550 Bad HELO - Host impersonating domain name [domain name]. whatever solution was given by previous threads i could not get where to find exim.conf to do...

forum.directadmin.com

As you can see from post #5, DA changed it to remove that notice. However, it was luckily changed back afterwards.

You @mxroute even wrong a shell script for it:

Host impersonating domain name

Imho if people want to do the special things, have them create the extra file or do the extra effort. correct.

forum.directadmin.com

I'm not sure if this also may be catched or put in the whitelist via the /etc/exim.acl_check_helo.pre.conf file.

 

[mxroute]

No it's still in there due to protest of some people, which I was one of. As we had a lot of spammers trying to use our servers using helo of domains on ours servers. So we neede that option. There was however no need to remove this. Imho it still exist to prevent spammers abuse the system by impersonating domain names.

It's actually the only reason I have to replace exim.conf manually after every update, and why I'll have trouble if/when an update breaks syntax. If you ever lose that protest in the future, and I'm sorry but I kind of hope you do, give me a holler if you want me to script out that functionality for you in a way that exim updates won't overwrite. It's pretty easy. Much easier than reversing it out of exim.conf.

 

[Richard G]

and I'm sorry but I kind of hope you do

You don't need to be sorry about that. I will sure give you a holler if that would be the case as I understand your issue too ofcourse.
But as you could read, I'm a big proponant of leaving things as default as possible. And unfortunately, we still have issues with spammers trying this on regular base.

But it can't be that many servers connecting with the same domain, why not use the whitelist instead of overwriting exim.conf?

 

[twhiting9275]

This occurs when the connecting server issues a HELO statement which matches a domain in /etc/virtual.

There are, in fact, legitimate uses for this very thing. Unfortunately, as always, the vocal insist on things done improperly and breaking those.

Case in point:
I cannot send mail from wordpress , because of this.
My servers are properly setup and configured. Each have their own hostname, each has RDNS enabled. Each points to it's own IP address
The problem? I use ONE mail server for any number of domains. That's ALL that server is used for... MAIL

So, let's say I want to send mail from a wordpress website, using SMTP. Should be easy to do. I mean, the details are correct. Login is fine, and from any other pc, it works... Guess what though ? it DOESN'T work here, because of DA.

Yet another case of DA inserting itself where it shouldn't.

This is legitimate email, being blocked by trolls who "just don't like a setting some way"

Oh, and 'whitelist_host_ip' ??? Yeah, that doesn't work. It did , for the longest time, but stopped recently.

Again, there's nothing wrong with my FQDN, or my mailing setup. There is ABSOLUTELY something wrong with doing things this way though, blocking legitimate mail for literally no reason.

 

[Richard G]

There are, in fact, legitimate uses for this very thing.

There might be indeed. Normally it's an anti-spam option which is used and working fine. Still legitimate blocks a lot of them at our servers. So it really is a legitimate reason in spite of what you think.

The problem? I use ONE mail server for any number of domains. That's ALL that server is used for... MAIL

Yes even with this option deselected it can happen I understood.
Use this server to handle my emails.
Because in that case the domain should not be present in /etc/virtual/domains anymore and should not cause issues but still does for some reason.

You might want to have a look at this solution.

Host impersonating domain name

I use separate mail server to send emails I have 2 domain set on the main server when I try to send mail from first domain : Expected response code 250 but got code "550", with message "550 Bad HELO - Host impersonating domain name [first-domain.com] " but there is no problem with...

forum.directadmin.com

However.... maybe it's better to send in a ticket to investigate as to why the whitelist_host_ip is not working anymore.

 

[twhiting9275]

It really is a legitimate reason in spite of what you think.

No, it's really not.

This does nothing to block spam. It blocks legitimate usage, but doesn't block spam.

You want to block people trying to abuse that? Then put in a proper firewall. Institute proper password requirements. Simply blocking someone from trying to send legitimate mail is NOT the proper way to do things

 

[Richard G]

No, it's really not.

This does nothing to block spam.

It really is and it does block attempted spam. I can show you my logfiles about how many attempts I had of people trying to connect like this.
Having proper password requirements and a proper firewall, has nothing to do with it, I have all that. But that doesn't keep external users to try and login with an existing domain name.
It's used to bypasses anti-spam checks by pretending to be a legitimate domain hosted inside the server.
And maybe at some places it's not used often anymore, but we do have periods when we see loads of these attempts.
However, we probably will not agree about that, but I don't mind. The lets agree to disagree. I don't want to waste time with a discussion.

The blocking of legitimate mail this way when using a seperate server to handle all mail is a know issue with that, not only with DA.
Most do not use seperate mail server, so it just is the proper way to do things, because that's where the whitelisting is for. However whitelisting should be working.

I agree that a better solution might be created for situations with external mailservers, but you have to be with Exim for that. And I don't think they will make any effort because it's like that for years and there are several solutions to prevent it.

So I would suggest that you can either use on of the solutions or send in a ticket to fix the whitelist. Whatever you choose.

 

[mxroute]

There are, in fact, legitimate uses for this very thing. Unfortunately, as always, the vocal insist on things done improperly and breaking those.

Case in point:
I cannot send mail from wordpress , because of this.
My servers are properly setup and configured. Each have their own hostname, each has RDNS enabled. Each points to it's own IP address
The problem? I use ONE mail server for any number of domains. That's ALL that server is used for... MAIL

So, let's say I want to send mail from a wordpress website, using SMTP. Should be easy to do. I mean, the details are correct. Login is fine, and from any other pc, it works... Guess what though ? it DOESN'T work here, because of DA.

Yet another case of DA inserting itself where it shouldn't.

This is legitimate email, being blocked by trolls who "just don't like a setting some way"

Oh, and 'whitelist_host_ip' ??? Yeah, that doesn't work. It did , for the longest time, but stopped recently.

Again, there's nothing wrong with my FQDN, or my mailing setup. There is ABSOLUTELY something wrong with doing things this way though, blocking legitimate mail for literally no reason.

I'm in 100% agreement. Plenty of things stop spam, including powering off servers. But there has to be a line where you say "that isn't a reasonable solution because it breaks something legitimate." You having a cloud server named after your website which also sends mail to you at a DA box is a valid and common situation. But no one seems to be able to fathom the idea that a website might exist in the virtual domains file and also exist outside of that server. It can, and having to manually replace exim.conf on every update is an unreasonable solution to fixing it. At most this should be in an include file that is optional, not in exim.conf.

Even if whitelisting works, open relaying is far too high of a trust level to assign to fixing something that shouldn't be broken.

But I don't think about this anymore, feel free to use my scripts. https://github.com/mxroute/da_server_updates

Or use a WordPress SMTP plugin and use that DA server as your mail server on both ends. No you shouldn't have to, but it's fine to pick from working options and continue the protest.

 

[Richard G]

Even if whitelisting works, open relaying is far too high of a trust level to assign to fixing something that shouldn't be broken.

Agreed, but this is already the case for many years at lots of places so imho it's not caused by DA but by Exim right? So Exim should fix this, correct?

At most this should be in an include file that is optional, not in exim.conf.

+1 for that.

 

[mxroute]

Agreed, but this is already the case for many years at lots of places so imho it's not caused by DA but by Exim right? So Exim should fix this, correct?


+1 for that.

It's an ACL made by the DA devs, it's not default behavior.

 

[mxroute]

It's worth noting though that things like this aren't true:

"there's nothing wrong with my FQDN"

If that were correct, it would be highly unlikely for the server hostname to be in the virtual domains file on the DA box. A server's hostname is supposed to be a FQDN. For the layman, that means a subdomain. See here: https://en.m.wikipedia.org/wiki/Fully_qualified_domain_name

So if we play devil's advocate for a moment @twhiting9275 , we have to conclude that either you added the WP server's unique FQDN to the DA virtual domains file or more commonly, your server hostname is not an FQDN. I'll bet money on the latter because that describes 100% of scenarios I've witnessed. I'm not trying to provoke you or anything, I'm just being overly factual to take the devil's advocate hat on and off a couple of times.

But taking off the devil's advocate hat: Cloud providers often set hostnames as what customers fill in which is based on what the customer wants to see on their cloud panel, which is often just the single domain they intend to host on it. Expecting people to use an FQDN for their server hostname in 2023 is a lesson in wishful thinking or, at best, preaching at them for no reason. Thinking that people won't host email on DA and their website on another platform is ignoring all of the ways that real world clients upgrade their systems and migrate to limited platforms, often breaking up the email and web hosting in the process.

Root servers are now much more commonly in the hands of less experienced admins, and there's no shame in reducing friction for them from time to time. I don't like gatekeeping as a way to force people into submission to our old standards that aren't really relevant or important today.

I do agree though with using HELO blocks for spam/virus prevention. Just blocking ylmf-pc blocks a ton of them outright. I do see blocking HELO statements from the list of virtual domains as not being 100% without merit, but I usually find those just as easy to block by other conditions. Just blocking this ASN alone cuts out most of it: https://bgp.he.net/AS399471

So while I say "not without merit" I mean to say that it has value, but I still think the situation it breaks is of higher value than anything the ACL brings positively to the table.

 

[Richard G]

It's an ACL made by the DA devs, it's not default behavior.

Really? How come then I see this same issue almost everywhere on the internet, also not DA and almost always when the mail server used is on another server than the rest of the domain (c.q. only uses mail) when I read the answers.

If that were correct, it would be highly unlikely for the server hostname to be in the virtual domains file on the DA box.

??? The server's hostname in DA is always in the /etc/virtual/domains file, but not in the domainowners file. Always been like this in DA. I have that too and it really is a fqdn hostname like server.domain.com.
Or do you mean it should be removed from there if you don't use the local server as mailserver.

 

[mxroute]

Really? How come then I see this same issue almost everywhere on the internet, also not DA and almost always when the mail server used is on another server than the rest of the domain (c.q. only uses mail) when I read the answers.

I think you might be referring to a similar issue of those servers having a hostname that matches the incoming envelope sender domain. That would be different from the ACL this thread refers to. The ACL this thread refers to was definitely a DA addition.

??? The server's hostname in DA is always in the /etc/virtual/domains file, but not in the domainowners file. Always been like this in DA. I have that too and it really is a fqdn hostname like server.domain.com.

The hostname of your DA server sure. But let's say your DA server is directadmin.mydomain.tld, and you have domaina.com, domainb.com, and domainc.com configured as user domains on the server. Then you move domainb.com's website to a VPS that only hosts that domain, and you want your email to stay pointed to directadmin.mydomain.tld. Then your VPS might have a hostname of "domainb.com" which it uses by default to declare it's HELO statement, and then directadmin.mydomain.tld rejects a perfectly legitimate email from your VPS because it's HELO statement matched the entry "domainb.com" from /etc/virtual/domains.

 

[Richard G]

of those servers having a hostname that matches the incoming envelope sender domain.

No I Googled it this evening and also have seen this one, but also others were also responses where that this could be an issue when mailserver is external, even with other hostname.
However, if you say it's something DA did, and it's true, then they would better use a switchable external option for it and not an exim.conf setting as you said.

then your VPS might have a hostname of "domainb.com"

Ah that way... yes, but that's what I would call improper hostname configuration because that is not a FQDN hostname. So I don't find that only half legitimate because of faulty hostname configuration. I thought there was also something which blocked or at least gave a high spam sore when hostname was not FQDN, but I'm not sure anymore (memory leak).

But I understand what you mean. I'll try to keep out further so @twhiting9275 can be helped.