DirectAdmin 1.676

[Swift-AU]

I note that after the update to Dovecot 2.4, /etc/pam.d/dovecot was missing on my system, meaning that people who were accessing POP accounts belonging to usernames (as opposed to virtual email addresses) could not authenticate. I had to recreate it myself to restore previous functionality.

 

[Ohm J]

Dovecot fail to start

/etc/dovecot/conf/ssl.conf line 7: ssl_server_prefer_ciphers: Invalid value: yes

Confirm error,

with DA conf "ssl_configuration=old"

Solved Thread 'ssl_configuration=old causing dovecot crash'

Mar 7, 2025

Hello all,

Just a quick note, if you use the DirectAdmin setting:

ssl_configuration=old

it will add the line:

ssl_server_prefer_ciphers=yes

in:
/etc/dovecot/conf/ssl.conf

and prevent dovecot from starting..
as far as i can tell, the values for 'ssl_server_prefer_ciphers' should be 'client' (preferred) or 'server', not 'yes'

i set ssl_configuration to intermediate and that line no longer appears, and dovecot is happy again..
However, it could be a problem for people who need ssl_configuration set to old..
if that's the case, maybe override the value in...

• petersconsult
• Replies: 0
• Forum: General Technical Discussion & Troubleshooting

• 

 

[Driesp]

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

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:

sed -i '/^AUTH_ENABLE_CONDITION /d' /etc/exim.variables.conf.custom
da build exim_conf

I was actually looking for it this week.
We will have to contact our clients before we do this upgrade or activate this security feature.
Thank you for keep improving the security.

Kind regards
Dries

 

[fln]

A new release is made with the following fixes:

• Make sure Dovecot 2.4 works in the ssl_configuration=old mode, thanks @petersconsult and @Ohm J
• Create Dovecot PAM configuration for RHEL systems (Debian systems works without explicit config), thanks @Swift-AU

 

[vinao]

Hello
Today there was an update to dovecot.conf 0.5

Will it be necessary to allow the old authentication policy again after this update?

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

(too many clients use this option to change it immediately)

 

[fln]

@vinao, no the file /etc/exim.variables.conf.custom is never touched by DirectAdmin. If you have set custom variable there (custom SMTP auth policy) it will stay like this until you manually remove it.

 

[fln]

A new build is released. It includes a fix for old subdomain configuration on servers where a maintenance task to update subdomains config were never executed. Thanks @Ohm J for reporting it.

 

[Richard G]

Create Dovecot PAM configuration for RHEL systems

Is this for older RHEL systems? I checked all our Alma 9 servers and none had a "dovecot" file in /etc/pamd.d and we do also use pop3.
Or is this used by system accounts not converted to virtual? Just curious.

 

[sparek]

In regards to SMTP forcing secure authentications, does this also apply for Dovecot's POP3 and IMAP? Seems it's rather pointless to force secure log ins with SMTP if POP3 and IMAP is still allowed to be insecure. I don't see any specific mentions of this in the changelog, but there's a lot going on with the Dovecot 2.4 upgrade, so maybe it's included there.

Also has any thought been put into the potential ramifications of new accounts setting up email accounts before there's been a chance for a secure certificate to be issued?

I have to defer a bit on this because I'm using my own self-developed certificate issuance system and not what's built-in to DirectAdmin, so I don't know exactly how DirectAdmin's certificate issuance system works. But, I presume there's a timer to check for if a user's domain name resolves to the server to issue a certificate. Certificates cannot be issued immediately because you never know when a new user will modify the nameservers for their domain to resolve to your server. You'd expect it to be pretty quick, but I've also seen it take multiple hours to multiple days for users to modify their nameservers. Of course, an email address is not going to do any good until the domain is resolving to the server - which would mean the nameservers have been modified. But there's always that brief period between the user modifying their nameservers and the domain starts resolving correctly and then another brief period before a secure certificate is automatically issued.

 

[fln]

@sparek, there are no changes in how IMAP and POP work in this release. Authentication in POP/IMAP can be performed over plain text. But we need to start somewhere.

We deliberately avoided adding any changes in Dovecot config as part of the migration from 2.3 to 2.4. The Dovecot 2.4 configuration is more flexible and would allow some config simplifications and improvements, but our goal was to keep the configs 1:1 semantically and structurally compatible (between 2.3 and 2.4) as much as possible. This is to make it easier for admins that have Dovecot customisations to port them to the 2.4 version. Bigger changes for Dovecot configs are postponed until the migration to 2.4 is finished.

---

@Richard G The auth driver was one of the things we could not keep compatible. Dovecot 2.3 used the shadow auth driver, but in Dovecot 2.4 it was replaced with the PAM auth driver. The PAM config for Dovecot is not needed for Dovecot 2.3. Yes, it is used for UNIX user password authentication.

---

Thanks to the prevalence and availability of free TLS certificates, using encryption always and everywhere is no longer a problem. There will always be non-standard configurations and problematic edge cases, but it is easier to look at the problem from the following perspective. Imagine a situation where a user is having problems with TLS certificates (for reasons beyond our control). Which outcome would be preferred:

