GroupServer is an open source collaboration platform that enables users to interact in groups, using email and the web. This document aims to help with evaluating GroupServer, as well as planning and administering GroupServer deployments. It describes the current features and functioning of GroupServer, as well as improvements that are scheduled, or to be scheduled. It describes aspects of GroupServer's functioning that are determined by how GroupServer is configured, or customised, behind the scenes, but does not provide details of the technical architecture, installation or back-end administration.
GroupServer users interact in groups, which are located on a site, by exchanging messages. Users are members of groups, which are run by group administrators, while the site itself is run by a site administrator.
A GroupServer instance can support multiple sites.
Users interact with GroupServer using email and the site interface. Groups and sites are also administered using the site interface. Behind the scenes administration is carried out using the Zope Management Interface (zmi ), and via a terminal.
Each user in a GroupServer instance has a profile (account) that is common to all the sites in the instance. The profile stores all the user's personal information, an image associated with the user, the user's nickname, and the user's email addresses. This information is presented on the user's profile page,which also summarises the posts that have been made by the user. A profile is created when the user signs up with GroupServer group for the first time, or an administrator adds a new person to a group.
By default, the personal information stored by GroupServer conforms to the hCard microformat specification. However, the personal information that is stored on each profile can be configured for each GroupServer instance.
While anonymous visitors can navigate to user profiles, only the name, image and the public and private (but not secret) groups that the user belongs to are shown. The other profile attributes are only visible to logged in users.
Each user can define a nickname which is used in the url of their profile. This nickname is similar to the web address in Flickr.
All dates shown on a site show the timezone that is being used, and adjust automatically for daylight saving, if daylight saving is applicable to the timezone in effect. When a user joins a site, their timezone is set to the site timezone. A user can configure GroupServer to show dates in their own timezone.
Users can upload an image that appears on all posts made by the user, and on the user's profile page. The site converts the images so they are an appropriate size for each context.
Each user can add multiple email addresses to his or her profile. These email addresses are unique to the user (so no two users can share the same address) because the email addresses are used to identify the user when he or she sends email messages to groups, or logs in.
A user must verifythat they control each email address that they add to their profile. This ensures that that the user can access the email addresses that are entered, and prevents the addition of email addresses without consent of their owner. A user can make multiple attempts to verify an email address, and can re-verify an email address that has been set to unverified as a result of bouncing.
Users are blocked from adding disposable email addresses ― provided by services such as dodgit.com and spambox.us ― to their accounts.
GroupServer can be configured to hide email addresses on a site-by-site basis. When email addresses are hidden, a user can contact someone else by using the request contact form on the user's profile. This emails the recipient of the request a short message explaining who is trying to get in contact, and the email address of the user requesting contact.
Each user's profile displays the latest posts made, and files posted by the user. The visibility of these posts is determined by the privacy setting of the group they were made to, and by the group memberships of the viewing user.
Signing up to a GroupServer site creates a user profile. There are four ways that someone can join a group.
A join and leave log enables a Group Administrator to view changes to the membership of their group.
A user can sign up and join a public group via the web or email.
When registering via the web, the user initiates the registration process by entering their email address. An email is sent to the user, requesting that they verify the email address, and the users is asked to complete a profile, and optionally join public groups on the site. If the user has verified their email address by the time they have completed their profile, they are taken to the group they have joined. If the email address is not yet verified, the user is taken to page that prompts them to check their email for the verification request. When the user clicks the email address verification link that was emailed to them, they are logged in to the site, and asked to set a password. The user can generate further email address verification requests, if necessary.
A new or existing user can request membership of a private group, stating a reason that they should be allowed to join the group. When a user requests membership of a group, GroupServer sends a message to the Group Administrators, showing the email address and reason given by the person requesting to join, and links that enable the Admin to accept or decline the request.
A group administrator can invite existing and new site members to join a group in the following three ways.
In all of the above cases, the users must accept an invitation before they become a group member. This ensures the following.
In the two cases where new user accounts can be created, the Group Administrator can add information to the users' profiles, while creating them. If the email address specified by the group administrator belongs to an existing user, the user's profile remains unchanged. The Group Administrator can also define each invited user's message delivery settings.
A Group Administrator can also add individual and bulk members to a group, without requiring the user to take any action.
A user can log in to a site to edit profiles, and make posts to groups using the Web interface. Optionally, users can stay logged in over multiple sessions.
The password reset feature emails the user a link that enables them to set a new password. GroupServer never sends passwords out by email.
A group is the primary location for interaction on GroupServer. It is made up of three components:
The behaviour of the group is primarily defined by two things: the type of group, and the privacy settings of the group. Members are either invited to join a group, or join and leave of their own accord.
The different types of groups primarily differ in who can post and receive messages. In the common discussion group all the members can post and receive messages. Only some members can post messages to an announcement group, while all the members receive the messages. In a closed group, members can view but not post messages and files. While these three group types are defined by GroupServer, it is possible to create custom group types via the zmi. For example, with a support group, anyone — including non members — can post, though only the members receive the posts.
While the group-type defines the basic behaviour of the group, specific behaviour can also be configured by a zmi administrator. For example, the messages from any group can be altered so email replies go to either the author of the message or the group.
The group type is determined by a Site Administrator when the group is created. The group type can not be changed via the site interface, once the group has been started. It is possible to change a the type of a group via the zmi.
There are three privacy settings, which only a Site Administrator can alter. From most open to most restrictive, the group privacy settings are as follows.
The privacy and security settings are more nuanced than the three settings above, and a zmi administrator can alter the specific security and privacy settings. However, experience has shown these to be the most useful combination of settings.
The privacy of the group is explained, in simple terms, on the pages where a group member can post. This allows the member to find out what the privacy is when it matters.
Site administrators do not follow the same rules as other users of GroupServer: and administrator can view all posts, files, and users on a site, regardless of group membership.
The members of a GroupServer group are listed on the members page. In public and private groups, the members page is visible to non-members. In public groups, members are only listed on the members page if they have made one or more posts. (GroupServer values the right to “lurk in peace”).
When a user leaves or joins a group, a message is sent to user to notify them of the change that has taken place. A message is also sent to each Group Administrator.
The group administrators' role is usually related to member management tasks. The group administrator can carry out the following tasks.
A Site Administrator can carry out all group member management tasks that can be carried out by a Group Administrator. In addition, a Site Administrator can grant group administrator status to one or more group members, and revoke that status.
The mailing list for the group is tasked with determining who can post to the group, and which members should receive the posts that are made to the group. Most of the capabilities of the mailing-list portion of the group is discussed below.
On the web, the group consists of a series of pages related to the group. The home page for the group shows the following.
A Site Administrator can add arbitrary content to be displayed on the group home page, including, images, links, lists, headings and paragraphs.
The appearance of the group on the web is based on the appearance of the site.
Arbitrary pages in the group context can be added and edited via the zmi. Group members can be allowed to edit these pages using the Structured Content Editor.
Only site administrators can start groups , delete groups and alter the group attributes.
The following information is required to start a group.
A Site Administrator can effectively delete a group while retaining an archive of its posts by removing all its members, and setting the group privacy to secret. Only an instance administrator can truly delete a group, and even then posts must be explicitly deleted from the database to remove archives.
A logged-in user can leave a group via the group's home page. A user can also leave a group by by sending an email to the group address with the subject line unsubscribe.
Users can post a message to a group using email or the web. All posts made to a group, are emailed to all group members, according to their delivery settings. Depending an each group's privacy settings, all messages posted are stored on the site and are visible to users with the required group memberships within the group context (as well as on the site home page and in search results).
Messages are normally grouped into topics. Topics are determined by examining the subject-line of the email: messages with the same subject line belong to the same topic. In the group context, messages are displayed in the following ways.
On the Topic and Post views, an image of the author of each post is shown, and a short link to each post is provided (to enable users to link to individual posts).
To increase the usability and utility of the messages, GroupServer formats the messages when it displays them on the Web.
First, the excessive quoting or prior posts at the bottom of the message is hidden. The bottom quoting is often added by email clients, and it contains no extra information, as the prior posts are visible in the topic. Hiding the bottom quoting is based on a number of heuristics, so it can detect quoting with minimal false positives, even if a standard quoting-convention is not used. However, if it does get it wrong, the user has the option of seeing the hidden text.
To protect privacy, email addresses in the text of posts are replaced with the text "<email obscured>". This reduces the collection of addresses by spammers and prevents people who do not belong to the group from contacting the group members.
As well as email addresses, the following link types are recognised and processed accordingly.
While the messages are formatted and presented as part of a HTML Web-page, HTML email messages are not used, instead the plain-text form of the message is used. This is to ensure the security of the system.
Attachments are linked at the bottom of each message. If an image is attached a thumbnail is shown, so the reader can decide if he or she wants to view the entire image. All images in a topic are put into a gallery, so the reader can view them without bothering with reading the text!
The final formatting change is to convert the message so it uses the UTF-8 (Unicode) character encoding. This enables a wide range of character sets to be used within the same topic.
GroupServer performs some minor alterations of email messages before they are sent out.
First, a footer added to the bottom of every message. The footer can be configured by an instance administration, but by default message footer contains the following.
A GroupServer Site can be configured to allow Group Administrators to add custom text to message footers for a group.
reply-to field of the email message is also set
at this stage.
reply-to field is set to the group email address
for discussion groups, but it is set to the message author in
Via the site interface, a user can specify individual message delivery settings for each group, choosing one email per post, topic digest, and Web only. When receiving email, a user can also specify one of their email addresses for group-specific message delivery, independent of their site default email address. A user can also enable and disable digest mode via email.
A topic digest is an email message that lists the latest topics in a group. For each topic the digest shows the title, the number of posts, the date of the last post, and a link to the topic. A topic digest is sent every day, if there are posts, and every week, whether there are posts or not.
If the group member does not want to receive any email messages from the group, he or she can set the delivery setting to Web only. This option is also used when the user wants to follow the messages using the Web feeds of the latest posts in the group, on the site or by a person — rather than use an email client. To access the web feed for private and secret groups the user needs to be logged in to the GroupServer web site.
There are three primary restrictions to posting messages: requiring verified email addresses, limiting the posting rate, and moderating messages from members. There are also some general criteria for blocking messages.
A site administrator can define a posting rate for each group: the number of posts that a user can make in a period of time. When a user has exceed the posting rate, both the email and web interfaces inform the user that they can not post, and when the user will be able to post again.
A group administrator can determine the moderation status of group, choosing between the following settings.
When a group member who is moderated makes a post, GroupServer sends a notification email to all moderators for the group. The moderation notification email contains links that enable the moderator to approve or decline the post.
A group administrator can also assign the role of moderator to one or more group members, and revoke that role.
Besides moderation messages can be automatically blocked based on who posted it, the email address that the message was posted from, the contents of the message, what sort of email-software produced the message, what properties the user who sent the message had set and the size of the message.
Individual users can be banned from posting to a group or a site. These users can add or remove email addresses, but they will still be banned from posting.
As well as blocking users, specific email addresses can be blocked from posting to a group or site. This prevents a user from creating a new profile and posting.
GroupServer also blocks messages based on message contents. Normally, this is used to block out of office messages from being posted to a group, but the system can be configured to block any phrase. However, there is no mechanism to quarantine messages for later approval based on the message contents.
Messages are also blocked if
The required profile properties can be set at both the site and group level, so specific group can have tighter requirements on profile-properties than the site.
Finally, an instance administrator can determine the maximum size of message that can be posted to GroupServer.
A user's post can be marked by the user or a Group Administrator as “hidden”. The post, along with a record of the date, the reason for marking as deleted, and the user who marked the message as deleted is accessible to group administrators.
An instance administrator can delete a message from the archive, but it is not possible to delete a message via the site interface.
GroupServer automatically responds to some messages, such as Subscribe and Unsubscribe messages. It has no generic auto-responders but these could be implemented relatively easily.
Files can be shared as attachments to posts made by email, or by the web. In both cases, a link to the files is distributed in the email version of the post, rather than sending out the files as attachments. This prevents people with slow Internet connections, or mailbox size restrictions from becoming overwhelmed with large attachments.
Files are displayed on the Topic and Post pages. The Topics list on the Group page shows the number of files associated with each Topic. In addition, Web feeds are available of the latest files posted on the site, in a group, and by a particular person.
An instance administrator can configure Groupserver to make files available to unauthenticated users for a defined period after they are uploaded.
Files are virus-checked as they are uploaded.
Groups are organised into sites.
The site home page displays the following.
Topic summaries on the site home page, group home page and search results show keywords that are automatically extracted from each topic to increase “information scent”. The keywords are extracted using the TFIDF (term frequency inverse document frequency) algorithm. This extracts words that occur frequently in the topic but infrequently in the rest of the site.
The search feature can show topics, posts or files visible to the current user that contain a specified search string. Searches can be restricted to a specific group or user, or both. It is possible to implement search of user profiles.
An instance administrator can define a site title, logo and page footer that appear on all pages.
Usage statistics for all public and private groups are visible to anonymous site visitors though the site interface. Statistics for secret groups are visible to group members. The usage statistics show the number of posts, and the number of group members who made posts (authors) per month. The usage statistics can be downloaded in CSV format.
An instance administrator can add a Google Analytics tracking code to a site, so that Google Analytics can be used to analyse site usage.
An instance administrator can obtain ad hoc statistics by viewing logs, and running SQL queries on the message database tables (see “System Usage Logging”).
Pages and content can be added to sites and and edited either via the Structured Content editor, or via the Zope Management Interface (see Behind the Scenes). All valid XHML1 or XHTML2 can be used. This supports the display of external content such as Custom features such as a YouTube Movie, Flickr Badge, Google Calendar, Google Map. Examples of site content created in this way can be found at GroupServer.org and Remote Huts.
An instance administrator can select a site colour scheme, from a list of predefined colour schemes.
An individual visual style, including fonts, colours and layout can determined for each site, but this currently requires instance-level administration.
A site administrator can set the default timezone for a site. The site timezone determines the timezone for all dates displayed on the site, for non-logged-in visitors, and the timezone for all new users who register to join groups on the site.
GroupServer provides the basic infrastructure to support a multi-lingual interface. The interface also supports UTF-8, so that a wide range of character sets can be displayed.
Sites include the following help resources.
A site can be addressed via the web and email at any domain for which the DNS can be administered.
The open source WYMEditor component (http://wymeditor.org) is used to edit structured content in GroupServer sites. The structured content editor outputs valied XHML2 and can be used to create the following page elements.
The Structured content editor supports multiple-users, and version-tracking. This is a functional equivalent to a wiki, that does not require editors to learn a markup language.
The Structured Content Editor is used in the following places.
GroupServer only accepts email from addresses that are associated with a member of the group that they are addressed to. GroupServer sends notifications in response to emails from addresses that are not associated with a group member, as often these are sent by users who have incorrectly configured email settings.
An instance administrator can implement a spam-management tool such as SpamAssasin in conjunction with GroupServer, to control spam arriving at the email server used by a site. This is necessary for performance reasons, to reduce the number of emails that must be checked by GroupServer to determine whether how they should be handled. This also limits the possibility of spam email being posted to groups.
All posted files are checked for viruses as they are uploaded.
An email address is said to be bouncing if the server that controls the address rejects the messages that are delivered there. GroupServer detects when a messages from a group bounces; by default, if an address bounces on five different days in any sixty day period, the address is set to unverified. The user is notified of this action by an email message that is sent to all non-bouncing addresses associated with the user account.
GroupServer identifies and terminates "Out of Office" reply loops. The loop-detection uses a variety of configurable methods to recognise automatically generated email.
GroupServer does not currently support integration with external authentication systems, but its technical architecture does enable this to be implemented. Implementation of Open ID is anticipated.
Day to day administration of a GroupServer site can mostly be carried out via the site interface. Behind the scenes, there is wide scope for custom administration and customisation. Some behind the scenes administration can be carried out without specialist technical skills. The scope of what can be achieved behind the scenes expands proportionally to skill and experience with Zope, Python, TAL, SQL, and GroupServer itself.
A GroupServer instance can support multiple sites. User profiles are common to all sites in an instance.
An instance administrator can configure the following for all sites in an instance.
The GroupServer system log records the following
An instance administrator can view a log of all messages received and sent by the Postfix email server. The database tables containing stored messages can also be queried by an instance administrator.
The technical architecture of a GroupServer instance requires a set of server components, including Zope, Apache, Postfix and PostgreSQL. A single set of server components, on a single physical server, can support multiple GroupServer instances. Alternatively, the components that support a single GroupServer instance can be distributed across multiple machines.