DirectAdmin 1.664

Thanks @exlhost for report. We are working on a solution as we speak, it will be released as a hotfix as soon as it's ready.
 
  • Like
Reactions: fln
An update with File Manager fix is released now.
 
@fln pointing your customers to a thread that's not monitored by any of you isn't the right way to handle this.

Adding this 'informational' message to pressure customers into an upgrade disgusts me. We do not use legacy licenses but there can be reasons why some still use them. It is not up to you to inform their customers as there is nothing wrong with these servers or the services provided by them.

We've been a customer for about 18 years now. Technically we have no reason to look elsewhere. But this is not how you treat your customers. It worries me a bit for what the future will hold.
 
A legacy license notice on the login screen is added to inform end users why not all features might be available or functional. It was deliberately designed to be:
  • Non-intrusive and blend it with the page design to avoid distracting users or grabbing attention.
  • Cleanly separated from the main login functionality to make it very easy to customize (or hidden).
  • Have a single location for this message (not individual messages for each skin, each layout, etc.).
Having a single message in a single well-known location helps us avoid documenting and repeating the same message in every place where legacy code-base functionality is limited or differs from the modern DA.

This message can be completely removed by adding a single rule in Customize Evolution Skin -> Login Customization -> Styles tab:

Code: 
.LegacyLicense {display: none !important;}

For a smooth DA experience we want the message to be visible to all the users (same as all the other informational texts in the UI). If server administrators disagree and want to hide this message it is entirely up to them. It is not our goal to make it hard or impossible (otherwise the implementation would be completely different).

We understand that the notice regarding limitations in our legacy products has caused concern. However, it is crucial for us to maintain transparency with all users (not just admins) who interact with our software daily. By clearly indicating the limitations of legacy licenses, we ensure that everybody is aware of the differences between these products and our more modern offerings. Without this transparency, less informed users (end-users) might assume such limitations are universal to DA instead of being caused by legacy licensing.
 
One more update is released with updated exim config. It adds a fallback to main server host name for null sender emails (bounces, or auto-replies) originating from unknown domain.
 
That has been discussed a lot when that was introduced. It's just hotfixes to v1.664. Hotfixes are not numbered, but referenced sometimes with the new build number
 
> Should be 1.666 or 1.664 hotfix 2

It's an update to the exim config and that was versioned. It shouldn't be called an hotfix, it doesn't affect DA itself.
 
In this version some changes were made to exim / hostname detection;

Version 1.664 | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com

This hotfix improvement builds upon that change if I read it correctly, so that's why there's no new number. That's how it's done since a few years
 
17c61f4b751f384cfcd44bb96d46714403697c41

export packages do not work (Icon grid / refreshed) I want to copy packeges to another server no popup appear I tested on 2 servers
 
@DanielP, please open a support ticket. Package import/export feature works fine on our test servers. It could be specific to the server configuration.
 
In the Security.txt Report, can you add a link to easily view the contents of the security.txt file? Now I need to manually browse to the file and I would like to quickly open/view it from the Security.txt Report.
 
One more update for DA 1.664 is released. It has an exim configuration update to keep using static HELO identifier. Dynamic HELO identifier helped reaching DMARC SPF alignment for emails with null sender, however it can cause problems with delivery to servers which prefer static HELO over DMARC SPF alignment. Based on operational experience it is better to keep it static.
Thanks for the suggestion @Erulezz, I will pass it to the dev team.
 
fln said:
One more update for DA 1.664 is released. It has an exim configuration update to keep using static HELO identifier. Dynamic HELO identifier helped reaching DMARC SPF alignment for emails with null sender, however it can cause problems with delivery to servers which prefer static HELO over DMARC SPF alignment. Based on operational experience it is better to keep it static.
Thanks for the suggestion @Erulezz, I will pass it to the dev team.
Click to expand...
Thanks for the update @fln

So is exim.conf 4.5.49 just a rollback to 4.5.47?
Are there any changelogs for the Exim/easy_spam_fighter/blockcracking configuration files? In the past there was a changelog at http://files.directadmin.com/services/SpamBlocker/4.5.x/, it was basic, but it was something.

It would be great if you could keep a detailed changelog, email is a critical area of hosting companies, and good documentation would help us all.

Regarding this change in the HELO identifier, could you please tell us in detail where problems occurred, which servers refused dynamic HELO? This will be useful for our email knowledge base. Thanks
 
unihostbrasil said:
So is exim.conf 4.5.49 just a rollback to 4.5.47?
Click to expand...
No, exim.conf still have changes to make sure null-sender emails would get DMARC alignment for DKIM. The part that was aligning SPF with the same domain as DKIM got reverted.

Trying to align same domain for both DKIM and SPF can cause problems when receiving server checks HELO identifier to have a valid PTR record (SPF uses HELO identifier for null sender emails). Some services (for example gmail) ignore the HELO identifier PTR lookup problems as long as DKIM and SPF aligns to the same domain because this is stronger proof of valid sender compared to just having valid PTR record. Other servers can refuse to accept email on HELO identifier PTR check failure without even checking for SPF and DKIM alignment.

In practice current configuration seems to be a good compromise to work with all the servers. We have DKIM alignment with the sender domain and SPF alignment with server host name. It is not the same domain (it is same domain for non null-sender emails) but it is still ok.

Exim config file version is being increased just to make sure CustomBuild knows there is the config needs updating. The changes are too small to deserve a separate change log entry. Entry DMARC alignment for auto-generated emails still captures the essence of it.
 
Thanks for the detailed explanation. In fact, the improvements in DKIM alignment brought a good result, as autoresponders often had problems with Gmail, for example. It's great that this change was kept. Thank you all for the good work!
 
#Modsecurity#
#url: :2222/evo/admin/modsecurity

Completely add rules and remove all disabled rules, result "/usr/local/directadmin/data/admin/modsecurity_rules" deleted.
Code: 
 nginx: [emerg] "modsecurity_rules_file" directive Failed to open the file: /usr/local/directadmin/data/admin/modsecurity_rules

Ensure, I don't have any customize on "/etc/nginx/nginx-modsecurity-enable.conf"
Code: 
# ls -l /usr/local/directadmin/custombuild/custom/nginx_reverse/conf
total 7
-rw-r--r-- 1 root root 948 Aug 14  2023 nginx.conf
-rw-r--r-- 1 root root  26 Dec 22  2019 nginx-events.conf

after all remove rules
#content: /etc/nginx/nginx-modsecurity-enable.conf
Code: 
# cat /etc/nginx/nginx-modsecurity-enable.conf
modsecurity on;
modsecurity_rules_file /etc/nginx/nginx-modsecurity.conf;
modsecurity_rules_file /usr/local/directadmin/data/admin/modsecurity_rules;
 
You must log in or register to reply here.
Back
Top