Re: Benachrichtung zum Übermittlungsstatus (Fehlgeschlagen)

D G Teed donald.teed at gmail.com
Sun Jul 4 07:39:18 EDT 2010


2010/7/4 Dan White <dwhite at olp.net>

>
> Cyrus SASL requires that shared secrets be stored within an auxprop store,
> such as sasldb. Regardless of what your sasl_pwcheck_method configuration
> is, sasl will always use your auxprop plugin(s) to service the DIGEST-MD5
> plugin. To use DIGEST-MD5, you could use saslpasswd2 to store user
> credentials within /etc/sasldb2.
>
> saslauthd, and pam, cannot perform the required handshaking that DIGEST-MD5
> requires, since the neither have knowledge of what the shared secret
> (password) is.


Thanks for the explanation.  When I think about it, it makes sense
that MD5 cannot work when it has to pass it on to another
auth service.


> More than likely you were dealing with clients that failed the DIGEST-MD5
> authentication and then fell back to PLAIN or pre-sasl login.
>
> If 'allowplaintext' is disabled in your imapd.conf, then PLAIN, LOGIN, and
> pre-sasl login can only be achieved in the presence of TLS or some other
> encryption. 'allowplaintext: 0' will prevent a clear text password from
> being sniffed over the wire.
>

Yes.  I don't know why one type of connection tries the next method
while non-TLS only did CRAM-MD5 and then failed.  I'll fix it to not
reference the MD5 mech types.

In our case the webmail and cyrus are on the same subnet used only
in the data centre, so we are not concerned with access of data
over the wire.  With a few thousand people accessing webmail,
I would be more concerned about the load of encrypting all that traffic
between Cyrus and Horde.  We do use TLS on the Horde login screen.

--Donald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20100704/802d8da3/attachment-0001.html 


More information about the Info-cyrus mailing list