DirectAdmin 1.680

The new Exim setting is affecting to MDaemon usage. For example, we have some customers using one email account for authenticating for all outgoing emails. So, the email for authentication is different than the email in FROM field. With this type of customers, the new ACL will stop all outgoing emails.

Putting the setting "AUTH_BLOCK_SENDER_SPOOFING = no" into /etc/exim.variables.conf.custom will change the whole server. Is there any way to use it for a specific domain in the system?
Yep, this logics still weird. Workaround by using the main account authentication, but this will be security issued and shouldn't use from any 3rd party app.

If the main account ( without @domain ) can use to sproof any "{sender}@user_domain", then any sub email account must can sproof the "{sender}" with same "@domain" authentication too.
 
The server running version 1.680 is currently experiencing an issue where the default sorting in the File Manager is set to Permissions and cannot be changed back to the previous behavior as in version 1.679. I have checked other servers still using version 1.679 with the Evolution skin, and they display the file list normally — sorted by name by default. This issue affects all users, not just a specific account.
Could this be a problem introduced with the latest update? It seems the recent change in the "New File Manager's files and folders table design evolution" might have affected the default sorting behavior.
It is really not clear how to re-create such situation like you have, because FM does not allow to sort files/folders using "Permissions" column.
Please create support ticket and provide us all details with all steps (including browser you use) how to reproduce that problem.
 
Hi Romans,
Just using any system using Directadmin with 1.68 and login with user , then login File Manager, and see any thing about like attachment i was send before
 
After a downgrade from apache 2.4.64 to 24.63 the error was over.
Thanks! This helped me for now.
Have same issue like HageHosting, think there should be a warning or simple script added by DA if update affects config files in such way in future.

This works form me:
I totally agree with you. I thought it was a regular update until I see the notifications of Uptime Monitor saying that all of my sites are down. This could be prevented. I'm in a hurry so I couldn't use your script but thank you so much for it. I hope DA will fix this issue, until the next update I'm holding the apache update. I reverted back to 2.4.63

Edit: I just updated my customs, everything seems fine now.
 
Last edited:
Yep, this logics still weird. Workaround by using the main account authentication, but this will be security issued and shouldn't use from any 3rd party app.

If the main account ( without @domain ) can use to sproof any "{sender}@user_domain", then any sub email account must can sproof the "{sender}" with same "@domain" authentication too.
I would just disable this completely on the server. I mean, everything worked prior to this addition with this update. If an email account's authentication data is compromised all this does is prevent the sending out of mail through the server unless it uses the same email account as it's envelope-sender. It does nothing to rectify the main issue... that the email account's authentication data was compromised.

This, to me, is more of a solution in search of a problem. That's why I'm not a big fan of this. But... at least DirectAdmin provides a means to disable this.
 
The Apache 421 issue is fairly widespread.

We don't use nginx or custom scripts and we are showing sites with the error. Most appear to be CloudFlare hosted, another was a monitor that wasn't passing SNI.

I've downgraded till I can run more tests in lab.
 
The server running version 1.680 is currently experiencing an issue where the default sorting in the File Manager is set to Permissions and cannot be changed back to the previous behavior as in version 1.679. I have checked other servers still using version 1.679 with the Evolution skin, and they display the file list normally — sorted by name by default. This issue affects all users, not just a specific account.
Could this be a problem introduced with the latest update? It seems the recent change in the "New File Manager's files and folders table design evolution" might have affected the default sorting behavior.
I have checked again and found that the issue was due to using an older version of Chrome (v118.x). This likely caused the incorrect display behavior shown in the attached screenshot.


After updating to the latest version (v138.x), the issue no longer appears.
 
I would like to know what changes were made to the Exim configuration in version 4.5.57, so that I can check this before updating. Previously, it was possible to access the data via the following link: https://files.directadmin.com/. Is this no longer possible?
 
For us, this update broke 2 critical services on our DirectAdmin servers…

