Every project has a default set of core mailing lists.
The despots of a project are the moderators of all lists and will receive administrative messages from time to time from the ezmlm list management system.
Messages sent to the announce@ address get automatically copied to the dev@ and user@ lists. Additionally, a blog entry is added to the Haus News blog.
The user@ list is intended for user-based discussions of the project.
The dev@ list is intended for developer-centric disucssions of project implementation, direction, and management. Using addcommitter to add a committer to a project will also cause the user's @codehaus.org address to be subscribed to the dev@ list.
The scm@ list receives source change notifications and Jira change notifications. Some of the membership of this list is automatically handled using the normal project management tools to control committer access. Using addcommitter to add a commiter to a project will also cause the user's @codehaus.org address to be subscribed to the scm@ list.
The despots@ list acts as a central point-of-contact for all despots of a project. All of the membership of this list is automatically handled using the normal project management tools to control despot priveledges. Using adddespot to add a despot to a project will also cause the user's @codehaus.org address to be subscribed to the despots@ list.
Information about a particular mailing list can be printed with
If your archives appear to suck, make sure you are using the new archive system. In your ~project/haus.d/httpd.conf, ensure that your archive.project.codehaus.org site has a single RewriteRule as:
where yourproject is your project name, of course
All administration can be done through email, though command-line tools are also available.
When a moderation request is generated, typically due to a non-subscriber attempting to post a message, the despots will receive an email with instructions. Most moderation is handled simply by replying to the appropriate address(es).
Replying to the -reject address will reject the message that requires moderation. You can simply ignore the moderation request and the message will be implicitly rejected after a while.
Replying to the -accept address will accept this message (and only this message) for posting to the list.
Replying to the -allow address will add the sender's address to a whitelist so he can continue to post without moderation in the future. He is not subscribed to the list. This is useful to allow postings from Jira, Confluence or SCM modules mailing commits messages to a list.
Adding addresses that can post
Most likely you want your lists to be set up so that only subscribers can post. In this case, if you want to allow certain addresses to post without being subscribed use the following command:
Bouncing messages from unsubscribed posters
In the default configuration, messages from unsubscribed users are send to the moderators. If you want to bounce them right away you'll have to edit the
editor file in the list directory. Replace this line
with these ones:
Note that the only linebreaks are before the | character. If in doubt have a look at the Neo mailing lists.
Changing the allowed message size
To change the maximum allowed message size edit the
msgsize file in the list directory. If it exists it is assumed to contain
max is the maximum size in bytes of an acceptable message body, and
min the corresponding minimal size. Either will be ignored if zero or omitted. If the
ezmlm-reject command line specifies the list directory, messages not meeting the size criteria are rejected. Default is