Host impersonating domain name

[vmanojdhawan]

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 necessary changes, since server is not in my control.
pls suggest me what to do, how to overcome this problem

 

[Richard G]

since server is not in my control.

Sorry, but this says everything.
This is a support forum for admins and resellers. However, we can't give support to resellers, for things which need to be done on admin level.

You have to contact your host, the one who has control over the server, to fix this.

 

[mxroute]

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 necessary changes, since server is not in my control.
pls suggest me what to do, how to overcome this problem

Here's the scenario where this occurs most often:

I add mxroute.com as a domain on my DirectAdmin server. I have another server hosting the website for mxroute.com. That server is named "mxroute.com" in it's hostname. I set up my website to connect via SMTP to the DirectAdmin server to send email, my mxroute.com server connects to the DirectAdmin server and says "Hi, my name is mxroute.com." DirectAdmin server replies "No you're not, because I was told that I am mxroute.com, a user on my server added the domain themselves!" That translates loosely to "550 Bad HELO - Host impersonating domain name."

Either the root user on the DA server needs to comment out the ACL in exim.conf (which will be replaced on every update) or you should rename your webserver from domain.com to something like "server.domain.com" instead. You can still host your website there, but the server needs to announce itself as something different when speaking over SMTP. For example, on many systems, that could be as simple as running this:

hostnamectl set-hostname server.example.com

Or even just replacing the contents of /etc/mailname.

 

[Richard G]

Which all can't be done without admin/root access which he hasn't.

 

[DirectAdmin Support]

I've pushed exim.conf 4.5.29, which removes this HELO check. To update:

cd /usr/local/directadmin/custombuild
./build update
./build exim_conf

(assuming your mirrors has been updated, else wait longer)
We've had a few reports of things like a remote WordPress install sending via smtp using "domain.com" as the HELO name, where WP is hosted on domain.com, but the email is hosted remotely, thus the WP block. The check is not always correct to enforce, hence Sayōnara chekku.


I've left the code, but simply commented it out in the acl_check_helo section so it will have no effect,
but if you DO want to still have it, then you can re-add it by creating

/etc/exim.acl_check_helo.pre.conf

and add code:

  accept  hosts = <;; @[]; 127.0.0.0/8 ; ::1 ; @
  accept  hosts = +whitelist_hosts_ip
          logwrite = acl_check_helo: $sender_host_address whitelisted in local hosts IP whitelist

   deny message = HELO_HOST_IMPERSANATION
     condition = ${if or { \
                           {eq{$sender_helo_name}{$smtp_active_hostname}} \
                           {eq{$sender_helo_name}{[$interface_address]}} \
                         } {true}{false} }

and you're back in business.[/code]I've included an extra whitelist bit, as you may want to have the check, but allow some exceptions via the /etc/virtual/whitelist_host_ip file, so this allows for that.

John

 

[k1l0b1t]

