DirectAdmin 1.676

fln

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,111
We are happy to announce the release of DirectAdmin 1.676.

This release has significant changes related to the email subsystem. The Dovecot (POP/IMAP server) version 2.4 is now used by default, Exim configuration uses more secure defaults for email submission, the daily per-mailbox email limit system is improved. There are also UI improvements for FileManager.

Note: The Exim configuration changes can cause extremely old email client configurations (that still use SMTP port 25 for email submission) to stop working. Updating email client configurations might take some time, so to help with the transition, there is an easy workaround to keep using the old configuration while clients are being reconfigured.

A full release change log is here:

DirectAdmin 1.676​

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!
 
Dovecot 2.4.x is supported by all types of DirectAdmin licenses (including the legacy licenses).
 
If you are using global sieve filters for Dovecot 2.3, do not forget to adjust the config file for version 2.4; otherwise, Dovecot will not start.
 
Today I updated dovecot, unfortunately after the update me and my clients have a problem with sending messages: autehentication required
can anyone help us?
 
@vinao if this happened after you have updated the Exim configuration using CustomBuild (da build exim_conf or via GUI), then this could mean one of the two things (or both of them):
  • Your clients using Thunderbird or Outlook were passing passwords over plain-text connection (not using encryption).
  • Your clients using Thunderbird or Outlook were using SMTP port 25 to send emails.
To fix the issue clients should update the email sending configuration by making sure they use encrypted connection when sending emails (use TCP port 587 or 465).

If there is a large number of clients that need to update their configuration you can allow using old insecure authentication policy with the commands listed in the change log.

Code: 
sed -i '/^AUTH_ENABLE_CONDITION /d' /etc/exim.variables.conf.custom
echo 'AUTH_ENABLE_CONDITION = yes' >> /etc/exim.variables.conf.custom
da build exim_conf

After all clients have updated their email applications to use encrypted connection you can switch to the default (secure) auth policy with commands:

Code: 
sed -i '/^AUTH_ENABLE_CONDITION /d' /etc/exim.variables.conf.custom
da build exim_conf
 
Last edited:
How about php mail() in various webscripts which do not send over authenticated SMTP? Are they now also blocked from sending mail? Because if I'm not mistaken they also use port 25.
 
Richard G said:
How about php mail() in various webscripts which do not send over authenticated SMTP? Are they now also blocked from sending mail? Because if I'm not mistaken they also use port 25.
Click to expand...
By default PHP mail() (on Linux anyway) uses a system call to sendmail to send out mail. This is handled within the Exim configuration in the not_smtp ACL. There is no TCP connection to the SMTP server.

Now if you are using PHPMailer or some other system that creates a TCP connection to the SMTP server, then you may run into issues with this new Exim configuration - if that TCP connection isn't using a secure port.
 
Never understood that you still allow PHP mailer at all. Here it has been blocked for years and everyone is forced to use SMTP via port 465
 
because if website get hacked, php mailer is much slower and the chance for me to catch it earlier is much higher. With full smtp-account, intruder can send many 1000s spams before it gets even noticed. with all following consequences.
 
So? It's a free choice like there are many different choices with hosters. We also still allow pop traffic via port 110.
Next to that, like @johannes said. And we have strict limits for php mail so we can catch it fast.
We also limit the SMTP authenticated traffic, but that is a lot higher than the php mail limit. We can always change things if run into issues but we hardly ever do.
But that's a different discussion, as said, everybody's own choice.
 
exlhost said:
How do we enable imagemagick now, Install from source?
Click to expand...
If PHP imagick plugin is enabled (php_imagick=yes in CB options.conf) then CB will install imagemagick from the system repos and will build the PHP extension.
 
johannes said:
.. sounds as it would break a lot of mailing plugins in diff. CMS..
Click to expand...
All scripts using SMTP are normal email clients, like the well-known desktop applications Outlook or Thunderbird. They all support using a submission port and encryption. Nevertheless, the configuration of such scripts will require an update if they were not using encryption (or were abusing the SMTP 25 port).

The real goal we are trying to achieve is to expose insecure configurations and create pressure to fix it. The old DA default configuration was okay in 2010 (before RFC 6409), but not anymore.

Note: if the script sending mail over SMTP is running on the same server, it can use plain text SMTP when connecting to localhost:587. There is an exception to not force encryption on localhost connections. If the script connects to the remote DA server, it will need to use encryption (well, unless an admin deliberately switches to a less secure SMTP auth policy).
 
That’s something for WordPress to implement properly imo. I’m all for pushing secure and modern configurations like this DA update. Up until the recent 6.8 they still used MD5 (now bcrypt) for passwords?!
 
You must log in or register to reply here.
Back
Top