i've tried to replace saslauthd with dovecot sasl service
stopped saslauthd daemon and added
service auth { unix_listener /var/run/saslauthd/mux { mode = 0660 user = root group = mail } }
so it will listen on the same socket.
the effect with sendmail is as below
Mar 23 21:23:29 <2.3> puchar dovecot: auth: Error: Authentication client not compatible with this server (mixed old and new binaries?)
do i need to specify something while compiling sendmail to make it compatible?
}
so it will listen on the same socket.
the effect with sendmail is as below
Mar 23 21:23:29 <2.3> puchar dovecot: auth: Error: Authentication client not compatible with this server (mixed old and new binaries?)
do i need to specify something while compiling sendmail to make it compatible?
solved by setting saslauthd to authenticate over imap - through dovecot server. testsaslauthd shows it works fine.
but it seems sendmail strips domain name from entered login.
On 3/24/19 10:01 AM, Wojciech Puchar via dovecot wrote:
so it will listen on the same socket.
the effect with sendmail is as below
Mar 23 21:23:29 <2.3> puchar dovecot: auth: Error: Authentication client not compatible with this server (mixed old and new binaries?)
do i need to specify something while compiling sendmail to make it compatible?
solved by setting saslauthd to authenticate over imap - through dovecot server. testsaslauthd shows it works fine.
The optimum setup though would be to auth directly against dovecot. A redirection through saslauthd seems unnecessary.
but it seems sendmail strips domain name from entered login.
What backend do you use for authentication ? (system / virtual users ?)
Yassine.
Am 24.03.2019 um 10:01 schrieb Wojciech Puchar via dovecot:
solved by setting saslauthd to authenticate over imap - through dovecot server. testsaslauthd shows it works fine.
but it seems sendmail strips domain name from entered login.
No, it is saslauthd. Check the documention and see the "-r" parameter of saslauthd.
Alexander
but it seems sendmail strips domain name from entered login.
No, it is saslauthd. Check the documention and see the "-r" parameter of saslauthd.
found it a minute before reading this e-mail. thank you
works fine. almost ;)
Why authenticating over imap takes so slow?
my saslauthd runs like that
/usr/local/sbin/saslauthd -a rimap -O 127.0.0.1 -n 0 -r
imap server is handled by dovecot of course.
to be sure it's not sendmail i've tried testsaslauthd
testsaslauthd -u wojtek@puchar.net -p mypassword
works but takes 5-10 seconds. server is lightly loaded.
telnet 127.0.0.1 imap responds instantly.
what to check?
Why authenticating over imap takes so slow?
my saslauthd runs like that
/usr/local/sbin/saslauthd -a rimap -O 127.0.0.1 -n 0 -r
imap server is handled by dovecot of course.
to be sure it's not sendmail i've tried testsaslauthd
testsaslauthd -u wojtek@puchar.net -p mypassword
works but takes 5-10 seconds. server is lightly loaded.
telnet 127.0.0.1 imap responds instantly.
what to check?
seems like saslauthd problem, tried telnetting to imap server and entering login command by hand - works instantly
login_trusted_networks = 127.0.0.1
fixed the speed problem
participants (3)
-
Alexander Dalloz
-
Wojciech Puchar
-
Yassine Chaouche