1. It broke assets loaded by CDN (421 Misdirected Request error) because of Apache v2.4.64 (we don't use NGINX proxy, but websites using CDN were impacted).
It took to us half a day for 2 people to figure out what happened, as we are not familiar with panel auto-updates breaking such things.
Regarding this Apache issue, will a fix be automatically pushed in the next update? Or should we stay on version 2.4.63 while waiting to understand how to implement that workaround? (It's not clear to us, as we don't have NGINX proxy (only Apache with mod_lsapi), so we don't really know what to do with Apache 2.4.64.) ?

(Any help appreciated! thanks) (?)

2. It broke mail sent by several CMS, like Blesta or SMF (forum), with a 550 error on SMTP because of AUTH_BLOCK_SENDER_SPOOFING automatically set to "yes", changing the previous behavior. We lost at least three days of outgoing mail for several purposes.
It would be appreciated if such critical behavior changes were not made without notice and clear information. For example, when critical feature updates are applied automatically in cPanel, a big screen appears upon first logging into WHM, announcing "What's new?". Users must then choose to "Enable or Not Enable" some features via this screen.

Just my feedback. Thanks!

P.S. (edit) : btw, I've just switched our "Update channels" from "current" to “stable” to avoid this kind of problem as much as possible for next auto updates.
 
Last edited:
For us, this update broke 2 critical services on our DirectAdmin servers…

1. It broke assets loaded by CDN (421 Misdirected Request error) because of Apache v2.4.64 (we don't use NGINX proxy, but websites using CDN were impacted).
It took to us half a day for 2 people to figure out what happened, as we are not familiar with panel auto-updates breaking such things.
Regarding this Apache issue, will a fix be automatically pushed in the next update? Or should we stay on version 2.4.63 while waiting to understand how to implement that workaround? (It's not clear to us, as we don't have NGINX proxy (only Apache with mod_lsapi), so we don't really know what to do with Apache 2.4.64.) ?

(Any help appreciated! thanks) (?)

2. It broke mail sent by several CMS, like Blesta or SMF (forum), with a 550 error on SMTP because of AUTH_BLOCK_SENDER_SPOOFING automatically set to "yes", changing the previous behavior. We lost at least three days of outgoing mail for several purposes.
It would be appreciated if such critical behavior changes were not made without notice and clear information. For example, when critical feature updates are applied automatically in cPanel, a big screen appears upon first logging into WHM, announcing "What's new?". Users must then choose to "Enable or Not Enable" some features via this screen.

Just my feedback. Thanks!

P.S. (edit) : btw, I've just switched our "Update channels" from "current" to “stable” to avoid this kind of problem as much as possible for next auto updates.

What CDN are you using? It is likely that CDN is not yet compatible with apache 2.4.64

Security fixes included in apache 2.4.64 changed its behavior a bit, our findings show that for SSL requests, TLS SNI extension is now mandatory, otherwise 421 Misdirected Request error is returned.
 
@nlaruelle

nginx_apache, cloudflare CDN working fine. And yes that issued need to resolves from CDN provider. Or workaround by just switch to "nginx_apache".


I don't have any test box for pure "Apache" only, so goodluck.
 
@Ohm J @sewiti thanks !

We had to revert the AUTH_BLOCK_SENDER_SPOOFING setting back to "no" after discovering that the update broke email functionality in Blesta and SMF CMS. We don’t want this kind of issue affecting our users, especially considering the wide variety of other CMS platforms they use—many of which we’re not even aware of.

Regarding the CDN, we personally use Bunny.net—it’s not the worst, I guess?

Similarly, our end-users rely on many different CDNs, so we prefer not to enforce an Apache version with overly strict early-stage restrictions that could impact their services. Backward compatibility is important in the context of reselling web hosting, which is why we still offer PHP 7.4 to our users.

As for nginx_apache, we’re looking forward to taking advantage of it, but unfortunately, it’s not compatible with the security suite we pay for (Imunify360). I must admit, CloudLinux should really make more of an effort to support DirectAdmin the same way they do for cPanel—especially since we’re paying the same price for both.

So, we must to be stuck at the 2.4.63 version, waiting the world adapt themselves to this new TLS/SNI restriction or I did not understand what to do next ?

Thanks again !
 
Continuing from what @nlaruelle mentioned above, I updated DirectAdmin and Exim yesterday on a server that doesn't host any clients, and only today we realized that our WHMCS also stopped sending emails.

In WHMCS, if you configure the global email as "[email protected]", set "[email protected]" for invoices, and "[email protected]" for support, all the emails are simply ignored.

As with other Exim-related changes in DirectAdmin, this one also had to be disabled (AUTH_BLOCK_SENDER_SPOOFING = no). On a production server with hundreds of users, there’s no way we can keep this enabled permanently.
It may be an additional layer of protection, but for us as server administrators, it only creates more problems.
 
broke email functionality in Blesta and SMF
If I read this, and the post of @paulonichio then I start to wonder if this would also affect other forum software like phpBB and Xenforo for example especially with XF bounce functionallity.
So I think for the time being I will disable that sender spoofing too for the time being until things are more clear about it's effects on CMS/forums.
 
Back
Top