Victoriano Giralt | 3 Sep 2011 10:12
Picon
Favicon

Sympa SOAP sends wrong content-length when list definition contains UTF-8


Hi. I am testing Sympa's SOAP and have found that the SOAP service, even
when queried with sympa_soap_client.pl, if the lists subjects or gecos
fields include UTF-8 characters. The response content-length header is
smaller than the real character count in the response document, thus,
clients create too small buffers to process the XML document and validation
of said document fails.

I have verified this capturing traffic off the wire with tcpdump, checking
that the character count of the captured document and the number in the
content-length header differed and then modifying all my lists to remove
the UTF-8 characters from config files, which eliminates the problem. As
soon a the config files are restored to their normal UTF-8 content, the
problem reappears.

I have been googling and the problem seems to be that libwww is counting
*characters* instead os *bytes*, someone proposed a patch to libwww that
some libwww guro refuses and proposes that either the data should be base64
encoded (which I think could do more harm to interoperability), or the
socket should be told to use binary in case the data is not ASCII with
binmode($sock, ":utf8").

I do not know enough neither Sympa internals nor Perl to propose a patch.
Can you please help? I'm using Sympa 6.1.4, SOAP::Lite 0.70 and the libwww
of Perl 5.805.

Thanks.
--
Victoriano Giralt
Systems Manager
(Continue reading)

Victoriano Giralt | 3 Sep 2011 11:40
Picon
Favicon

Re: [SOLVED] Sympa SOAP sends wrong content-length when list definition contains UTF-8


Victoriano Giralt wrote:
The problem is *SOLVED*

| Can you please help? I'm using Sympa 6.1.4, SOAP::Lite 0.70 and the libwww
| of Perl 5.805.
I have upgraded (which I should have done before molesting the list)
SOAP::Lite to the latest version (0.712.5) and it now works as expected.

So, this two messages are here for posterity in case some other lazy soul
hits the problem.

Thanks all for your time reading my messages.
--
Victoriano Giralt
Systems Manager
Central ICT Services
University of Malaga
SPAIN
-
A: Yes.
| Q: Are you sure ?
|> >> A: Because it reverses the logical flow of conversation.
|>> >>> Q: Why is top posting annoying in email ?
David Verdin | 5 Sep 2011 14:05
Picon
Favicon
Gravatar

Re: [SOLVED] Sympa SOAP sends wrong content-length when list definition contains UTF-8

Hi Victoriano,

I updated the required version of this perl module to the latest version, so Sympa users will have their module version updated next time they upgrade.

Thanks for fixing this problem!

Regards,

David

Le 03/09/11 11:40, Victoriano Giralt a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Victoriano Giralt wrote:
The problem is *SOLVED*

| Can you please help? I'm using Sympa 6.1.4, SOAP::Lite 0.70 and the libwww
| of Perl 5.805.
I have upgraded (which I should have done before molesting the list)
SOAP::Lite to the latest version (0.712.5) and it now works as expected.

So, this two messages are here for posterity in case some other lazy soul
hits the problem.

Thanks all for your time reading my messages.
- --
Victoriano Giralt
Systems Manager
Central ICT Services
University of Malaga
SPAIN
- -
A: Yes.
| Q: Are you sure ?
|> >> A: Because it reverses the logical flow of conversation.
|>> >>> Q: Why is top posting annoying in email ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFOYfXwV6+mDjj1PTgRAnGFAJ4z4xDt9puxQqs3H8jv1I7RkBZFsACgxsBh
x9teKFNpwDhGgD4GhQDtn4s=
=GG7F
-----END PGP SIGNATURE-----

--
David Verdin
RENATER
Le CRU est maintenant rattaché à RENATER.
CRU is now attached to RENATER

Requests for Sympa: please use the the Sympa tracker
css | 7 Sep 2011 09:13

Postfix alias help

Hello,

I'm having a tough time getting this setup properly for a non-profit I'm
working with.

I read up on Sympa's features and it looks like the right choice - it covers
three things they need - web-based posting, discussion lists, and announce
lists.  And it covers things I need like a decent permissions system and
bounce processing.

After reading about the various Postfix integration methods, this one seemed
like it was the best in that it would not make me a backscatter source (the
other options for virtual setups do rejects after the message enters the queue
due to their greedy regex matching):

