DirectAdmin 1.680

[Ohm J]

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.

 

[romans]

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.

 

[thuanduongpa]

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

 

[altayevrim]

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.

 

[sparek]

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.

 

[kevinb]

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.

 

[thuanduongpa]

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.

 

[Rolf B]

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?

 

[nlaruelle]

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.

 

[sewiti]

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?

You can explore and customize exim configuration in /usr/local/directadmin/custombuild/configure/exim, for more info see https://docs.directadmin.com/custombuild/customize-everything.html

 

[sewiti]

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.

 

[Ohm J]

@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.

 

[nlaruelle]

@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 !

 

[paulonichio]

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.

 

[Richard G]

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.

 

[gate2vn]

In Email Accounts section, if I created 500 accounts already, the Create Account button disappears, even the limitation of the DA account is 650. Needed to increase that limitation to have the Create Account button coming back. Can you check and verify the bug, please?

 

[romans]

In Email Accounts section, if I created 500 accounts already, the Create Account button disappears, even the limitation of the DA account is 650. Needed to increase that limitation to have the Create Account button coming back. Can you check and verify the bug, please?

I was not able to reproduce the issue neither in Evolution nor in Enhanced skin. "Create Account" button is still available after the first 500 mailboxes were created.
If there are more details with exact steps how it can be reproduced (including specific browser), please create support ticket and we will try checking it closer.

 

[smtalk]

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.

I don't think it has anything to do with CMS If you authenticate as [email protected] in CMS and send using SMTP, but you try to send as [email protected] - you cannot do this with the protection on, unless you add [email protected] as a forwarder of [email protected], or you make [email protected] a catch-all address.

Earlier users could easily spoof the sender, for example, if I had martynas@ mailbox, I could send from richard@, and all SPF/DKIM etc. would match, thus the receiver wouldn't know that it was not sent by richard@.

 

[Richard G]

I don't think it has anything to do with CMS

Not in base. But in configuration by the user of the CMS. In some you can use multiple names for example admin@ and webmaster@ and if authenticated with webmaster, but that is only userd for the contact form and for e-mail verification they would use admin@ then this would already cause an issue with the protection on.
Same if they authenticate with their own account but send from noreply@ for example.

I just doublechecked with XenForo and in there one can use seperate smtp authentication for 3 difference mail accounts (including bounce account). However, I'm sure some will just fill in one because that's easier.
And since this protection is serverwide, I presume it can't be disabled for some useraccounts seperately. However we could teach our users to use the correct credentials.

Is there a specific error notice we can lookup in the Exim logs to see if users are affected when we have this on? Or will this just be "authentication error"?

 

[sparek]

Earlier users could easily spoof the sender, for example, if I had martynas@ mailbox, I could send from richard@, and all SPF/DKIM etc. would match, thus the receiver wouldn't know that it was not sent by richard@.

But SPF/DKIM/DMARC etc was never intended to have that much granularity. They were meant to be used to insure message from any @example.tld email address was coming from an authorized server.

I just think this implementation is a bad idea. But at least it can be disabled. I might encourage to have it disabled by default and have to be explicitly enabled.

I can't be the only person that sets up one [email protected] email account who's sole purpose is to be used in authentication to send out email. Then I can send out email from any @example.tld email address profile I have set up in my email client. This would break that set up. Technically it's true that authenticating as [email protected] would allow me to send email from ANY domain that is set up on the server. But I'd argue that there are so few and far between instances of that happening that it's not worth the effort to worry about. If someone is that paranoid about their email being used in this way, then they need to get a dedicated server or VPS. There's a reason shared web hosting is so cheap.

As I said, at least this option can be easily disabled so there's always that option. I just think you're going to get a lot of users who suddenly can't send out email because they or their server administrator just updated DirectAdmin without paying attention to the forums or changelogs.