Dspam home has one gid /uid yes. But the maildirs under it (I use it per user base not per emailadress base) has their own gid /uids. If not the webui cannot access these files. Maybe theres another way bt this way was for me the only working solution.
I think it would be real important to have a split between users and dspam. I mean at the moment a mail goes to dspam until the moment it leaves it should be under the authority of dpsam. Nothing else. User authenticate anyway different to the webui (like pop3/imap login). All dspam has to know which dataset a user has to get. By this way it should be not that hard having groupadmins ,.. Additionally: It would be also possible (if not in mysql) to store mbox files in a different maybe more suiteable format than mbox/maildir. It has nothing todo with the situation now but im just thinking ahead a bit. It would make it possible to store all users over different servers : Lets say user a has 1k mails but they are stores 500/server 1 500/server2 ... in webui you see one list with 1k (I know dspam cannot do this at the moment but by changing the structure things like this maybe possible) Also it maybe the first step to make webui and dspam server possible on different hosts. Another maybe function would be every mail older than x days go into a gzip archive until user deletes it or deliver it. And and and .... dont wanna flood here with more possible feature ideas :-) My point it dspam must get more flexible. Means only dspam engine itself has to know where are the mails are and how to deal/deliver it) webui should just be the one which sends dspam commands like : please deliver xxx and delete xxx Here it would be a big deal having the mbox files into Xsql But these are just crazy ideas from Austria .-) Imposit.com Phone: +43 (1) 9971636-30 Fax: +43 (1) 9971636-90 E-mail: mailto:webmas...@imposit.com Web: www.imposit.com Registered Office: Wienerstrasse 130, 8680 Mürzzuschlag, Austria, Company number FN310087K -----Ursprüngliche Nachricht----- Von: Steve [mailto:steeeeev...@gmx.net] Gesendet: Samstag, 05. Dezember 2009 21:26 An: dspam-devel@lists.sourceforge.net Betreff: Re: [Dspam-devel] Control multiple users from one login on web-ui -------- Original-Nachricht -------- > Datum: Sat, 5 Dec 2009 21:13:04 +0100 > Von: "Imposit.com - Webmaster" <webmas...@imposit.com> > An: dspam-devel@lists.sourceforge.net > Betreff: Re: [Dspam-devel] Control multiple users from one login on web-ui > Ok but the user has no right tot he mbox file. > > Maybe im wrong but I thought the credentials needed to get rights on the > mbox file trough suexec > Depends on the implementation. I general the DSPAM_HOME has just one uid/gid. I don't know how it is with enabled home dir. Do you know that? > > > Von: Edgar Díaz Orellana [mailto:eorel...@fulltimehosting.net] > Gesendet: Samstag, 05. Dezember 2009 21:07 > An: dspam-devel@lists.sourceforge.net > Betreff: Re: [Dspam-devel] Control multiple users from one login on web-ui > > > > Hi. > > I guess just create 3 tables on mysql engine, with only that you could > create all type of group, users and joins. > > like > > Table A (Users) Table B (Joins ) Table C ( > Groups ) > r...@localhost > Admin (* all users) > ad...@localhost > Admin (* all users) > > ad...@somedomain 1 > ad...@somedomain > j...@somedomain 1 > ot...@somedomain 1 > u...@somedomain 1 > otheru...@somedomain 1 > > > Then when ad...@somedomain logons, could admin all users there could > admin. > > and so on. > > Just think about > > > > On Sat, 05 Dec 2009 16:49:37 +0000, Paul Cockings <ds...@cytringan.co.uk> > wrote: > > I think flat file is absolutely okay (woof woof) > LOL > > So if I really wanted this then maybe a 3rd file then called 'manager.cgi' > that obeys a simple flat file? > 'Managers' that need this function would use > http://my-dspam-install/manager.cgi > > User A can control User 1,2,3,4 > User B can control User 2,4,6,8 > > I suppose error handling would have to include missing (or misspelt) > using, null user, missing file, corrupt file > If 'manager' is not in 'flatfile' then user cannot login, they should go > use http://my-dspam-install/users.cgi > 'manager' can still login to http://my-dspam-install/users.cgi to control > there own profile (but would only see their profile) > > I hear what you say about about this isn't best way and maybe during v4.0 > brainstorming will can build this type of thing in... but until then a hack > will work? Maybe as as a /contrib rather then main project? > > I am thinking simple ie 'manager' as the login user and can control xyz > other users, no more, no less. > > Could I send you a pizza and a large packet of chocolate biscuits to code > this up? I am lost in perl :-( > > Pc > > > > Steve wrote: > > -------- Original-Nachricht -------- > > > Datum: Sat, 05 Dec 2009 15:44:28 +0000 > Von: Paul Cockings > An: dspam-devel@lists.sourceforge.net > Betreff: [Dspam-devel] Control multiple users from one login on web-ui > > > > > > I have some customers that have multiple address's being filtered by the > same Dspam server. To check each account (they are separate as far as > Dspam is concerned) the end user has to log in as user 1, check account, > close browser, log in as user 2, check account, close browser... /loop/ > > Is they anything we can easily do to change the web-ui to handle one > user login that can 'manage' several accounts? Note, I don't want > shared/merged groups as these accounts are better left as individual > spam databases. > > > > Currently you can't switch users. Only an administrator can do that. I > guess declaring them as administrators on DSPAM WebUI is not an option? > > The WebUI works that way that it checks for the HTTP REMOTE_USER variable > and uses that for active user. That restriction is only relaxed for users > that are in the "admin" file mentioned. Every one else can't switch. > > We could relax that for other users but then we would need to have another > source where we need to look for which other user one can switch. > Something like this: > userA (can switch to): userB,userC,userD > > I could add something like that but I see it already. I see already 1 > million users then going to ask that we add group functionality into that. Aka: > groupA (can manage): userA,userB,userC > > And then I see others asking for: > groupA (can manage): userA,userB,userC > groupB (can manage): userX,userY,userZ > groupC (can manage): groupA,groupB > userA (is member of): groupA > userB (is member of): groupB > userPaul (is member of): groupC > admin (is member of): ALL GROUPS > > And then I see others asking for: > groupA (can manage): userA,userB,userC > groupB (can manage): userX,userY,userZ > groupC (can manage): groupA,groupB > groupD (can manage): groupA,groupB,groupC > groupE (can manage): groupC but not members of groupB > > > And so on and so on.... you can imagine: It would be a never ending story > since every one would at the beginning say that they could live with a flat > file and then they start to fill in bug reports asking for feature A, then > feature B and then for featureC and at the end the flat file solution is > ultra terrible to maintain and very limited to work with and it would have > been better to implement everything with a proper directory (aka LDAP or > other solution) then going the simple road. > > But off course. At the beginning everyone and his dog will tell you that a > flat file is absolutely okay and that in NO WAY they would ever want more > then that. In German we have an expression "Mit dem Essen kommt der > Appetit".. That means: With eating comes the appetite. > > As soon as you give the small finger they (the users out there) are going > to take/request the whole hand. And I don't know if doing now again a hack > on top of another hack (the hack on top of the hack is the WebUI) is the > right solution? > > > > > Pc > > > > Steve > > > > > > > > > > > -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ---------------------------------------------------------------------------- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel !DSPAM:1005,4b1ac21e54831804284693! ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
