Next message: Derrick J Brashear: "Re: on a similar note: enabling CRAM-MD5 auth for postfix+cyrus-imap+auxprop+mysql w/ encrypted passwords?"
hi all,
> It's nothing to do with the design of Cyrus, it's all about how the shared secret authentication methods work.
<snip>
> but my previous statement is a mathematical reality.
all-right-y then. i'm sure it is. thanks. i acknowledge your views as to what can't or shouldn't be done.
so, now, does anyone else have any suggestions or interest as to how "this" (incl. Cyrus ...) might be made to work like other, currently available-and-operational systems (CGPro & Courier are apparently two ... any others?)?
or are the consenus/suggestions from the cyrus-world 'go use one of those
other systems' or 'fix it yourself'?
one of the driving forces here is that there are in existence systems (as mentioned) where 10s-1000s of clients are configured currently to use CRAM- or DIGEST-MD5 (perhaps also Kerberos, GSSAPI, NTLM ... but i've _zero_ experience with those auth mechs, client- or server-side) over TLS backended by 'other systems', commercial or otherwise.
if the goal is to migrate to _this_ proposed system, then eventually there's an administrative task to be undertaken. either:
(a) all the clients need to be invidually reconfigured --
-- by either admins or the users <<< BAD
or,
(b) the existing encrypted PWD db's beed to migrated to (i) unencrypted stores, or to (ii) a translated system where "something_in-the_middle" (sasldb, etc.) is maintains a separate UNencrypted store in parallel/sync with the existing encrypted one <<< NOT SO BAD, BUT NOT GOOD
or,
(c) a system needs to be migrated TO that does not require such reconfiguration -- i.e., one that DOES support secret-based auth over TLS/SSL with encrypted password stores ... <<< GOOD
IMHO, it'd be great to get some input from the maintainers as to issues/priorities at hand ...
Cheers,
richard
