OpenLDAP Pass-through Authentication
Hi, Trying to get pass-through authentication working however, I'm running to the following error in OpenLDAP: openldap | 679ceede.3aa31e0a 0x7f2ff617e6c0 conn=1004 op=1 SRCH attr=uid mail displayName openldap | 679ceede.3aa4b816 0x7f2ff617e6c0 conn=1004 op=1 SEARCH RESULT tag=101 err=0 qtime=0.19 etime=0.000172 nentries=1 text= openldap | 679ceede.3aaafd88 0x7f2ff597d6c0 conn=1005 fd=14 ACCEPT from IP=172.16.32.1:47082 (IP=0.0.0.0:1389) openldap | 679ceede.3aab8f34 0x7f2ff597d6c0 conn=1005 op=0 BIND dn="cn=usern...@domain.tld,ou=users,dc=domain,dc=local" method=128 openldap | 679ceede.3aac9267 0x7f2ff597d6c0 SASL [conn=1005] Failure: cannot connect to saslauthd server: No such file or directory openldap | 679ceede.3aad25b9 0x7f2ff597d6c0 conn=1005 op=0 RESULT tag=97 err=49 qtime=0.05 etime=0.000120 text= openldap | 679ceede.3ab0191f 0x7f2ff617e6c0 conn=1005 fd=14 closed (connection lost) openldap | 679ceede.3ab3d76a 0x7f2ff597d6c0 conn=1004 fd=13 closed (connection lost) I followed the admin docs at: https://www.openldap.org/doc/admin26/guide.html#Pass-Through%20authenticatio n Here's what I did: Created /usr/lib/sasl2/slapd.conf with the following content: mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/sasl2/mux Created /etc/saslauthd.conf with the following content: ldap_servers: ldap://192.168.xxx.xxx.xxx ldap_search_base: OU=Users,DC=domain,DC=tld ldap_filter: (uid=%u) ldap_bind_dn: CN=saslauthd,CN=Users,DC=domain,DC=tld ldap_password: somepassword Added a user that already exists in domain.tld in openldap with the following password: {SASL}usern...@domain.tld I would appreciate some help on this. Thanks ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
RE: OpenLDAP Pass-through Authentication
Apologies. Posted to the wrong list. Please disregard. >Hi, >Trying to get pass-through authentication working however, I'm running to the >following error in OpenLDAP: ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Problem email client iPhone ios18.2
Hello, I experience the same problem (mail headers not loading, mail bodies not loading) since iOS 18 on one of my machines. The other machine seems unaffacted, but I don't know yet which setting is different. The working one is Debian, the broken one FreeBSD. Terminating the mail app via the task manager and starting again fixes the problem temporarily. Florian ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Problem email client iPhone ios18.2
On 4. Feb 2025, at 3.53, stephen--- via dovecot wrote: > > in my experience the only users who complained were mail abusers - with tens > of thousands of messages in each folder - tons of folders etc etc. smaller > mailboxes seemed fine. i think apple uses some threshold where this new > pipelining takes place on larger mailboxes maybe. > > there is a lot of info including raw logs here where they ended up patching > it in another mail server: > https://github.com/stalwartlabs/mail-server/issues/765 With Stalwart apparently they had a clear issue with IDLE pipelining. Dovecot is able to handle DONE + commands pipelined just fine, at least in all my tests. So I don't think Stalwart rawlogs are helpful for Dovecot. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Problem email client iPhone ios18.2
On 04/02/2025 11:19 EET Florian Effenberger via dovecot wrote: Hello, I experience the same problem (mail headers not loading, mail bodies not loading) since iOS 18 on one of my machines. The other machine seems unaffacted, but I don't know yet which setting is different. The working one is Debian, the broken one FreeBSD. Terminating the mail app via the task manager and starting again fixes the problem temporarily. Florian ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org Can you send imap rawlogs privately to me when it's misbehaving? Set rawlog_dir to a world writable directory. Aki ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: IMAP dovecot\postgres low authentication performance
On 3. Feb 2025, at 20.18, Anatoliy Zhestov via dovecot wrote: > >> >> Are you sure the problem is authentication / pgsql? You could test with >> looping "doveadm auth lookup $user" rapidly. Of course for different users >> to avoid them coming from cache. Or if you can reproduce it that way, try >> if the same happens for repeating the same user so it does come from cache. > > > i test in condition when 90% of imap connection is already established. > auth cache is enabled so i guess tests with the same user are not relevant. > > less loaded server > ps waux|grep imap-login|wc -l > 24977 Oh, somehow I missed that you have this many concurrent connections. > echo "13285 / 343" |bc > 38 (per second) So with this speed 24977 users would take 11 minutes to login back, which is a bit slow. Some ideas: 1) If pgsql is the bottleneck, try multiple pgsql connections: Add maxconns=4 (or whatever) to the dovecot-sql.conf.ext's connect line. 2) In your Dovecot proxy (assuming you have one?) you can configure it to spread over disconnections over a long time, if the issue is that backend disconnects everyone at once. login_proxy_max_disconnect_delay setting does this. 3) With that many connections and to make logins faster, you'd be better off using https://doc.dovecot.org/2.3/admin_manual/login_processes/#high-performance-mode 4) To optimize login performance, it would be best to get rid of the post-login script. Also: service imap { service_count = 1000 process_min_avail = 10 } 5) auth_cache_size is rather small. Likely could be increased much larger. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: IMAP dovecot\postgres low authentication performance
Good idea, thanks. As I understand it, this is a one of a standard modboa installation script, but I think we won't have big problems with updates if we make a trigger instead of this script. However, I still don't quite understand what event to assign it to. The database doesn't know anything about whether the login was successful, and updating the time of the last successful login for any login-password request doesn't seem correct to me. On Mon, Feb 3, 2025 at 11:10 PM Marc wrote: > > > > Do you mean that the contents of this file are not cached? or that there > > is > > some limit on the number of simultaneous requests to read it? > > content of this file not look too heavy > > > > > psql -c "UPDATE core_user SET last_login=now() WHERE username='$USER'" > > > > > > /dev/null > > I would put a '&' at the end, so at least nothing is waiting for this. > This does not seem to be critical. This is also not efficient. Can't you > make a trigger in the database so you do not even need a shell script? > > > ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: IMAP dovecot\postgres low authentication performance
> > I can't really write anything useful. On the client side MUA you can't do > anything these are all 'unique' connections. You can only optimize to your > connection to the database. But I am not using this kind of setup. So I > don't really know. I am using ldap and ldap stuff is being cached by sssd > or nslcd. Anyway, thank you for your attention and your ideas and tips. I really hope that we can put them to good use. On Mon, Feb 3, 2025 at 11:15 PM Marc wrote: > > > > > > Probably not as you only restarted. The limit is when you have create a > > new > > > connection and don't use an existing one. > > > > I don't see a way to reuse an existing connection yet if the number of > > persistent connections after a restart should increase from 0 to 40K > > I miss something obvious? (We tried changing the client_limit value for > > imap-login (in order to reduce the number of processes), but in our > > experience it works correctly only within 3-5 and at higher values > > imap-login stops responding quite quickly.) > > > > I can't really write anything useful. On the client side MUA you can't do > anything these are all 'unique' connections. You can only optimize to your > connection to the database. But I am not using this kind of setup. So I > don't really know. I am using ldap and ldap stuff is being cached by sssd > or nslcd. > ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: IMAP dovecot\postgres low authentication performance
> > 1) If pgsql is the bottleneck, try multiple pgsql connections: Add > maxconns=4 (or whatever) to the dovecot-sql.conf.ext's connect line. Great thanks for this hint. I can't imagine how I could have missed this parameter. If I increase maxconns to 200+, does it make sense to use pgbouncer in front of postgresql? Or are these connections permanent and are regulated only by setting the max connections in postgresql itself, and pgbouncer will be useless? 2) In your Dovecot proxy (assuming you have one?) Suddenly no, we didn't have a proxy in this configuration. I haven't worked with this service, so I'll read up on how to set it up properly. 3) With that many connections and to make logins faster, you'd be better > off using > https://doc.dovecot.org/2.3/admin_manual/login_processes/#high-performance-mode What are the default values for service_count\process_min_avail parameters? To enable high performance mode do I need to specify both explicitly or is the first one enough? 4) To optimize login performance, it would be best to get rid of the > post-login script. Also: > service imap { service_count = 1000 process_min_avail = 10 } When we tried to raise service_count > 5, service stopped responding quickly. I suppose now it depends on maxconns=5 by default. 5) auth_cache_size is rather small. Likely could be increased much larger. Thanks for your advice. What value would you recommend here? On Tue, Feb 4, 2025 at 1:23 PM Timo Sirainen wrote: > On 3. Feb 2025, at 20.18, Anatoliy Zhestov via dovecot < > dovecot@dovecot.org> wrote: > > > >> > >> Are you sure the problem is authentication / pgsql? You could test with > >> looping "doveadm auth lookup $user" rapidly. Of course for different > users > >> to avoid them coming from cache. Or if you can reproduce it that way, > try > >> if the same happens for repeating the same user so it does come from > cache. > > > > > > i test in condition when 90% of imap connection is already established. > > auth cache is enabled so i guess tests with the same user are not > relevant. > > > > less loaded server > > ps waux|grep imap-login|wc -l > > 24977 > > Oh, somehow I missed that you have this many concurrent connections. > > > echo "13285 / 343" |bc > > 38 (per second) > > So with this speed 24977 users would take 11 minutes to login back, which > is a bit slow. > > Some ideas: > > 1) If pgsql is the bottleneck, try multiple pgsql connections: Add > maxconns=4 (or whatever) to the dovecot-sql.conf.ext's connect line. > > 2) In your Dovecot proxy (assuming you have one?) you can configure it to > spread over disconnections over a long time, if the issue is that backend > disconnects everyone at once. login_proxy_max_disconnect_delay setting does > this. > > 3) With that many connections and to make logins faster, you'd be better > off using > https://doc.dovecot.org/2.3/admin_manual/login_processes/#high-performance-mode > > 4) To optimize login performance, it would be best to get rid of the > post-login script. Also: > > service imap { > service_count = 1000 > process_min_avail = 10 > } > > 5) auth_cache_size is rather small. Likely could be increased much larger. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org