DirectAdmin 1.676

We're having issues right now.

We can't login to pop3 on port 110, not even if we have this in our exim.variables.conf.custom and rebuild exim.conf file.
AUTH_ENABLE_CONDITION = yes

What do we need to do so smtp on port 25 is blocked, but plaintext authentication is allowed on port 587 and also for pop3 on port 110 so the old ports.

Before we had this line:
echo 'AUTH_ENABLE_CONDITION = ${if !eq{$interface_port}{25}}' >> /etc/exim.variables.conf.custom
but also in that case, connections to port 110 are not allowed (did not test smtp).

Edit: reason might be dovecot is not starting.
Fatal: Error in configuration file /etc/dovecot/conf.d/91-quota-warning.conf
Click to expand...

Got this content in there:
Code: 
plugin {
  quota_warning = storage=100%% quota-warning 100 %u %d
  quota_warning2 = storage=95%% quota-warning 95 %u %d
  quota_warning3 = storage=80%% quota-warning 80 %u %d
}
service quota-warning {
  executable = script /usr/local/bin/quota-warning.sh
  user = root
  unix_listener quota-warning {
    user = mail
    mode=0666
  }
}

Does this plugin not work anymore?

Edit: we temporarily fixed it by removing this customisation. But this was nice, so we would like to know if this can be possible again somehow.
 
Last edited:
Richard G said:
Does this plugin not work anymore?
Edit: we temporarily fixed it by removing this customisation. But this was nice, so we would like to know if this can be possible again somehow.
Click to expand...
Is this after upgrade to dovecot 2.4? If so, you need to re-do the quota warning thing.
Try something like this in custom/dovecot/2.4/conf.d/90-quota.conf:
Code: 
quota "" {
  driver = maildir

  warning warn-100 {
    quota_storage_percentage = 100
    execute quota-warning {
      args = 100 %{user} %{user | domain | lower}
    }
  }
  warning warn-95 {
    quota_storage_percentage = 95
    execute quota-warning {
      args = 95 %{user} %{user | domain | lower}
    }
  }
  warning warn-80 {
    quota_storage_percentage = 80
    execute quota-warning {
      args = 80 %{user} %{user | domain | lower}
    }
  }
}

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

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

See https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2.4.html for more details about the new syntax.
 
