http://bugzilla.spamassassin.org/show_bug.cgi?id=4546
------- Additional Comments From [EMAIL PROTECTED] 2005-08-19 22:52 ------- I also agree that learning disabled by default is correct. I've been thinking about how secure authentication can be done. The biggest problems I see: 1) The spamd protocol does not have any notion of session. Authentication that does not pass a password in the clear requires a back and forth protocol and the establishment of a session. A session based protocol is a huge change. 2) I really don't like the idea of rolling our own secure authentication protocol. Security protocols never come out right when you just make them up. 3) Some ideas I thought about don't scale well in, for example, an ISP environment. For example, let's say that we store a password in each user's bayes database and require that the password be somehow passed in the spamc call. Ignoring for the moment how to do that without the password being in the clear on the network (a solvable problem), it seems like it would be difficult for an ISP to set up for all users. Similarly for setting up a client-side SSL certificate for each user, which would have to go both on the client and server side. Here is a simple solution. Add a password configuration option to both the spamc configuration file and the regular (spamd) per-user configuration file. Spamc only uses it when -S is specified. The protocol gets an new field for password. If spamd sees a password configured in the specified user's preferences, it only will process a message if SSL is being used and the correct password is sent by spamc. The sysadmin already has to provide users with the ability to set their own local preferences and the user configuration files or database entries already have to be kept secure from other people. The user can enable learning via spamc -L by setting matching password options in the two config files. By requiring SSL, there is no security hole in passing the password in the clear from spamc to spamd. Note that this is not necessary if auth-identd can be trusted. That will be the case if spamd is configured to only accept connections from a trusted IP address (such as localhost) on a system that supports identd. In that case, the password is not necessary, --auth-ident takes care of the authentication, and everything just works. If SSL adds too much overhead for a system with many users and high load, then the sysadmin just has to set things up so that the spamd server can trust the spamc client machines' identd. Comments? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
