http://bugzilla.spamassassin.org/show_bug.cgi?id=4546
------- Additional Comments From [EMAIL PROTECTED] 2005-08-22 02:58 ------- Duncan, Ok, I think I understand. With DBM or SDBM users each have their own database file, so running sa-learn can give them no access to another user's database. With SQL, there is only one shared database, so access via sa-learn implies access to all users' data. With DBM and SDBM you can get security by setting things up so users can run sa-learn and either not allow spamc -L or set up --auth-ident properly. With SQL you can't get security if they can run sa-learn. But you still would have to either not allow spamc -L or else set up --auth-ident properly. In any case, I agree that doc can be dealt with later and the voting for the patch can proceed without it being perfect. I'll vote on this as is after I get a chance to build and run with the patch. Loren, --allow-tell is not an option that means "--allow-malicious-data-corruption". It means allow spamc to tell spamd the spam/ham status of the message being sent for the purpose of bayes learning. It just so happens that there is a side effect that allows any user to affect the Bayes database of any other user. The name reflects what it is for, not the side effect. In any case, I think that getting this fix in is what is important. If we figure out a way to get real user authentication for version 3.2, this option could change anyway. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
