DirectAdmin 1.703

fln · Monday at 3:20 AM

We are happy to announce the release of DirectAdmin 1.703.

A full release change log is here:

DirectAdmin 1.703

The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!

JosKlever · Monday at 5:32 AM

This is not something from this update, but I've seen it with some previous updates as well. When updating software via CustomBuild, I see a lot of deprecated warnings, like:

Code:

mysql: Deprecated program name. It will be removed in a future release, use '/usr/local/mariadb-11.4.11-7VPi/bin/mariadb' instead
/usr/local/mysql/bin/mysqldump: Deprecated program name. It will be removed in a future release, use '/usr/local/mariadb-11.4.11-7VPi/bin/mariadb-dump' instead

And on another server it's like:

Code:

/usr/bin/mysqldump: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb-dump' instead

And more of similar lines. Can this be fixed?

Richard G · Monday at 8:24 AM

I'm very curious how that new Exim configuration will be working. Looks very good, Exim won't be talking outgoing to other mailservers on port 25 anymore. Seems a great idea.
Just wondering about scripts (so unauthenticated e-mail) which use php mail() but if I'm correct they are not using Exim but sendmail or something similar, right?

JosKlever · Monday at 8:28 AM

Richard G said:
I'm very curious how that new Exim configuration will be working. Looks very good, Exim won't be talking outgoing to other mailservers on port 25 anymore. Seems a great idea.
Just wondering about scripts (so unauthenticated e-mail) which use php mail() but if I'm correct they are not using Exim but sendmail or something similar, right?

I can confirm that the websites on my servers can still send emails via PHP mail, so that should be okay.

AlexanderNL · Tuesday at 7:59 AM

Since version 1.702, SpamAssin puts a username in the place where the spam score normally appears.
I think its now solved?
The fill in is from Lastpass and before was there problem.

LawsHosting · Tuesday at 10:19 AM

AlexanderNL said:
Since version 1.702, SpamAssin puts a username in the place where the spam score normally appears.

Either you're seeing something cached, or it's still a LastPass issue. I'm not seeing this.

kristian · Wednesday at 2:16 AM

Accounts using a certain package (with limited access) when going into Account Manager -> SSL Certificates, are now getting this message:

SSL Certificates
Unable to retrieve data due to the following reason: "Access Denied". Click "Retry" to try again.

The access log reveals this 403:

Code:

2026-06-03T10:12:16+02:00 0.001 185.114.57.222 403 24 GET /api/domain-tls/<domain>/certs https://<server>:2222/evo/ssl admin|<username> session-native -

What do I need to add to my feature set's commands.allow for this to work?

fln · Wednesday at 2:20 AM

@kristian, yes. Thanks for bringing this up. The page now uses domain-tls command. We will add automatic migration for login-keys and feature sets. If user had access to CMD_SSL command he should also be able to access domain-tls.

kristian · Wednesday at 2:51 AM

Automatic migration is fine, but I update my feature sets using ansible, so any migration you do will be removed next time I run ansible, unless I too have added the new access. I can do that, but I would need to read about it in the changelog first.

Can confirm that adding domain-tls to commands.allow solves the problem.

ju5t · 2026-06-04T14:20:56-0600

Hoping to get your opinion on this @fln, but could you share the cases you've seen where turning off `FORCED_MX_DNS_CHECK` makes sense?

fln · 2026-06-05T02:47:41-0600

@ju5t, it is just an option to restore backwards compatibility for unusual or highly customised email routing. The default forced MX check rule could cause problems if Exim receives emails that should be delivered locally from an external server over an authenticated SMTP session and MX records do not point to the Exim server.

MX records not pointing to the Exim server can happen if all incoming emails are routed through a proxy mail checking service. The mail checking service forwards the emails to Exim. If forwarding happens without authentication, Exim will accept the email and deliver it to the local mailbox. If the forwarding service were to use an authenticated SMTP session, then Exim would assume this is an outgoing email from a local client. Exim would look up the MX records and deliver the email back to the mail checking service (because MX points to it). The mail checking service would try sending the email back to Exim, thus creating a routing loop.

This is a hypothetical situation because there is no reason for the mail checking service (that collects mails from the Internet) to use SMTP authentication when delivering them to Exim.

DirectAdmin 1.703

fln

Administrator