http://bugzilla.spamassassin.org/show_bug.cgi?id=4550
------- Additional Comments From [EMAIL PROTECTED] 2005-08-22 15:59 ------- I mostly agree with Justin's comment 9, with these further comments: No auth is fine. --auth-ident is useful with it. Do we want to implement it as a plugin, though? In HTTP basic authentication, the client sends a name/password in the clear in two fields in the protocol. The server can send a request for authentication to the client and the client then has to respond with it. In our case there is no need for spamd to send a request for authentication to spamc. HTTP encodes the password in BASE64, which seems like a good idea for our protocol. So what we are left with that we add another field to the record that spamc sends in addition to the existing user name field, which will contain 'pwd:' and the BASE64 encoded password. That basic authentication becomes secure when used with SSL or with a VPN or SSH tunnel. I agree that it would be a headache to design our own secure protocol. However, we should make sure that the plugin API makes it possible for someone to use a plugin that encrypts/decrypts the message using a per-user key that spamc and spamd have access to. That provides security that is a lot more lightweight than establishing an SSL session each time or requiring every user to have a VPN tunnel to the server. I might write such a plugin. I don't see any reason for persistent connections. Let's not add a keepalive header unless a reason for it comes up. If one does, I agree with the HTTP 1.0 style of header that has no keepalive by default and a 'connection: keepalive' field to keep the connection open. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
