Feature Requests item #2824760, was opened at 2009-07-21 12:16
Message generated for change (Comment added) made by csmr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126468&aid=2824760&group_id=250683

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Carlo Rodrigues (csmr)
Assigned to: Stevan Bajic (sbajic)
Summary: Preferences ignored when using shared,managed groups

Initial Comment:
When using shared,managed groups, all info (stats, history, quarantine and 
preferences) are relative to the group, and can be seen/managed on the webui,
When the group manager changes the preferences for his group, on the 
preferences pane, they are always ignored.

When  an email comes, dspam just checks if there are any preferences for the 
user itself and for uid 0, If there aren't, dspam uses the preferences in 
dspam.conf.

26720: [07/21/2009 11:58:14] input args: dspam --debug --process --user 
us...@mydomain.tld --deliver=innocent --stdout
26720: [07/21/2009 11:58:14] pass-thru args:
26720: [07/21/2009 11:58:14] processing user us...@mydomain.tld
26720: [07/21/2009 11:58:14] uid = 1111, euid = 1111, gid = 1111, egid = 1111
26720: [07/21/2009 11:58:14] loading preferences for user us...@mydomain.tld
26720: [07/21/2009 11:58:14] _mysql_drv_getpwnam: returning NULL for query on 
name: us...@mydomain.tld
26720: [07/21/2009 11:58:14] _ds_pref_load: unable to 
_mysql_drv_getpwnam(us...@mydomain.tld)
26720: [07/21/2009 11:58:14] Loading preferences for uid 0
26720: [07/21/2009 11:58:14] Loading preferences for uid 0
26720: [07/21/2009 11:58:14] default preferences empty. reverting to dspam.conf 
preferences.
26720: [07/21/2009 11:58:14] Loading preferences from dspam.conf
26720: [07/21/2009 11:58:14] using /var/dspam/opt-in/us...@mydomain.tld.dspam 
as path
26720: [07/21/2009 11:58:14] using 
/var/dspam/opt-out/us...@mydomain.tld.nodspam as path
26720: [07/21/2009 11:58:14] assigning user us...@mydomain.tld to group 
ad...@mydomain.tld

$ dspam_admin list pref ad...@mydomain.tld
enableBNR=on
showFactors=off
signatureLocation=message
trainingMode=TUM

The point of the shared,managed groups is for someone to manage that group, and 
to set the global preferences for that group. The training mode, the signature 
location, etc. This cannot be accomplished with the current implementation.

----------------------------------------------------------------------

>Comment By: Carlo Rodrigues (csmr)
Date: 2009-10-26 16:18

Message:
Hello, Stevan.

2 weeks ago, I posted on dspam-users and dspam-devel asking if it would
make sense to use group preferences for other kinds of groups. As no-one
answered, group preferences are only active for SHARED,MANAGED groups for
now. README file was updated too.

Cheers,
Carlo Rodrigues

----------------------------------------------------------------------

Comment By: Carlo Rodrigues (csmr)
Date: 2009-10-13 22:30

Message:
Hello, Stevan.

Sounds pretty good to me. I just need to slightly change the patch to
allow the group preferences to be used for all kinds of groups, instead of
just being used for SHARED,MANAGED groups.
I'll do that, and I'll update the documentation.
Then I'll get back to you.

Cheers.

Carlo Rodrigues

----------------------------------------------------------------------

Comment By: Stevan Bajic (sbajic)
Date: 2009-10-13 19:44

Message:
Hallo Carlo

Looks good to me. How about you and me making a deal together?

You update the documentation (and post it here) of DSPAM to mention that
preferences can be now attached to groups and I am going to include your
patch into DSPAM 3.9.0.

Is this a deal?


Kind Regards from Switzerland

Stevan Bajic

----------------------------------------------------------------------

Comment By: Carlo Rodrigues (csmr)
Date: 2009-10-13 15:37

Message:
I wrote a patch to allow group preferences to be taken into account. In
this patch, preferences work with the following priorities: default, group,
user. User being the most specific and having the most priority..

This is *very* important for SHARED,MANAGED groups.

----------------------------------------------------------------------

Comment By: Stevan Bajic (sbajic)
Date: 2009-07-21 17:22

Message:
So the changes needed to be done are not that much. However... looking at
the code I see that at the time when the preferences are read only the
agent context is known and one needs now to extend that to have the whole
DSPAM context available inside the function to allow to query the groups
and call _ds_pref_load with the group info. I see on the agent context that
there is a place holding the group information but I don't know (jet) if
that data is written there or not. I would need to check that out. Another
issue is that such a change would affect all storage drivers. So I can not
just go and add that function without doing a bigger test run to see if
everything works as expected.

Kind Regards from Switzerland

Stevan Bajic

----------------------------------------------------------------------

