http://bugzilla.spamassassin.org/show_bug.cgi?id=4550
------- Additional Comments From [EMAIL PROTECTED] 2005-08-22 12:17 -------
First off, using plugins to extend spamd is definitely worth doing. I've been
planning to do it for a long time. I'm planning to move out all the odd little
authentication systems (vpopmail, etc.) into plugins, instead of having that
code littering around spamd.raw -- which is messy and buggy.
Secondly, re capabilities. When thinking about spamc and spamd, the best
parallel is to think in terms of the HTTP protocol, not SMTP or POP. so
capabilities, and capability advertising, is not likely to be useful, in my
opinion -- there's no "banner" sent from server to client, before the client
issues its request, so how's the client going to know what the server supports?
Instead of thinking in these terms, look at how the HTTP/HTTPS protocol solves
these problems.
As a result, in my opinion we should have:
- no authentication on the userid passed (as in current trunk), if spamd has
the command line flag to allow that.
- simple password auth, modeled on HTTP basic authentication. Warn, as with
HTTP basic auth, that the pwd is sniffable.
- simple password auth as above, over an SSL channel.
Some notes:
- The last one is a secure way to do it. Note that there is *no* additional
secure method -- because it's easier just to use SSL and let *that* do the
hard work of keeping the pwd secret, instead of inventing our own secure
protocol! Believe me, I've been down that road before.
- If connection open/close handshaking is an issue, then we add a
connection-persistence hook to the protocol, similar to HTTP Keepalive in
HTTP/1.0 vs HTTP/1.1. we could also do the "session key" idea, but I
think keepalive is more useful.
- If we have >1 methods of userid auth for learning, we will need some way
for spamd sysadmins to indicate their site policy (e.g. "all users must use
auth over SSL").
PS: Michael, +1 in general on the comment 5 idea.
>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.
+1 for either; I can see the usefulness of the latter, as long as the plugin
doesn't interfere with other plugins (or the core) seeing the header.
PPS: spamc password UI -- why not emulate rsync? support passing it in through
an environment var, it works well for rsync, should work here too.
PPPS: I don't see how att 3054 on bug 4517 is relevant -- the have_plugin()
call? not getting it.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