I came upon this thread after updating to this new version:
it broke my mail server (could not connect) (fixed now, by restoring backup of the vps I'm running on)

is anyone else having this after the exim.conf update?

 

[Richard G]

I didn't at least, but I instantly put back the old situation before updating. Because often we have spammers abusing it this way. Also today again I've seen a "host impersonating domain" which were again Chinese spamers.

Have you tried building exim and exim.conf again? And set fastest to be sure?

cd /usr/local/directadmin/custombuild
./build set fastest
./build update
./build exim
./build exim_conf

 

[Richard G]

@DirectAdmin Support bug with your solution.

We wanted to have that protection the old way, because as stated some spammers always try to use the domain name or hostname.

We used the solution presented to keep the helo check, but something is missing. Because now on all servers, webmail is not working anymore. Giving a 550 connection failed.
And when looking in the logs, it says:

2020-09-10 21:41:45 H=localhost (server.domain.com) [127.0.0.1] rejected EHLO or HELO server24.domain.com: Bad HELO - Host impersonating hostname [server.domain.com]

This did not happen with the old exim.conf with helo check, so something with the code is off.

I could ofcourse whitelist the hostname, but this should normally not be necessary.

 

[Richard G]

Addition: adding the server's hostname or ip to the whitelist does -not- solve the problem.

Edit: I'm just wondering. Wouldn't it be better the leave default things default and only change external things if needed?
Like put back the original exim.conf file and people who don't want the default helo check use a seperate file for it? Makes more sense to me.

 

[DirectAdmin Support]

For the re-add code, I found it was missing this line at the top, because exim.acl_helo.pre.conf was run BEFORE the localhost check which should have accepted it first.

accept  hosts = <;; @[]; 127.0.0.0/8 ; ::1 ; @

Sorry about that.

Regarding having it there by default, I'm open to discussion, whatever is most desired, we'll do

1. With it there, it blocks fake HELO spammers, but also blocks valid smtp deliveries that claim to be local.
2. Without it, the inverse: smtp deliverises work, but it one less block for spammers.

One could argue that with #1, the smtp deliveries are making "incorrect" claims about who they are, as 2 boxes shouldn't both have the same HELO, in which case the whitelist would be needed.

Option #3 might be to re-add the original code, but include the whitelist_host_ip 'accept', making it much simpler to allow this "incorrect" HELO for the #1 case.

So choices would be 1+3, or 2.

John

 

[Richard G]

Thank you for the code correction. However, isn't it odd that putting the server ip in the whitelist did have no effect?

Well I don't know how others think, but personally I opt for default things, not strange things. So using external mailserver is something external, so strange. This is agreeing with the argument that 2 boxes shouldn't have the same helo.
And mostly also wordpress sites are run on localhost if I'm correct.

So my choice would be back to original with a whitelist for external boxes/mailservers/domain parts. So that would be 1+3.
@bdacus01 What would you choose?

 

[DirectAdmin Support]

The whitelist isn't checked until after the HELO is done, so 4.5.29 and older would not be exempt from helo checks.
I've added whitelist code to the acl_check_helo for the next push to fix that, but will wait for more feedback on which state it should be. With all of the above, I'm now leaning towards 1+3 as well so far with the whitelist being respected, but will wait for other votes.

 

[DirectAdmin Support]

ESF 4.5.30 and ESF 1.32 are now up, availble for testing, but not yet in the versions.txt. For anyone who'd like to try them now, use

cd /usr/local/directadmin/custombuild
echo "exim_conf_45:4.5.30:" >> custom_versions.txt
echo "easy_spam_figther:1.32:" >> custom_versions.txt
./build exim_conf

and once fully released, or you wish to undo the custom change, delete the custom_versions.txt.

I'll let this simmer for a day to allow for some testing.
Changes listed in the 4.5.30 section here:

Index of /services/SpamBlocker

John

 

[Richard G]

Thank you John.

I found some typo in the given code.

easy_spam_figther:1.32: >> custom_versions.txt

should be

echo "easy_spam_figther:1.32:" >> custom_versions.txt

I installed it this way and have a look if things keep working. I don't use the whitelist.

 

[factor]

removes this HELO check

Why do we want to remove this? Doesn't seem like we would.

the email is hosted remotely

Why should some remote servers effect the Native System?

I've left the code, but simply commented it out in the acl_check_helo section so it will have no effect,
but if you DO want to still have it, then you can re-add it by creating

Seems like it should be the opposite. Let the folks using remote email comment it out. Are we saying more people don't use email in DA?

I opt for default things,

Me to.

So my choice would be back to original with a whitelist for external boxes/mailservers/domain parts. So that would be 1+3.
@bdacus01 What would you choose?

Back to original.
Let the ones that have Remote mail comment it out.

Hope that helps

 

[smtalk]

Why do we want to remove this?

Let's say you host yourdomain.com on server A, and you host mail of yourdomain.com on server B (MX records point there). You try to send an email to your domain (for example, contact submission form on the webpage), PHP mail script sends HELO with yourdomain.com to your server B (DA), and it refuses to accept your mail.

That's one of possible scenarios

Let the folks using remote email comment it out. Are we saying more people don't use email in DA?

rspamd, easy spam fighter or spamassassin should be used for the spam control, if they don't solve spam cases well - default settings could be adjusted.

 

[factor]

you host mail of yourdomain.com on server B

By default, DA doesn't do this. Not saying it can't. When you run setup it builds exim on server A. Allowing someone to choose to handle mail outside of server A is fine but not the default.

rspamd, easy spam fighter or spamassassin should be used for the spam control, if they don't solve spam cases well - default settings could be adjusted.

Are you saying Exim can't fight spam or shouldn't fight spam?

default settings could be adjusted

Right, I think my suggestion is the default setting should lean towards the Native install scenario. Not the hybrid server a and b scenario.

 

[smtalk]

By default, DA doesn't do this.

It's just a matter of "Use this server to handle my e-mails. If not, change the MX records and uncheck this option." checkbox in MX Records page on the server hosting the website. Please note the website could also be hosted in another hosting provider (using a totally different panel), and it'd still have this problem if they try to mail their DA server from there. DA has email-only feature set, and it's quite popular to host only email accounts there

Are you saying Exim can't fight spam or shouldn't fight spam?

No, I'm just saying there are other ways to stop the spam if there is any increase in unsolicited emails after this change. It is still a discussion though.

 

[Richard G]

Ofcourse there are other ways to fight spam, but the default helo check is a nice addition which would fall away in benefit of something undefault which probably most hosters don't use. Or has to be reverted by an extra manual made file.
So I would like to see a real good argument to make a change, instead of opting for the default with a whitelist option for domains who do it the external way, so 1+3.
I didn't see a real good argument for option 2 yet, so for changing default good working things.
Imho if people want to do the special things, have them create the extra file or do the extra effort.

 

[factor]

It's just a matter of "Use this server to handle my e-mails. If not, change the MX records and uncheck this option." checkbox in MX Records page on the server hosting the website.

Yes, but you don't seem to be getting my point. All the things you keep pointing out are the Non Default setup. If admins want to uncheck that box it means they want the Non-Default standard way of processing SMTP natively in Directadmin.

DA has email-only feature set, and it's quite popular to host only email accounts

I haven't seen any documentation on setting up an email only server.

there are other ways to stop the spam

Are those other ways native and installed by default to help replace the feature.

I guess what I am saying is if you have 100 DA installs. What percent uses more of an out of the box default setup? 80 or 90% maybe 10 or 20% are some other Email only or super custom remote setup aka remote email, db ect..

The out of the box install should match the 90%.

Like what I said about Https it should be the standard

A few weeks in with DirectAdmin and my thoughts

A few weeks in with DirectAdmin and my thoughts. I haven’t discovered everything. DirectAdmin at its core is great piece of software. These of course are MHO. They are also generalities. Note: I am not looking for a debate. I am simply a Client voicing his opinion. I am not mad or angry...

forum.directadmin.com

Certain features not standard: In the ever-changing landscape that is Information technology. Certain “features” (directadmin.conf) should follow the 80 20 rule. All of these seem to be documented in https://help.directadmin.com Here is what I mean.

10 years ago https:// wasn’t the 80% it was 20% now it’s the standard. SSL should just be built in and work by default. Failing only because DNS was wrong or it just couldn’t issue. The system should just set a letsencrypt cert on the server out of the gate. The 20% should be set ssl=0 and turn it off. This goes back to the directadmin.conf issue.