OpenLDAP Pass-through Authentication

2025-02-04 Thread Dino Edwards via dovecot
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

2025-02-04 Thread Dino Edwards via dovecot
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

2025-02-04 Thread Florian Effenberger via dovecot

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

2025-02-04 Thread Timo Sirainen via dovecot
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

2025-02-04 Thread Aki Tuomi via dovecot
 
 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

2025-02-04 Thread Timo Sirainen via dovecot
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

2025-02-04 Thread Anatoliy Zhestov via dovecot
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

2025-02-04 Thread Anatoliy Zhestov via dovecot
>
> 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

2025-02-04 Thread Anatoliy Zhestov via dovecot
>
> 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