1 (edited by 3n4rch3 2021-02-18 21:20:00)

Topic: [SOLVED] 'ldap_force_change_password' plugin behaves inconsistently

- iRedMail version (check /etc/iredmail-release):                           1.3.2 OPENLDAP edition.
- Deployed with iRedMail Easy or the downloadable installer?      Downloadable, self-hosted
- Linux/BSD distribution name and version:                                    CentOS Linux release 8.3.2011
- Store mail accounts in which backend (LDAP/MySQL/PGSQL):  LDAP
- Web server (Apache or Nginx):                                                     Nginx
- Manage mail accounts with iRedAdmin-Pro?                               (Not yet for LDAP...soon!)
TL;DR Edit: Check your ports! If you're using alternatives, postfix/master.cf needs to be adjusted for iRedAPD to work its magic consistently.

Thanks to quick help from ZhangHuangBin, my iRedAPD connection problem is history. However, I've run into another iRedAPD-related problem.

iRedAPD has a plugin 'ldap_force_change_password' that purports to prevent SMTP sessions (i.e., no sending) when a password is expired. I did some preliminary checks a week ago using Mozilla's Thunderbird email client, and was quite happy with the results. Not only was sending prevented, but the user got an alert message pop-up containing the webmail address where the password could be changed. Great!

The problem now is that, with my other issue addressed, I can do more testing with other clients...and that is not looking so promising. :-/  Thunderbird still blocks & notifies, but other Linux-based clients (claws-mail, sylpheed), as well as "Mail for Windows 10", just do not. Same for Android open-source clients (K-9 Mail, FairEmail). In most cases, the message simply gets sent, with not even a warning.

Why is this? Is the plugin really so dependent on the client picking up a particular signal that there's a 'problem'? Do I (really??) need to require users to stick with Thunderbird, so that I can expire their password when necessary? Or...am I missing something in the setup (more likely!)?

It seems to me that this should probably be enforced at a client-independent level, no?


Re: [SOLVED] 'ldap_force_change_password' plugin behaves inconsistently

Is this normal/to-be-expected behavior? Is it only my weird subset of mail clients, or has anyone else out there experienced this?


Re: [SOLVED] 'ldap_force_change_password' plugin behaves inconsistently

Comparing logs for working & non-working connections, i realized that we have both imap-submission (587, working) and SMTPS (465, module doesn't work) available. IIRC, this should only require a change to postfix configs. But...my postfix-fu is not that great. How can I group them so behavior is similar? Or maybe the easiest solution is to simply replace port 587 with 465, since that is the end-goal in this situation.

Any tips?


Re: [SOLVED] 'ldap_force_change_password' plugin behaves inconsistently

Fixed, I hope. :-)
I already had this block in postfix's 'master.cf' to enable SMTPS, but needed to add the 'smtpd_client_restrictions' line, so it now looks like this:

## CUSTOM (Add port 465 for 'submissions', implicit rather than opportunistic TLS.)
smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o content_filter=smtp-amavis:[]:10026

Windows insists on doing its own cute little message rather than the custom notification; but otherwise, seems like it's working...woot!


Re: [SOLVED] 'ldap_force_change_password' plugin behaves inconsistently

We have this "smtpd_client_restrictions=" line in our tutorial, it's just your mistake. smile


Buy me a cup of coffee ($5) to support iRedMail:

buy me a cup of coffee