http://www.folly.org.uk/sympa/sympa_config_03.html

It's a nice setup, but the changes to Sympa since that was released left me
having to patch up Conf.pm, alias_manage.pl, and confdefs.pm.

This seems to work however - all my listname-* <at> virt.host.com mappings work,
those aliases are generated automatically by the patched alias manager.  The
Conf.pm changes are working fine (set flags in each virthost robot.conf).

What I seem to be missing since I'm looking at so many Postfix tutorials, many
of which are now outdated, is how to handle my sympa@... mappings.
I can't find a decent reference for that.  Below is my current postfix setup,
which seems to work, but I need to add a mapping manually for each host as
noted in the config.

Let's start with main.cf:

#
# SYMPA STUFF
#
transport_maps = regexp:/usr/local/etc/postfix/transport_sympa

# Set the concurrency for delivery to Sympa
sympalist_destination_recipient_limit = 1
symparequest_destination_recipient_limit = 1
sympaeditor_destination_recipient_limit = 1
sympasubscribe_destination_recipient_limit = 1
sympaunsubscribe_destination_recipient_limit = 1
sympabounce_destination_recipient_limit = 1

# Specify the virtual alias domain(s)
virtual_alias_domains = lists.hostcompanion.com,lists.o4onyc.org

# Specify the virtual alias file(s) - this is the only per virthost config
virtual_alias_maps = regexp:/usr/local/etc/sympa/postfix/
lists.hostcompanion.com,regexp:/usr/local/etc/sympa/postfix/lists.o4onyc.org

Then the transport maps:

# Transport map for Sympa virtual domain transports
/^.*\ <at> sympalist$/         sympalist:
/^.*\ <at> symparequest$/      symparequest:
/^.*\ <at> sympaeditor$/       sympaeditor:
/^.*\ <at> sympasubscribe$/    sympasubscribe:
/^.*\ <at> sympaunsubscribe$/  sympaunsubscribe:
/^.*\ <at> sympaowner$/       sympabounce:

And master.cf:

# Sympa mailing list manager transports
sympalist     unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user} <at> ${extension}
symparequest     unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user}-request <at> 
${extension}
sympaeditor     unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user}-editor <at> 
${extension}
sympasubscribe     unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user}-subscribe <at> 
${extension}
sympaunsubscribe     unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user}-unsubscribe <at> 
${extension}
sympabounce     unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/local/libexec/sympa/bouncequeue ${user}

And now the aliases that are autogenerated for one virthost:

## This virtual aliases file for domain lists.hostcompanion.com is dedicated
to Sympa Mailing List Manager
## You should edit your Postfix main.cf file to declare it
##
/^lists\.hostcompanion\.com$/            xxx
##
#------------------------------ test1: list alias created 06 Sep 2011
/^(test1)-(request|editor|owner|subscribe|unsubscribe)\ <at> lists\.hostcompanion
\.com$/    $1+lists.hostcompanion.com <at> sympa$2.
/^(test1)\ <at> lists\.hostcompanion\.com$/
$1+lists.hostcompanion.com <at> sympalist.

And finally, the hack that I stick in the top of that same file to handle the
bounces, posts, etc.:

