The list moderators have more limited permissions; - they are not able to change any list configuration variable, but - they are allowed to tend to pending administration requests, - including approving or rejecting held subscription requests, and - disposing of held postings. Of course, the list - administrators can also tend to pending requests. - -
In order to split the list ownership duties into - administrators and moderators, you must - set a separate moderator password, - and also provide the email - addresses of the list moderators. Note that the field you - are changing here specifies the list administrators.''')), - - ('moderator', config.EmailList, (3, WIDTH), 0, - _("""The list moderator email addresses. Multiple - moderator addresses, each on separate line is okay."""), - - _('''There are two ownership roles associated with each mailing - list. The list administrators are the people who have - ultimate control over all parameters of this mailing list. They - are able to change any list configuration variable available - through these administration web pages. - -
The list moderators have more limited permissions; - they are not able to change any list configuration variable, but - they are allowed to tend to pending administration requests, - including approving or rejecting held subscription requests, and - disposing of held postings. Of course, the list - administrators can also tend to pending requests. - -
In order to split the list ownership duties into - administrators and moderators, you must - set a separate moderator password, - and also provide the email addresses of the list moderators in - this section. Note that the field you are changing here - specifies the list moderators.''')), - - ('description', config.String, WIDTH, 0, - _('A terse phrase identifying this list.'), - - _('''This description is used when the mailing list is listed with - other mailing lists, or in headers, and so forth. It should - be as succinct as you can get it, while still identifying what - the list is.''')), - - ('info', config.Text, (7, WIDTH), 0, - _('''An introductory description - a few paragraphs - about the - list. It will be included, as html, at the top of the listinfo - page. Carriage returns will end a paragraph - see the details - for more info.'''), - _("""The text will be treated as html except that - newlines will be translated to <br> - so you can use links, - preformatted text, etc, but don't put in carriage returns except - where you mean to separate paragraphs. And review your changes - - bad html (like some unterminated HTML constructs) can prevent - display of the entire listinfo page.""")), - - ('subject_prefix', config.String, WIDTH, 0, - _('Prefix for subject line of list postings.'), - _("""This text will be prepended to subject lines of messages - posted to the list, to distinguish mailing list messages in in - mailbox summaries. Brevity is premium here, it's ok to shorten - long mailing list names to something more concise, as long as it - still identifies the mailing list. - You can also add a sequencial number by %%d substitution - directive. eg.; [listname %%d] -> [listname 123] - (listname %%05d) -> (listname 00123) - """)), - - ('anonymous_list', config.Radio, (_('No'), _('Yes')), 0, - _("""Hide the sender of a message, replacing it with the list - address (Removes From, Sender and Reply-To fields)""")), - - _('''Reply-To: header munging'''), - - ('first_strip_reply_to', config.Radio, (_('No'), _('Yes')), 0, - _('''Should any existing Reply-To: header found in the - original message be stripped? If so, this will be done - regardless of whether an explict Reply-To: header is - added by Mailman or not.''')), - - ('reply_goes_to_list', config.Radio, - (_('Poster'), _('This list'), _('Explicit address')), 0, - _('''Where are replies to list messages directed? - Poster is strongly recommended for most mailing - lists.'''), - - # Details for reply_goes_to_list - _("""This option controls what Mailman does to the - Reply-To: header in messages flowing through this - mailing list. When set to Poster, no Reply-To: - header is added by Mailman, although if one is present in the - original message, it is not stripped. Setting this value to - either This list or Explicit address causes - Mailman to insert a specific Reply-To: header in all - messages, overriding the header in the original message if - necessary (Explicit address inserts the value of reply_to_address). - -
There are many reasons not to introduce or override the - Reply-To: header. One is that some posters depend on - their own Reply-To: settings to convey their valid - return address. Another is that modifying Reply-To: - makes it much more difficult to send private replies. See `Reply-To' - Munging Considered Harmful for a general discussion of this - issue. See Reply-To - Munging Considered Useful for a dissenting opinion. - -
Some mailing lists have restricted posting privileges, with a - parallel list devoted to discussions. Examples are `patches' or - `checkin' lists, where software changes are posted by a revision - control system, but discussion about the changes occurs on a - developers mailing list. To support these types of mailing - lists, select Explicit address and set the - Reply-To: address below to point to the parallel - list.""")), - - ('reply_to_address', config.Email, WIDTH, 0, - _('Explicit Reply-To: header.'), - # Details for reply_to_address - _("""This is the address set in the Reply-To: header - when the reply_goes_to_list - option is set to Explicit address. - -
There are many reasons not to introduce or override the - Reply-To: header. One is that some posters depend on - their own Reply-To: settings to convey their valid - return address. Another is that modifying Reply-To: - makes it much more difficult to send private replies. See `Reply-To' - Munging Considered Harmful for a general discussion of this - issue. See Reply-To - Munging Considered Useful for a dissenting opinion. - -
Some mailing lists have restricted posting privileges, with a - parallel list devoted to discussions. Examples are `patches' or - `checkin' lists, where software changes are posted by a revision - control system, but discussion about the changes occurs on a - developers mailing list. To support these types of mailing - lists, specify the explicit Reply-To: address here. You - must also specify Explicit address in the - reply_goes_to_list - variable. - -
Note that if the original message contains a - Reply-To: header, it will not be changed.""")), - - _('Umbrella list settings'), - - ('umbrella_list', config.Radio, (_('No'), _('Yes')), 0, - _('''Send password reminders to, eg, "-owner" address instead of - directly to user.'''), - - _("""Set this to yes when this list is intended to cascade only - to other mailing lists. When set, meta notices like - confirmations and password reminders will be directed to an - address derived from the member\'s address - it will have the - value of "umbrella_member_suffix" appended to the member's - account name.""")), - - ('umbrella_member_suffix', config.String, WIDTH, 0, - _('''Suffix for use when this list is an umbrella for other - lists, according to setting of previous "umbrella_list" - setting.'''), - - _("""When "umbrella_list" is set to indicate that this list has - other mailing lists as members, then administrative notices like - confirmations and password reminders need to not be sent to the - member list addresses, but rather to the owner of those member - lists. In that case, the value of this setting is appended to - the member's account name for such notices. `-owner' is the - typical choice. This setting has no effect when "umbrella_list" - is "No".""")), - - _('Notifications'), - - ('send_reminders', config.Radio, (_('No'), _('Yes')), 0, - _('''Send monthly password reminders?'''), - - _('''Turn this on if you want password reminders to be sent once - per month to your members. Note that members may disable their - own individual password reminders.''')), - - ('welcome_msg', config.Text, (4, WIDTH), 0, - _('''List-specific text prepended to new-subscriber welcome - message'''), - - _("""This value, if any, will be added to the front of the - new-subscriber welcome message. The rest of the welcome message - already describes the important addresses and URLs for the - mailing list, so you don't need to include any of that kind of - stuff here. This should just contain mission-specific kinds of - things, like etiquette policies or team orientation, or that kind - of thing. - -
Note that this text will be wrapped, according to the - following rules: -
However, not all mail readers are standards compliant yet, - and if you have a large number of members who are using - non-compliant mail readers, they may be annoyed at these - headers. You should first try to educate your members as to - why these headers exist, and how to hide them in their mail - clients. As a last resort you can disable these headers, but - this is not recommended (and in fact, your ability to disable - these headers may eventually go away).""")) - ) - # Suppression of List-Post: headers - rtn.append( - ('include_list_post_header', config.Radio, - (_('No'), _('Yes')), 0, - _('Should postings include the List-Post: header?'), - _("""The List-Post: header is one of the headers - recommended by - RFC 2369. - However for some announce-only mailing lists, only a - very select group of people are allowed to post to the list; the - general membership is usually not allowed to post. For lists of - this nature, the List-Post: header is misleading. - Select No to disable the inclusion of this header. (This - does not affect the inclusion of the other List-*: - headers.)""")) - ) - - # Discard held messages after this number of days - rtn.append( - ('max_days_to_hold', config.Number, 7, 0, - _("""Discard held messages older than this number of days. - Use 0 for no automatic discarding.""")) - ) - - return rtn - - def _setValue(self, mlist, property, val, doc): - if property == 'real_name' and \ - val.lower() <> mlist.internal_name().lower(): - # These values can't differ by other than case - doc.addError(_("""real_name attribute not - changed! It must differ from the list's name by case - only.""")) - elif property == 'new_member_options': - newopts = 0 - for opt in OPTIONS: - bitfield = config.OPTINFO[opt] - if opt in val: - newopts |= bitfield - mlist.new_member_options = newopts - elif property == 'subject_prefix': - # Convert any html entities to Unicode - mlist.subject_prefix = Utils.canonstr( - val, mlist.preferred_language) - else: - GUIBase._setValue(self, mlist, property, val, doc) - - def _escape(self, property, value): - # The 'info' property allows HTML, but lets sanitize it to avoid XSS - # exploits. Everything else should be fully escaped. - if property <> 'info': - return GUIBase._escape(self, property, value) - # Sanitize tags but nothing else. Not the best - # solution, but expedient. - return re.sub(r'<([/]?script.*?)>', r'<\1>', value) - - def _postValidate(self, mlist, doc): - if not mlist.reply_to_address.strip() and \ - mlist.reply_goes_to_list == 2: - # You can't go to an explicit address that is blank - doc.addError(_("""You cannot add a Reply-To: to an explicit - address if that address is blank. Resetting these values.""")) - mlist.reply_to_address = '' - mlist.reply_goes_to_list = 0 - - def getValue(self, mlist, kind, varname, params): - if varname <> 'subject_prefix': - return None - # The subject_prefix may be Unicode - return Utils.uncanonstr(mlist.subject_prefix, mlist.preferred_language) -- cgit v1.2.3-70-g09d2