http://bugzilla.spamassassin.org/show_bug.cgi?id=4550
------- Additional Comments From [EMAIL PROTECTED] 2005-08-21 18:26 ------- Ok, some more details on a possible solution. 1) In spamd.raw parse_headers you add a spamd_parse_headers plugin hook. Initially I was thinking as just an else case but I can see value in letting plugins step in for any of the headers. 2) Then you add the services_authorized_for_username plugin hook in sub check and sub dotell passing in the appropriate service (ie check, report, process, learn, etc). 3) Then you add a new command line option to spamc that accepts a password and adds a password (or something else) header to the spamd protocol stream. 4) Then you create a plugin that has a hook that reads in the new password header and resonds to the services_authorized_for_username call with the appropriate response. It would also allow a new config option, choose whatever name you want really, that allows the user to specify the password. The plugin would then compare the passed in password with the one in the config and use that to generate it's response. Bonus points for doing interesting things with the password, like MD5 hashes or other obfuscation techniques. I know it's basic, but in the long run I see plugins that instead of looking in the user config it will do some database or ldap lookups to determine if the user is authorized. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
