I sent this to spamassassin-devel a moment ago, then realized it's
probably fair-game to spamassassin-talk, too. Here you go:
-------------------------------------------------------------------
We're considering implementing spamd/spamc in a fairly normal way:
spamd runs as root to maintain full auto-whitelist and user-config
functionality, and spamc being run system-wide (or over-ridable in
.procmailrc).
This is all great, but we're a little concerned about the fact that a
modified spamc can be used to do mildly nasty things to other people
by telling spamd it's someone else.
I suspect you are all aware of this, but here's an example (skip at
will):
I modify spamc so it always says its running as user "foobar" (my
mortal enemy). I then run a carefully crafted message with a
score of 200 and coming "from" foobar's boss through this modified
spamc 1000 times. foobar never gets the mail so he doesn't know
what's going on, but now his AWL database is screwed up and he
stops getting mail from his boss.
Yeah, it's minor... I know. Still, I'd like to see it addressed. The
reason I'm writing to this list is I'd like to look into doing
something about it and wanted to get feedback. The way I see it,
there are two major ways to approach this. Both could only be applied
part of the time and so would probably be available as command-line
args. Besides, you wouldn't even WANT something like this in many
cases.
1) use ident: spamc connects, spamd asks ident if spamc is who it
says it is, then proceeds.
BAD: This is slowish (although probably not compared to the
spam-checking itself).
BAD: Not portable.
BAD: You'd need to restrict the server to accept connections only
form ident-able machines, the you're probably already
restricting anyway.
GOOD: probably pretty easy to implement
GOOD: still fully network-based
2) use unix sockets and check who's on the other end directly.
BAD: spamc and spamc must run on the same machine (although we
intend to do this anyway via firewall rules)
BAD: both spamc and spamd must be modified
GOOD: more portable: most everybody has unix sockets
GOOD: probably pretty fast
Anyway, I'm interested in what people think would be the best way to
address this and whether there would be enough interest to warrant
patch-acceptance. If it's just us, I probably won't spend the time on
it, but if it's likely to be incorporated, I probably will.
-Michael
--
Michael Stenner Office Phone: 919-660-2513
Duke University, Dept. of Physics [EMAIL PROTECTED]
Box 90305, Durham N.C. 27708-0305
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
