Dan, I must thank you again for your superb and prompt assistance. You provided me with the knowledge (tools) to be able to test effectively and discover that the issue is usage of an incorrect password (and especially with the knowledge that the list of users exists in sasldb and how to set passwords for user in that database).
Now I need to dig into the details of our custom application to see if simply using a correct password resolves all issues. Thank you! - John Wright On Thu, 20 Oct 2011 09:35:28 -0500, Dan White wrote: On 20/10/11 09:13 -0500, wri...@mnstarfire.com wrote:
>Dan, > >I was reading the documentation for configuring Cyrus here in our >environment. Another hint which might help is that I noticed the mechanism >in /etc/default/saslauthd has been changed from "pam" to "sasldb". On 20/10/11 09:16 -0500, wri...@mnstarfire.com wrote: >Dan, > >Opps, here I'll copy and paste the /etc/imapd.conf and attach it: >admins: cyrus >#sasl_mech_list: PLAIN >#sasl_minimum_layer: 0 >#sasl_maximum_layer: 256 >sasl_pwcheck_method: saslauthd >#sasl_auxprop_plugin: sasldb >sasl_auto_transition: no A more typical configuration for your setup is: sasl_pwcheck_method: auxprop sasl_auxprop_plugin: sasldb Which should accomplish the same thing and bypass saslauthd altogether. On 20/10/11 09:22 -0500, wri...@mnstarfire.com wrote: >Dan, > >Yes saslauthd is being started with -a sasldb. > >I've tried loggin in with a few users and get the same result as when I >try with root. > >I used sasldblistusers2 to see that there was only one user (cyrus). >And used saslpasswd2 to set it to a known password and then used imtest >again and it appears to have worked. Thank you! > >So this implies to me that the original problem (which launched me on >this investigation) is that our custom application must be sending the >wrong password. -- Dan White