# this seems to be necessary, probably belongs somewhere else
/^(sympa)\ <at> lists\.hostcompanion\.com$/
$1+lists.hostcompanion.com <at> sympalist.
/^(listmaster)\ <at> lists\.hostcompanion\.com$/
$1+lists.hostcompanion.com <at> sympalist.
/^(.*+owner\ <at> lists\.hostcompanion\.com$/
$1+lists.hostcompanion.com <at> sympaowner.

I'm pretty lost here - any input is appreciated.

Thanks,

Charles

Elwyn Davies | 7 Sep 2011 20:51

Re: Postfix alias help

Hi, Charles.

I am glad you found my stuff useful!

As far as I can see, you are pretty much done.

You seem to think you have a problem here in that you have to paste this in manually..

> > And finally, the hack that I stick in the top of that same file to handle the
> > bounces, posts, etc.:
> > 
> > # this seems to be necessary, probably belongs somewhere else
> > /^(sympa)\ <at> lists\.hostcompanion\.com$/
> > $1+lists.hostcompanion.com <at> sympalist.
> > /^(listmaster)\ <at> lists\.hostcompanion\.com$/
> > $1+lists.hostcompanion.com <at> sympalist.
> > 
Well you could do some extra stuff to generate this automatically with
the first instance of the list, but I didn't.

Its a once per virtual host operation, so I just left it for manual
config.  I only really cared about making extra lists (I only had one
host to worry about so it wasn't a big deal).  You will have to do it
for each virtual host.

This line is *NOT* required (and will probably screw things up)
/^(.*+owner\ <at> lists\.hostcompanion\.com$/
> > $1+lists.hostcompanion.com <at> sympaowner.
> > 

The aliases already cope with mylist-owner@... etc

One point which is not clear form your mail is that it is essential that
there are no extra newlines in the added lines.. if they are really like
this in the virtual host aliases file, then they won't work.  You need
something like:
/^(root|postmaster)\ <at> lists\.hostcompanion\.com$/      whoever_is_postmaster@...
/^(sympa|listmaster)\ <at> lists\.hostcompanion\.com$/     $1+lists.hostcompanion.com <at> sympalist.

where there is no newline after .com$/

BTW
If you are willing to send me the updated conf.pm etc files, I'll add
them to the description so that people can use them with the latest
version.  I haven't had occasion to upversion my installation yet as it
does everything we needed (very simple requirements) and the password
improvement was not essential.  For our purposes the shared documents
folders were really helpful!

Regards,
Elwyn Davies

On Wed, 2011-09-07 at 09:14 +0200, css@... wrote:
> Hello,
> 
> I'm having a tough time getting this setup properly for a non-profit I'm
> working with.
> 
> I read up on Sympa's features and it looks like the right choice - it covers
> three things they need - web-based posting, discussion lists, and announce
> lists.  And it covers things I need like a decent permissions system and
> bounce processing.
> 
> After reading about the various Postfix integration methods, this one seemed
> like it was the best in that it would not make me a backscatter source (the
> other options for virtual setups do rejects after the message enters the queue
> due to their greedy regex matching):
> 
> http://www.folly.org.uk/sympa/sympa_config_03.html
> 
> It's a nice setup, but the changes to Sympa since that was released left me
> having to patch up Conf.pm, alias_manage.pl, and confdefs.pm.
> 
> This seems to work however - all my listname-* <at> virt.host.com mappings work,
> those aliases are generated automatically by the patched alias manager.  The
> Conf.pm changes are working fine (set flags in each virthost robot.conf).
> 
> What I seem to be missing since I'm looking at so many Postfix tutorials, many
> of which are now outdated, is how to handle my sympa@... mappings.
> I can't find a decent reference for that.  Below is my current postfix setup,
> which seems to work, but I need to add a mapping manually for each host as
> noted in the config.
> 
> Let's start with main.cf:
> 
> #
> # SYMPA STUFF
> #
> transport_maps = regexp:/usr/local/etc/postfix/transport_sympa
> 
> # Set the concurrency for delivery to Sympa
> sympalist_destination_recipient_limit = 1
> symparequest_destination_recipient_limit = 1
> sympaeditor_destination_recipient_limit = 1
> sympasubscribe_destination_recipient_limit = 1
> sympaunsubscribe_destination_recipient_limit = 1
> sympabounce_destination_recipient_limit = 1
> 
> # Specify the virtual alias domain(s)
> virtual_alias_domains = lists.hostcompanion.com,lists.o4onyc.org
> 
> # Specify the virtual alias file(s) - this is the only per virthost config
> virtual_alias_maps = regexp:/usr/local/etc/sympa/postfix/
> lists.hostcompanion.com,regexp:/usr/local/etc/sympa/postfix/lists.o4onyc.org
> 
> Then the transport maps:
> 
> # Transport map for Sympa virtual domain transports
> /^.*\ <at> sympalist$/         sympalist:
> /^.*\ <at> symparequest$/      symparequest:
> /^.*\ <at> sympaeditor$/       sympaeditor:
> /^.*\ <at> sympasubscribe$/    sympasubscribe:
> /^.*\ <at> sympaunsubscribe$/  sympaunsubscribe:
> /^.*\ <at> sympaowner$/       sympabounce:
> 
> And master.cf:
> 
> # Sympa mailing list manager transports
> sympalist     unix  -       n       n       -       -       pipe
>   flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user} <at> ${extension}
> symparequest     unix  -       n       n       -       -       pipe
>   flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user}-request <at> 
> ${extension}
> sympaeditor     unix  -       n       n       -       -       pipe
>   flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user}-editor <at> 
> ${extension}
> sympasubscribe     unix  -       n       n       -       -       pipe
>   flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user}-subscribe <at> 
> ${extension}
> sympaunsubscribe     unix  -       n       n       -       -       pipe
>   flags=RF user=sympa argv=/usr/local/libexec/sympa/queue ${user}-unsubscribe <at> 
> ${extension}
> sympabounce     unix  -       n       n       -       -       pipe
>   flags=RF user=sympa argv=/usr/local/libexec/sympa/bouncequeue ${user}
> 
> And now the aliases that are autogenerated for one virthost:
> 
> ## This virtual aliases file for domain lists.hostcompanion.com is dedicated
> to Sympa Mailing List Manager
> ## You should edit your Postfix main.cf file to declare it
> ##
> /^lists\.hostcompanion\.com$/            xxx
> ##
> #------------------------------ test1: list alias created 06 Sep 2011
> /^(test1)-(request|editor|owner|subscribe|unsubscribe)\ <at> lists\.hostcompanion
> \.com$/    $1+lists.hostcompanion.com <at> sympa$2.
> /^(test1)\ <at> lists\.hostcompanion\.com$/
> $1+lists.hostcompanion.com <at> sympalist.
> 
> And finally, the hack that I stick in the top of that same file to handle the
> bounces, posts, etc.:
> 
> # this seems to be necessary, probably belongs somewhere else
> /^(sympa)\ <at> lists\.hostcompanion\.com$/
> $1+lists.hostcompanion.com <at> sympalist.
> /^(listmaster)\ <at> lists\.hostcompanion\.com$/
> $1+lists.hostcompanion.com <at> sympalist.
> /^(.*+owner\ <at> lists\.hostcompanion\.com$/
> $1+lists.hostcompanion.com <at> sympaowner.
> 
> I'm pretty lost here - any input is appreciated.
> 
> Thanks,
> 
> Charles

Eileen Roach | 8 Sep 2011 18:49
Picon
Favicon

Sympa as Groups Management Tool

  We are considering using Sympa for our campus Identity Infrastructure 
Groups Management tool -- so for groups other than mailing lists too.  
Are there other campus's doing the same? And if so, any pros/cons that 
we should consider?

Thanks in advance,

Eileen

--

-- 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
  Eileen Roach
  Programmer/Analyst, Identity Management Group
  California Polytechnic State University, San Luis Obispo
  Phone: (805)756-6214
  E-mail: eroach@...

Victoriano Giralt | 8 Sep 2011 19:24
Picon
Favicon

Re: Sympa as Groups Management Tool


Eileen Roach escribió:
|  We are considering using Sympa for our campus Identity Infrastructure
| Groups Management tool -- so for groups other than mailing lists too.
| Are there other campus's doing the same? And if so, any pros/cons that
| we should consider?

Hi Eileen, I've been toying with such an idea for some time, as it seems
really natural to form groups around mailing lists:

+ The invitation system is tested in the wild and works (most of the time)
+ People are more or less accustomed to the group feeling a list gives
+ With Sympa group members can come from several "inside" sources as well
as from the outside.

So this seems like all pros :)