Last edited:
Thanks! I used the example in the docs but script part from previous script.
The begin lines are a bit different.
Like:
Code: 
quota user {
  warning warn-95 {
etc..

And I put it in a 91-quota-warning.conf file because the original file can be overwritten. Dovecot restarts, but I have to wait if mails are send if quota is too high.
 
We only had some servers with this quote config, not sure how that's possible?

I've rolled back to Dovecot 2.3 on those servers for now.
 
fln said:
@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
Click to expand...
Would it be possible to log these users somewhere? I'm not expecting many users will still use port 25 but it's extremely likely some do. I only want to send a targeted email to a handful of customers. I'm pretty sure if we send an email to all customers there will be much more pressure on support with 'false positives'.

Edit: should've read the answer on page 2. We're going to use this for now:

Bash: 
grep P=esmtpa /var/log/exim/mainlog* \
  | grep -v -e ' \[::1\] ' -e ' \[127\.0\.0\.1\] ' \
  | sed -n 's/.*A=login:[^@]*@\([^ ]*\).*/\1/p' \
  | sort -u

It gives us a list of all domains we need to reach out to.
 
Last edited:
My custom ssl.conf (/usr/local/directadmin/custombuild/custom/dovecot/conf) for dovecot is not updating the main ssl.conf anymore?
I see there is also new syntax for that and copied the new ssl.conf

Code: 
ssl_server_cert_file = /etc/exim.cert
ssl_server_key_file = /etc/exim.key
ssl_server_dh_file = /etc/dovecot/dh.pem

ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256

into /usr/local/directadmin/custom/dovecot/conf/ssl.conf, changed the TLS to 1.3 and did da build dovecot_conf like before but still not working

Edit

sorry.. RTFM:devilish:

Changed it to (and in new 2.4 dir)

Code: 
ssl_server_cert_file = /etc/exim.cert
ssl_server_key_file = /etc/exim.key
ssl_server_dh_file = /etc/dovecot/dh.pem

ssl=required
ssl_min_protocol = TLSv1.3
ssl_server_prefer_ciphers = client
ssl_curve_list = X25519:prime256v1:secp384r1

According to Mozilla SSL generator and all working now
 
Last edited:
Dovecot build through DA did not succeed. Find the end of log below

'
libtool --tag CC --mode link cc -std=gnu11 -g -O2 -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -mfunction-return=keep -mindirect-branch=keep -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -fPIE -DPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now \
-L/usr/lib64/dovecot -ldovecot -ldovecot-storage -I/usr/include/dovecot -o maildirlock /usr/local/directadmin/custombuild/configure/maildirlock/maildirlock.c
make: libtool: Command not found
make: *** [/usr/local/directadmin/custombuild/configure/maildirlock/Makefile:16: maildirlock] Error 127
failed to build maildirlock'

Is there a way to 'symply' revert to previous version 2.3 (the code does not seems to be online anymore)
 
@zEitEr, @kristian, thanks for pointing out the old quota notifications guide in the docs. It was updated to have both versions - for Dovecot 2.4 and 2.3. The example in @kristian's post could be slightly improved by hardening the socket permissions to be 0660 and making the socket file accessible to the mail group.

Right now, quota warnings are a customisation outside of DirectAdmin/CustomBuild. It means server admins are responsible for maintaining it. But considering it is a useful feature, we are planning to incorporate it into DirectAdmin/CustomBuild. This would mean enabling quota notifications would be a control flag in the CustomBuild options.conf file.
@castris, the error HELO should be a FQDN has nothing to do with the exim SMTP auth policy change. This error can no be triggered by authenticated connections.
 
Can somebody enlighten me what this means from the changelog?
# Block SMTP authentication on plain-text connections, but allow it to work on all TCP ports
Click to expand...
Code: 
sed -i '/^AUTH_ENABLE_CONDITION /d' /etc/exim.variables.conf.custom
echo 'AUTH_ENABLE_CONDITION = ${if or { {def:tls_in_cipher} {match_ip{$sender_host_address}{<; 127.0.0.1 ; ::1}} }}' >> /etc/exim.variables.conf.custom
da build exim_conf

So block smtp, but allow it to work on all ports??? That confuses me a little bit (sounds contradictory). What exactly does this do?
Would this fix php mail() issues or what is this for?
 
Richard G said:
So block smtp, but allow it to work on all ports??? That confuses me a little bit (sounds contradictory). What exactly does this do?
Would this fix php mail() issues or what is this for?
Click to expand...

If a plain connection is done (i.e. without an encryption) to any port: 25, 465, 587; then no SMTP auth will be allowed. Localhost and 127.0.0.1 are exceptions here, so PLAIN AUTH is allowed only from inside.

Correct me if I'm wrong please.
 
Thank you @zEitEr.

@fln It might be wise to make it more clear in the docs by adjusting the explanation to:
# Block SMTP authentication on plain-text connections, but allow it to work on all TCP ports for localhost
 
fln said:
@castris, the error HELO should be a FQDN has nothing to do with the exim SMTP auth policy change. This error can no be triggered by authenticated connections.
Click to expand...

Hi.

**Sorry to sound a bit surprised.**

Maybe I didn't quite understand, but the post originated from a change in DirectAdmin 1.676. At no point did I mention that the problem was related to authentication. This would surprise me a lot, since the message is clear: "R1: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)".

And I understand that this has to do with the change or update, as it didn't happen before, and now five users across three machines are experiencing it.

It's evident that this is due to a change in the rules, to be more strict. But in a technical environment where many SAP systems and third-party services, which are old and programmed to use SMTP, this leads to problems with clients who must find a solution.

Even applications with older versions have the habit of sending HELO with the machine name, the short hostname, and that is another problem.

All of these can be resolved gradually, but these changes are very tough and generate a lot of frustration among the clients.

Best regards.
 
@castris the DA 1.676 had no changes to Exim except the authenticated SMTP policy. The best way forward would be to open the support ticket and track down the root cause of this problem. Most likely it has nothing to do with this release.
 
Ok. if there are not changes for this question, so I will look for another way to address the issue. Thank you.
 
@castris If you really think it's done due to the changes, then just disable everything like this:

# Use old (insecure) SMTP authentication policy, authentication always available
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
and see if the issue is gone.

I'm sure FLN is correct and it has nothing to do with it, but this way you can look for yourself if things work again.
If not, just remove that line from that file and rebuild exim.conf again and search for the real cause.
 
You must log in or register to reply here.
Back
Top