<div class="gmail_quote">2010/7/4 Dan White <span dir="ltr"><<a href="mailto:dwhite@olp.net">dwhite@olp.net</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Cyrus SASL requires that shared secrets be stored within an auxprop store,<br>
such as sasldb. Regardless of what your sasl_pwcheck_method configuration<br>
is, sasl will always use your auxprop plugin(s) to service the DIGEST-MD5<br>
plugin. To use DIGEST-MD5, you could use saslpasswd2 to store user<br>
credentials within /etc/sasldb2.<br>
<br>
saslauthd, and pam, cannot perform the required handshaking that DIGEST-MD5<br>
requires, since the neither have knowledge of what the shared secret<br>
(password) is.</blockquote><div> </div><div>Thanks for the explanation. When I think about it, it makes sense<br>that MD5 cannot work when it has to pass it on to another<br>auth service.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
More than likely you were dealing with clients that failed the DIGEST-MD5<br>
authentication and then fell back to PLAIN or pre-sasl login.<br>
<br>
If 'allowplaintext' is disabled in your imapd.conf, then PLAIN, LOGIN, and<br>
pre-sasl login can only be achieved in the presence of TLS or some other<br>
encryption. 'allowplaintext: 0' will prevent a clear text password from<br>
being sniffed over the wire.<br>
</blockquote></div><br>Yes. I don't know why one type of connection tries the next method<br>while non-TLS only did CRAM-MD5 and then failed. I'll fix it to not<br>reference the MD5 mech types.<br><br>In our case the webmail and cyrus are on the same subnet used only<br>
in the data centre, so we are not concerned with access of data<br>over the wire. With a few thousand people accessing webmail,<br>I would be more concerned about the load of encrypting all that traffic<br>between Cyrus and Horde. We do use TLS on the Horde login screen.<br>
<br>--Donald<br><br>