On the other hand a group can be seen as something richer than just
belonging to a list of subscribers. People in groups can have roles, even
several of them. I reckon that lists also have roles, three of them in
Sympa: owner, moderator/editor and subscriber and that you can use, so to
say, "role lists", if you are in a given list you belong to a role, but
them, how do you map that to a given group, for example, a class. This
takes you into list combinatorial explosion territory.

I'm working on a plugin for MoinMoin Python wiki that will use Sympa lists
both for access control and for wiki farms (thanks to Sympa SOPA
interface): one list -> one wiki, list role -> wiki group, bound through
SAML asserions to the identity of the user in both systems.

But there are situations where you need richer groups with richer role sets
and then, you need a dedicated group manager, lightweight (<shameless plug>
~ like the work done by some of my colleagues[1][2]</shameless plug>) or
Grouper sized[3].

| Thanks in advance,
You are welcome.

[1]http://www.eunis.ie/abstracts/OAuth2Lib_JoseAlfonsoAccino-ElenaLozano_Abstract.pdf
[2]http://www.eunis.ie/papers/OAuth2Lib_JoseAlfonsoAccino-ElenaLozano_Paper.pdf
[3]http://www.internet2.edu/grouper/software.html

--
Victoriano Giralt
Systems Manager
Central ICT Services
University of Malaga
SPAIN
-
A: Yes.
| > Q: Are you sure ?
|> >> A: Because it reverses the logical flow of conversation.
|>> >>> Q: Why is top posting annoying in email ?
Thomas Berry | 8 Sep 2011 19:55
Picon
Picon
Favicon