Comment By: Carlo Rodrigues (csmr)
Date: 2009-07-21 17:17

Message:
Yes they are.

----------------------------------------------------------------------

Comment By: Stevan Bajic (sbajic)
Date: 2009-07-21 17:11

Message:
> I mean, they are never used. :)
>
But they are written back into the preference table?

----------------------------------------------------------------------

Comment By: Carlo Rodrigues (csmr)
Date: 2009-07-21 17:09

Message:
>> What do you mean with ignored? Are they written back to the preference
>> table? Can you check that?
>Yes they are. The only problem is that they are used.

I mean, they are never used. :)

----------------------------------------------------------------------

Comment By: Carlo Rodrigues (csmr)
Date: 2009-07-21 17:07

Message:
>
>> Comment By: Stevan Bajic (sbajic)
> Date: 2009-07-21 16:37
>
> Message:
> Hallo Carlo
>
Hey, Stevan

>> The point of the shared,managed groups is for someone to manage that
>> group, and to set the global preferences for that group. The training
>> mode, the signature location, etc. This cannot be accomplished
>> with the current implementation.
>>
> Is that really the point of shared,managed groups? I don't use
> shared,managed groups so I never have thought about it from a
configuration
> viewpoint. I always looked at groups from a data storage viewpoint and
> never from a configuration viewpoint.
>
>
I guess it is, because if you login as a user from a shared,managed group
on web-ui you don't get to see anything of your data, and can't do
anything, except to change preferences. Everything else is non-existent.
There aren't even entries in the db for the individual users the mails come
to (unless there are preferences set for that user). All data on the db is
written with the uid of the manager (stats, tokens, signatures) The group
manager (which is the group name) becomes the entity where everything is
concentrated for that group of users. It all works as if there is really a
single user, the manager.
>> When the group manager changes the preferences for his group,
>> on the preferences pane, they are always ignored.
>>
> What do you mean with ignored? Are they written back to the preference
> table? Can you check that?
Yes they are. The only problem is that they are used.

>
>
> Now that you bring that topic up... I think it is logical to allow the
> groups to have more value then just being storage for tokens. I would
say
> that the logic regarding preferences should be:
> Priority 1) User preferences
> Priority 2) Use group preferences
> Priority 3) Use default preferences (uid 0)
> Fallback) Use preferences from dspam.conf
>
> What do you think?
I think that would be the most logical way to do it.
>
> I am btw going to move that to Feature Request since the functionality
you
> mention is not advertised that way in the DSPAM documentation. I know,
I
> know. Now after reading your text it seems logical to me to have that
in
> place but you have to be honest that this way of group handling was
never
> advertised in DSPAM.
>
Ok.

I will just explain my scenario so what I want to accomplish can be
clear.

I'll be using dspam+postfix on 2 machines, using a shared fs for
dspam_home. This is the mail exchanger for an ISP relaying to approximately
2000 customers' domains. My idea is to hand over the administration of each
domain to the customer. So, someone from company X will have the task of
managing the email for the domain domain-x.tld, and will be responsible for
the retraining and quarantine management. So there is only one login and
one uid for that domain. No individual user accounts will exist on dspam.

We also filter outbound email so our users do not send spam to the outside
and our IP doesn't get blacklisted, and there will be a 'internet' user on
dspam (also a shared,managed group) configured with *, that will get
associated with every email that does not belong to any other group.

Thanks.

Carlo Rodrigues

----------------------------------------------------------------------

Comment By: Stevan Bajic (sbajic)
Date: 2009-07-21 15:37

Message:
Hallo Carlo

> The point of the shared,managed groups is for someone to manage that
> group, and to set the global preferences for that group. The training
> mode, the signature location, etc. This cannot be accomplished
> with the current implementation.
>
Is that really the point of shared,managed groups? I don't use
shared,managed groups so I never have thought about it from a configuration
viewpoint. I always looked at groups from a data storage viewpoint and
never from a configuration viewpoint.


> When the group manager changes the preferences for his group,
> on the preferences pane, they are always ignored.
>
What do you mean with ignored? Are they written back to the preference
table? Can you check that?


Now that you bring that topic up... I think it is logical to allow the
groups to have more value then just being storage for tokens. I would say
that the logic regarding preferences should be:
Priority 1) User preferences
Priority 2) Use group preferences
Priority 3) Use default preferences (uid 0)
Fallback) Use preferences from dspam.conf

What do you think?

I am btw going to move that to Feature Request since the functionality you
mention is not advertised that way in the DSPAM documentation. I know, I
know. Now after reading your text it seems logical to me to have that in
place but you have to be honest that this way of group handling was never
advertised in DSPAM.


Kind Regards from Switzerland

Stevan Bajic

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126468&aid=2824760&group_id=250683

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Dspam-devel mailing list
Dspam-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-devel

Reply via email to