• User just configures email client to use plain text. Everything works fine for the user. Even after a TLS certificate is issued, there is no mechanism to prompt the user to revisit his email configuration and upgrade to use encryption. His password can be passively sniffed at any time by anyone along the path from him to the DA server.
• Email does not work without encryption. The user is forced to pick one of:
  • Do not use email until the TLS certificate issue is resolved. The user is pressured to seek help from admin or others.
  • Use server host name. He could switch to using his domain once the TLS certificate is issued. Most likely he will not.
  • Use his domain name, but accept the invalid cert once (server host name certificate or self-signed certificate). Once the TLS certificate is issued, everything will work as expected.
  • Configure email with disabled cert validation (always accepting all certificates). The user will be vulnerable to active MITM attacks. At least the user is protected from passive sniffing.

In other words, having pressure on ironing out any automatic TLS issuance problems is preferred over using TLS issuance problems as a justification to compromise on security.

 

[zEitEr]

DirectAdmin 1.676

Quota warning configs might need to be updated per this docs: https://doc.dovecot.org/2.4.0/core/plugins/quota.html#quota-warning-scripts

Related:

- https://docs.directadmin.com/other-...ser-level.html#lmtp-quota-limit-notifications
- http://files.directadmin.com/services/all/91-quota-warning.conf

Meanwhile when tried the new config it reported 75 error:

Error: userdb: client doesn't have lookup permissions for this user: userdb uid (1065) doesn't match peer uid (8) (to bypass this check, set: service auth { unix_listener /var/run/dovecot/auth-userdb { mode=0777 } })

as of now it is:

# ls -al /var/run/dovecot/auth-userdb
srw-rw-rw- 1 dovecot root 0 Apr 24 11:22 /var/run/dovecot/auth-userdb

the error above fixed by (thanks to Kristian and his message #42):

service quota-warning {
  executable = script /usr/local/bin/dovecot-quota-warning.sh

  user = root
  unix_listener quota-warning {
    user = mail
    mode = 0660
  }
}

and still:

quota-warning: Fatal: master: service(quota-warning): child 1176063 returned error 75
auth([email protected],127.0.0.1,sasl:plain)<X8NSJYMzFp5/AAAB>: virtual_user: Password mismatch

and quota warnings can not be sent.

 

[wila]

Is there an easy way to check if any of my customers still use port 25, for example by grepping for it in the logs?
(I'll go have a look now myself, but figured that this might be useful anyways)

edit: Didn't see an obvious way to check for this in the logs, but hopefully there is a way.
Things I am also worried about besides customers are tools, such as backup scripts and other helpful scripts that are supposed to check things and now stop being able to report when things go bad. So I prefer to find where port 25 is used before turning it off and discover a foot gun later on.

 

[fln]

@wila The default Exim configuration does not log the incoming TCP port. Logging of incoming connection details can be enabled by customizing the /etc/exim.conf file and appending +incoming_interface to the log_selector field:

...
log_selector = \
  +incoming_interface \
...

In main Exim log file /var/log/exim/mainlog the log lines will have I={ip}:{port} section, authenticated connections will have P=esmtpa or P=esmtpsa (if encryption is used). Quick grep over the logs that used 25 port (with or without encryption) would be:

grep 'I=[^ ]*:25\s.*P=esmtps\?a' /var/log/exim/mainlog

---

Update:

All authenticated connections without encryption can be quickly grabbed with:

grep P=esmtpa /var/log/exim/mainlog | grep -F -v -e ' [::1] ' -e ' [127.0.0.1] '

This works with the default exim log, no changes to exim.conf needed.

 

[wila]

Brilliant!
Thanks @fln, much appreciated.

edit: the only missing note was that exim had to be restarted in order to read the updated exim.conf file, but that's kinda logical.
It works perfectly and I've already identified some port 25 users, thanks again!

 

[dkzr]

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.

For Debian/Ubuntu, this will result in a downgrade from ImageMagick7 to ImageMagick6. Any way to prevent this and keep an ability to keep ImageMagick up to date?

 

[fln]

For Debian/Ubuntu, this will result in a downgrade from ImageMagick7 to ImageMagick6. Any way to prevent this and keep an ability to keep ImageMagick up to date?

If custom ImageMagick7 is never removed (the command da build remove_imagemagick is never executed), the PHP extension will prefer the custom (non system) ImageMagic version.

This means existing servers can opt to not remove it. New servers will always use the ImageMagic that comes with the system unless custom version is manually installed in /usr/local/.... For standard web applications the version of ImageMagic library does not really matter that much.

Note: Debian 13 provides ImageMagic7.

 

[ccto]

May I know -
Is it still OK to run DirectAdmin 1.676 with Dovecot 2.3.21.1 (with 2.3 series Dovecot configuration) ?

(i.e. instead of Dovecot 2.4 yet)

Thank you.

 

[fln]

@ccto, yes DA is compatible with both versions. If you customize the Dovecot version to be 2.3.x, the CB and DA will create configs suitable for this version.

 

[fln]

A new build is released. This build fixes file upload errors in File Manager on systems that use ZFS. ZFS has limited support for modern Linux kernel fs features, so a backwards compatibility mode is added for ZFS.

 

[castris]

Support told me this discussion also relates to the message below, but I don't see any logic or the slightest hint that it has anything to do with the change made and what's being discussed here.

Am I mistaken or did I miss something?


> R1: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)