Theo, 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).
yes
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.
allowing everyone to connect to a service on my systems is mostly a bad idea, isn't it.
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.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.
I disagree. I'm maintaining a departmental server where our mailboxes are. Most of the mailboxes belongs to virtual user (these user don't exists on OS level). Therefore I need the -u switch to set the uid to spamc. There are also shell users that have access to this server and need to be able to call spamc (i.e. developers or skilled people). Because the -u switch is available to everyone, one could test the SpamAssassin settings of other user or trick the address of a well-known spammer into the AWL database of other user. One requirement (from our security policy) for running our own mail services is that none of the user has access to logs, settings or the mailboxes, neither directly nor indirectly through any tool like SA. Even if I restrict access to spamd to the localhost. I could not fulfill these requirements if I use SA. This setup is very common for mid-size companies or departments. So SA really breaks security here.
That's true for everything that improves security. Nevertheless securitySo far, I think authentication has more negatives (namely added complexity and time) than positives (limiting who can run through spamd with your config).
is a big point these days. Most security violations comming from inside.
cu,
Jan
-------------------------------------------------------
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
