On Thu, Nov 14, 2002 at 10:03:49AM -0500, Theo Van Dinter wrote:
> On Wed, Oct 30, 2002 at 02:16:28PM -0500, Michael Stenner wrote:
> > 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.
>
> you forgot:
> BAD: The default on a lot of systems is to do encrypted ident,
> so you just get a string like '[aTOhw4XvZQD6kO5C0jqERAw87rIngQRq]'
>
> I can decode that (timestamp uid source_ip source_port
> dest_ip dest_port)
> but spamd would have no way of doing it. Even if it did, it'd
> have to figure out uid->username.
I didn't forget it. At the time I wrote this message, I didn't KNOW
it :) I discovered that later, and the auth-ident patch I submitted
blissfully ignores it. Basically, it's up to the admin to make their
ident server send usernames in plaintext. Perhaps I should have put
that in the docs.
I don't think it's an unreasonable requirement.
1) it reduces computation considerably
2) ident is likely to be running on the same machine as spamd anyway
3) ident is likely to be set up specifically for this purpose
> > 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.
>
> I still don't see the purpose of authentication in spamd. Unless you
> enable user rules, the only things I can think of that could happen
> maliciously is tainting the AWL and generating lots of log entries with
> the other user's name.
Well, we are going to be deploying it in a situation where (about) 200
people will be using it, we want to enable user rules, and we don't
want to restrict executables that can be run from procmail. I agree
that the threat is not major, but it's also avoidable at a cost we're
willing to pay.
> So far, I think authentication has more negatives (namely added complexity
> and time) than positives (limiting who can run through spamd with your
> config).
I understand your point, and think that for most (probably 90% or
more) cases, I would agree with you. There are some cases (namely
ours) where I don't. I certainly don't think it should authentcate by
default. As the patch is written, it's EXTREMELY lightweight if you
don't use --auth-ident (*), and the (code) complexity is rather small.
I guess all I'm saying is that I think some people (few perhaps) will
find the tradeoff worthwhile. I know we do.
-Michael
(*) At start-up time, it must compile about 20 lines of code, but
loads no modules. For each message, it does one "if" on a hash
value.
--
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: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