Re: Sympa as Groups Management Tool


We took the opposite approach: our list server member management was 
incorporated with our existing group management which is stored in a 
centrally managed LDAP directory.  Sympa has the ability to integrate 
with LDAP and provides two level LDAP query capability which allowed us 
to integrate mailing list membership with groups where the member's 
distinguished names (DN) point to the members' entries (where their 
email addresses are found) also stored in the LDAP directory.

Although it might not be necessary now (we're still running 6.0), at the 
time we had to disable Sympa's ldap-to-list synchronizations.  Instead, 
we went with the following list update model:

1) Updates are made to list members stored in Sympa's databases when any 
changes to an LDAP group are made.

The update is initiated by the groups web interface that was developed 
to manage the LDAP groups; the interface remotely calls a script (ssh) 
on the list server which was an adaption of Sympa's "reload_list_config" 
function

2) Updates are made to list members ... when an email message is posted 
to a mailing list.

Instead of doing this, we could have just had a replica LDAP directory 
dedicated to our list server, but then there might still be latency 
between the time a group is updated and the time that Sympa synchronizes 
the lists.  We had a requirement to provide real-time updates between 
LDAP group membership and list membership.

We also have basic mailing list configuration settings stored in the 
LDAP directory.  This was done to simplify the list configuration 
management. We used Sympa's ability to extend the list-family and 
retrieved and translated the list settings stored in the LDAP directory 
into Sympa's list config settings when a list is updated. All list 
configuration in Sympa's web interface were disabled.  Although setting 
this up was complicated and required a lot of work upfront, it has 
greatly reduced the complexity to the users who can self-provision their 
own mailing lists.

We now have almost 6000 mailing lists and growing.  All of which are 
associated with groups that are also used for other purposes, primarily 
authentication of other applications also integrated with LDAP.

Thomas

On 09/08/2011 09:49 AM, Eileen Roach wrote:
>    We are considering using Sympa for our campus Identity Infrastructure
> Groups Management tool -- so for groups other than mailing lists too.
> Are there other campus's doing the same? And if so, any pros/cons that
> we should consider?
>
> Thanks in advance,
>
> Eileen
>

Warren Anderson | 8 Sep 2011 19:59
Picon
Favicon

Re: Sympa as Groups Management Tool

Hi,

I think one of the main reasons NOT to use sympa as a group management 
tool is the relative difficulty in leveraging your groups in other 
services. The large scientific collaboration I belong to (www.ligo.org) 
uses LDAP paired with Grouper. Grouper is extremely flexible for group 
management, can draw entities to group from an LDAP, and can then write 
group management information into LDAP (both by writinggroup entries 
into LDAP and by populating the multivalued isMemberOf attribute for 
the entities in a group). Very many tools have the ability to pull 
information out of LDAP without any modification (including sympa, 
which is what we do). For those tools that do not, whatever language 
they are written will almost surely have an LDAP module or library to 
make accessing the group information relatively straightforward to 
code. 

Perhaps your needs are not so varied, but we require groups for ACLs 
to several different brands of wiki, three different version control 
systems, three brands of bug/request tracking systems, posix/unix 
filesystems, grid computing (Globus) accounts, several in-house 
applications, web pages, mailing lists, etc. And to further complicate 
matters, our scientists use at least eight different linux distros, 
solaris, OS X, and at least three flavors of MS Windows. The amount 
of software we would have to write to leverage sympa groups for all of 
this would have been prohibitive. But as I say, your mileage may vary.

