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.