http://bugzilla.spamassassin.org/show_bug.cgi?id=4550
------- Additional Comments From [EMAIL PROTECTED] 2005-08-21 19:06 ------- The spamc password should be in the spamc config file, not on the command line (although a command line option that says to require a password is ok) so that the password does not show up in ps and command history lists. We should make it unlikely that someone will unthinkingly use password authentication where it can be sniffed. Perhaps we can enable it only when using a command line option --vpn that does nothing but indicate that the sysadmin claims that spamc/spamd communitcation is being done over a secure network, e.g., SSL or a VPN or on localhost. It would be a huge change to the protocol to make it session oriented. Without sessions and handshaking, the only way I see to avoid sending the password in the clear involves hashing the entire message... Oh, wait, don't spamc and spamd already read the entire message into memory? That means that they can hash it, which means that spamc can include a hash combining the message, the protocol command, the user name, the time, and the password. Spamd would use its copy of the password to verify the hash, which verifies the password as well as the integrity of the message transmission, with the password never being sent in the clear. I just has another idea... The password could be used by spamc to encrypt the message (actually password used to encrypt a session key used to encrypt the message). Spamd verifies the password by successfully decrypting, and sends back the result encrypted with the same session key. Not only do we get authentication without handshaking, but we get message confidentiality without the overhead of SSL. If we do that, it definitely has to be done as a plugin. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