Cheers,
Warren

On Sep 8, 2011, at 11:24 , Victoriano Giralt wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Eileen Roach escribió:
> |  We are considering using Sympa for our campus Identity Infrastructure
> | Groups Management tool -- so for groups other than mailing lists too.
> | Are there other campus's doing the same? And if so, any pros/cons that
> | we should consider?
> 
> Hi Eileen, I've been toying with such an idea for some time, as it seems
> really natural to form groups around mailing lists:
> 
> + The invitation system is tested in the wild and works (most of the time)
> + People are more or less accustomed to the group feeling a list gives
> + With Sympa group members can come from several "inside" sources as well
> as from the outside.
> 
> So this seems like all pros :)
> 
> On the other hand a group can be seen as something richer than just
> belonging to a list of subscribers. People in groups can have roles, even
> several of them. I reckon that lists also have roles, three of them in
> Sympa: owner, moderator/editor and subscriber and that you can use, so to
> say, "role lists", if you are in a given list you belong to a role, but
> them, how do you map that to a given group, for example, a class. This
> takes you into list combinatorial explosion territory.
> 
> I'm working on a plugin for MoinMoin Python wiki that will use Sympa lists
> both for access control and for wiki farms (thanks to Sympa SOPA
> interface): one list -> one wiki, list role -> wiki group, bound through
> SAML asserions to the identity of the user in both systems.
> 
> But there are situations where you need richer groups with richer role sets
> and then, you need a dedicated group manager, lightweight (<shameless plug>
> ~ like the work done by some of my colleagues[1][2]</shameless plug>) or
> Grouper sized[3].
> 
> | Thanks in advance,
> You are welcome.
> 
> [1]http://www.eunis.ie/abstracts/OAuth2Lib_JoseAlfonsoAccino-ElenaLozano_Abstract.pdf
> [2]http://www.eunis.ie/papers/OAuth2Lib_JoseAlfonsoAccino-ElenaLozano_Paper.pdf
> [3]http://www.internet2.edu/grouper/software.html
> 
> - --
> Victoriano Giralt
> Systems Manager
> Central ICT Services
> University of Malaga
> SPAIN
> - -
> A: Yes.
> | > Q: Are you sure ?
> |> >> A: Because it reverses the logical flow of conversation.
> |>> >>> Q: Why is top posting annoying in email ?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org
> 
> iD8DBQFOaPouV6+mDjj1PTgRApt6AJ97+hW8BPwVIEUlNbpmRiguSIcEtACgo8ix
> 59apr6jgOW1x6sePwM/ZpvI=
> =KnMk
> -----END PGP SIGNATURE-----

+================[ WARREN G. ANDERSON ]====================+
| PO Box 413, Dept. of Physics, Milwaukee, WI 53201, USA   |
|   CANADA: (403) 212 1426          USA: (414) 212 5446    |
+==========================================================+

Attachment (smime.p7s): application/pkcs7-signature, 1904 bytes
Dempsey, Steve AZ | 8 Sep 2011 20:16
Picon
Favicon

RE: Sympa as Groups Management Tool

Consider carefully what these groups will control before you
extend a mailing list for other purposes.  Groups that manage
resources may have real costs or security concerns needing
more oversight than a list moderator can provide.

We usually go the other direction - use automation to derive
the mailing list members from a security group, or merge
(include) a security group with a static list so a few extra
members can participate in the list without obtaining the
higher privilege.

-Steve

-----Original Message-----
From: sympa-users-request@...
[mailto:sympa-users-request@...] On Behalf Of Eileen Roach
Sent: Thursday, September 08, 2011 9:49 AM
To: sympa-users@...
Subject: [sympa-users] Sympa as Groups Management Tool

  We are considering using Sympa for our campus Identity Infrastructure 
Groups Management tool -- so for groups other than mailing lists too.  
Are there other campus's doing the same? And if so, any pros/cons that 
we should consider?

Thanks in advance,

Eileen

--

-- 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
  Eileen Roach
  Programmer/Analyst, Identity Management Group
  California Polytechnic State University, San Luis Obispo
  Phone: (805)756-6214
  E-mail: eroach@...


Gmane