~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Instructions for Majordomo List Owners ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Notes on the instructions below: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are several terms used frequently below with special meaning. majordomo the name of an email list management program running on the SVPAL computer. subscriber an email address that will receive email sent to majordomo to be redistributed to the subscriber list. command an emailed request to the majordomo program to provide some action relative to its email lists. All commands should be addressed To: majordomo@svpal.org config file a list of parameters and their associated values that tell majordomo how to respond to incoming email messages and commands. parameter any of the 46 specific items that can be set by specifying values in the majordomo config file. value the words or phrases assigned to a parameter in the config file. The Majordomo List Management program can be set up in a number of ways with many variations. The five most basic questions to ask yourself are: 1. Do I want this list to be moderated or unmoderated? 2. Do I want the subscription list open to anyone or only to a select group? 3. Do I want the existance of this list to be known by everyone? Lists, Which and Who commands. 4. How do I want this list to be viewed by my subscribers? Intro and Info and Data files. 5. Do I want to have a digest list? Other questions to ask yourself relate to enhancements to the email messages and email access to additional data files. The 46 configuration parameters may be grouped loosely by function. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ List of Configuration parameters (grouped) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Group 1: Subscription management Group 2: Email enhancements Group 3: Digests Group 4: Access Control Group 5: List moderation Group 6: Additional files Group 7: Miscellaneous ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alphabetic Listing of Majordomo Config Parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ parameter group parameter group ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ admin_passwd 1 maxlength 2 administrivia 5 message_footer 2 advertise 4 message_fronter 2 announcements 1 message_headers 2 approve_passwd 5 moderate 5 archive_dir 7 Moderator 5 comments 7 mungedomain 1 date_info 6 noadvertise 1 date intro 6 precedence 2 debug 7 purge_received 3 description 4 reply_to 2 digest_archive 3 resend_host 1 digest_issue 3 restrict_post 5 digest_maxdays 3 sender 2 digest_name 3 strip 4 digest_rm_footer 3 subject_prefix 2 digest_rm_fronter 3 subscribe_policy 1 digest_volume 3 taboo_body 5 digest_work_dir 3 taboo_headers 5 get_access 6 unsubscribe_policy 1 index_access 6 welcome 6 info_access 6 which_access 4 intro_access 6 who_access 4 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Parameters arranged by groups ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ announcements 1 Subscription policy subscribe_policy 1 unsubscribe_policy 1 maxlength 2 Email enhancements message_footer 2 message_fronter 2 message_headers 2 precedence 2 reply_to 2 sender 2 subject_prefix 2 digest_archive 3 Digests digest_issue 3 digest_maxdays 3 digest_name 3 digest_rm_footer 3 digest_rm_fronter 3 digest_volume 3 digest_work_dir 3 purge_received 3 advertise 4 Lists, which and who description 4 noadvertise 4 strip 4 which_access 4 who_access 4 administrivia 5 Moderation Policy approve_passwd 5 moderate 5 moderator 5 restrict_post 5 taboo_body 5 taboo_headers 5 date_info 6 Info, Intro and Index/Get files date intro 6 get_access 6 index_access 6 info_access 6 intro_access 6 welcome 6 admin_passwd 7 Miscellaneous mungedomain 7 resend_host 7 archive_dir 7 comments 7 debug 7 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ List Owner ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Each majordomo list has a List Owner. This is the person who owns the password and is able to issue all the special commands that require a password. This includes being able to change the list configuration, the intro file, the info file and to change the passwords. If you are reading this document, then you are probably a list owner. The list owner is able to specify some other passwords that allow others to share in the responsibility of managing the list without letting them take control. In particular, there may be one or more list moderators who may receive any incoming messages if the list is moderated. An on-going responsibility of the list owner is to handle bounced email and, if the list is 'closed', to approve changes to the subscriber list. See the section on subscriptions below. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Discussion of Specific Configuration Parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Do I want this list to be moderated or unmoderated? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Majordomo lists may be moderated or unmoderated. By this we mean, that for a moderated list, there will be one or more persons, discussion moderators or newsletter editors, who have to approve ALL the messages going to the list subscribers. A moderator controls the list which may be helpful or even necessary depending on the subscribers and the purpose of the list. For example, the less well known the subscribers are to each other, the more likely that discussions will need a guiding hand. Close knit groups may prefer the uncensored ambiance of unmoderated lists. Another possibility is a newsletter format with one or more editors who generate or at least pass on all the material being published. In this case, the only input from subscribers is in the form of letters to the editor. Majordomo's 'moderate' parameter should be set to 'yes' for a moderated list and 'no' for an unmoderated list. If the list is moderated, the parameter 'moderator' provides a place to enter the email address of a person different from the list-owner to be the moderator. The parameter 'approve_passwd' is used to set a password different from the owner's main password so that the moderator may be able to do her function without being able to change the list configuration. A critical issue is how to prevent spam from going to your subscribers. If the list is moderated, the moderators will handle this. But if the list in un-moderated, you may set the 'restrict_post' parameter to the name of the list. This will restrict incoming messages to subscribers only, hopefully limiting the spam. If that doesn't work, you will have to find out who is sending the offending email by scanning the message headers and unsubscribing the person manually. Majordomo provides a mechanism to catch messages that should have been sent to the list owner rather than the list. If certain key words appear in the title or first few lines of the message, the whole message will go to the list owner. These words include "Subscribe", "Unsubscribe", "Remove", "Help", etc. This can be a problem if subscribers want to discussing subscriptions, but does eliminate a lot of list messages that should not have been sent to the subscribers in the first place. To enable this feature, set the parameter 'administrivia' to 'yes', otherwise set it to 'no'. The default is 'yes'. The 'taboo_body' parameter allows for catching key words or phrases in the body of a message to an unmoderated list and directing the message to the list owner instead of the list. The parameter 'taboo_headers' does the same for words or phrases in the message header. These two commands require knowledge of 'regular expressions' common to unix systems. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2. Do I want the subscription list open to anyone or only to a select group? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Majordomo lists may be open or closed. Open lists allow anyone to subscribe without getting anyone's approval. Closed lists require approval. The same can be said for those wanting to unsubscribe. To make subscriptions open, set the "subscribe_policy" parameter to "open". To allow anyone to subscribe themselves OR anyone else, set the "subscribe_policy" parameter to auto. The "unsubscribe_policy" parameter is used in a similar manner. Please note that even with an open list, a person is not allowed to unsubscribe themselves without approval unless they are sending the unsubscribe command from the same account they wish to unsubscribe from. This can be confusing for subscribers with multiple accounts or who has dropped the account they had previously subscribed from. There is a special feature available for the subscribe_policy" parameter. This is the ability to force the new subscriber(or unsubscriber) to have to confirm the subscription or unsubscription. This is specified by adding the phrase "+confirm" after the value of the "subscribe" parameter. If the "+confirm" is added, majordomo will automatically send a nice message which includes a authentication number which must be sent back in with another subscribe command. This prevents a person from subscribing a bunch of his/her friends (or enemys) without their permission. If the "announcements" parameter is set to "yes", the list owner will be notified when subscriptions and/or unsubscriptions come in even with an open list. This should be done to make sure that no one is abusing the list, especially for auto or open lists. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3. Do I want the existance of this list to be known by everyone? Lists, Which and Who commands. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are three majordomo commands that subscribers and other can issue to get more information about the lists hosted at SVPAL. The "Lists" command will return to the sender a list of all the public lists. Each list is named along with a brief name as specified with the list's "description" config parameter. The length of the description is about 50 characters. The "Which" command will return to the sender the list of lists to which the sender is personalld subscribed at the address the command is sent from. The "Who " command will return to the sender the whole file of subscriber addresses along, possibly, with other subscriber info like their names. All these functions can be controlled and possibly limited by setting various config parameters. The "advertise" and "noadvertise" parameters can control whether your list will appear in the list returned by the List command. Unless your list needs to be private, I suggest leaving these parameters blank. The parameter "which_access" can be used to limit who can use the "which" command to see if they are subscribed to your list. Use the value of "open" if you don't care who sees if they are subscribers. Use "closed" if you don't want anyone to see. Use the value "list" if you want to limit the command to subscribers only. There is a MAJOR problem with the "which_access" parameter. If one sends the command "which
, all persons with an email address that includes the fragment will be returned. Thus the "which" command performs a "who" function. That is fine if you set the "Which_access" and "who_access" to the same value, but works against you if you wanted to use them in different ways. I find the "which" command of limited utility anyway, and recommend that you set "which_access" to "closed" to avoid unwanted side effects. Subscribers will generally know which lists they have subscribed to and they have no reason to need to know what lists other people have subscribed to. Maximum privacy should be maintained in most cases. The "who" command gives subscribers access to your subscriber list which has major privacy concerns attached. Again, the same values may be set for this parameter, "open", "closed" and "list". I recommend against ever using the "open" option. For close-knit groups, the "list" option allows subscribers to see the addresses of the other subscribers. This can act somewhat like a group address book and can be helpful under the right conditions. The "closed" value allows only someone with access to the list password to see who the subscribers are. This is most suitable for lists with an open subscription policy where the subscriber list is no one's business besides your own. The "strip" parameter can be very useful if you need to keep track of info about your subscribers, such as their name, affiliation, position held, committees, etc. If the value of the "strip" parameter is "no", then any info included with the "subscribe" command is saved in the subscriber file and will be available with the "who" command. If "strip" is set to "yes", then all info except the email address will be stripped from the subscriber addresses. An example of a "subscribe" command with extra info is: subscribe "Dennis Paull, KC6PUN, SPECS VP" I am an amateur radio operator with license KC6PUN and VP of a local ham organization. All that info will become available to anyone with "who" access to my organization's list. Note that if there are any commas in the info string, such as in the example, it is necessary to enclose the info in quotes (" "). The email address will also need to be enclosed in angle brackets (< >). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4. How do I want this list to be viewed by my subscribers? Intro and Info files. Do I want to provide a database of information for any reason? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are two special files that you can create to provide information to subscribers and potential subscribers. In addition, you can provide a database of files that can be accessed by certain people. The "info" file will be emailed to anyone who issues the command: info unless, of course, you restrict access to it. Like the commands above, you can set the value of the "info_access" to "open", "closed" or "list". Which you chose will depend in part on what kind of info you wish to publish in your info file. You can put just about anything you want and the file can be as long as you want. Just remember that most people won't read a very long file unless they are really interested. Items you may want to include in your info file are: Instructions on how to use the majordomo commands, especially how to unsubscribe, Information about your group, How to contact key people in your organization, Netiquette for using discusssion lists, Publication dates, etc, if this is a newsletter, Whatever else you choose. You may create your info file by using the "newinfo" command as follows: newinfo First line of info file.... ..... ..... Last line of info file. Note that this is not a part of the config file. Another, similar file called the intro file will be sent to all new subscribers if you set the "welcome" parameter to "yes". I strongly recommend that you do so. Your intro file can be the same as the info file, but since it is sent to new subscribers, you might want to include more info on how to use the list and less on non-list issues. You create the intro file by sending the "newintro" command as follows: newintro First line of intro file.... ..... ..... Last line of intro file. Access to both the info and intro files may be restricted by use of the "info_access" and "intro_access" parameters, with the values of "open", "closed" and "list". "closed" is a little useless since you can simply not have a file if you don't want anyone to see it! If you want potential subscribers to see either of these files, set the parameter value to "open" for that file. I suggest you leave the values of the parameters "date_info" and "date_intro" at their default "yes" value. Majordomo provides an additional feature that is mostly superceeded by the wide access to the world wide web. You may, if you wish, create files that can be accessed via email independent of web access. You may make these files accessible to the public or only to your subscribers by setting the value of the "get_access" parameter. Use the values of "open" or "list" as appropriate. People can get a list of available files using the "index command. Then, when they see the names of the files, they can download selected files by using the "get " command for each file needed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 5. Do I want to have a digest list? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you are interested in creating a digest list, please contact: owner-majordomo@svpal.org for more information. The available parameters for managing digest lists are: digest_archive digest_rm_fronter digest_issue digest_volume digest_maxdays digest_work_dir digest_name purge_received digest_rm_footer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2. Email Enhancements and Restrictions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "maxlength" parameter sets the length of the longest message that majordomo will send to your subscriber list. You may set it longer than the default 40,000 bytes, but this is long enough for almost any message. HOWEVER, if your subscribers attach files to their email, or include html versions of their posts, their file size may exceed the limits. This problem will only get worse as email software gets more sophisticated and people experiment with 'advanced features'. Posts that exceed the "maxlength" will be bounced to the list owner. It is probably worth explaining the facts of life in your "info" and "intro" files. People with slow connections really object to long posts, so users should be told that their long and/or fancy email may not get read by everyone. The "subject_prefix" provides a very useful aide to email reading for your users. It adds a short string of characters to the begining of the subject line on all list posts. Most email reading software allows a summary of incoming email to be shown before people open up each post. The summary usually includes something about the sender and the subject line. If the subject line includes prefix characters, users will quickly be able to tell which posts come from your list and which from someone else. I suggest that you use a prefix that will not be confused with any other subject words, for instance, use all caps, no spaces and follow with a colon. Make sure the prefix is related to the list by including all or part of the list name. As an example, I have a list named cdc-l and I use the prefix "CDCL:". If you use a lond prefix, some of the actual subject line may not show up in the email summary, which defeats the purpose somewhat. You can have majordomo add text lines to all outgoing email in any of three different places. These are at the beginning of a message, at the end of the message and in the message header lines. The "message_fronter" parameter allows text to be added at the beginning of each message. You can add as many lines as you wish, but I suggest limiting it to no more than 8 lines simply because longer messages take more time to transmit and more hard disk to save and require users to scroll past them to read the message. The "message_footer" parameter works exactly the same way but at the end of the message. Footer lines at least do not require readers to have to scroll past them, but then, they are less likely to be read. The "message_header" parameter adds header lines of your choice to each message, but these lines are much less likely to be read. Their main value is for specifying some special feature when all the subscribers are using similar email software, such as at a university or large corporation. Majordomo does not like to see blank lines in these three parameters. To include a blank line, or a line with leading spaces, add a single dash ("-") to the start of the line. Majordomo will delete the dash when it sends out the email but will preserve the exact text, including spaces, on the rest of the line. Never put a blank line into the headers. All header lines should start in column one and the header topic should be followed by a colon (":"). For example, you might add the header line: X-Info: Fronters and footers are especially good at publicizing web sites, email addresses and similar material. They are the list equivalent to personal 'signature' files. The "reply_to" parameter is not required but is helpful if you want replies to messages to be sent back to the list rather than to the author of the message. Remember, some people will be confused and will send personal replies back to the list by accident. You can warn your subscribers where replies are sent in a fronter or footer message, and that they can edit the To: address to override the default reply address. Users usually catch on quickly, but a few will have a problem remembering how to do it right. Some email software is much better than others at handling replies the way you intend. The "precedence" and "sender" parameters should be left with their default values unless you have an overriding desire to change them. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7. Miscellaneous Parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "admin_passwd" can be used to allow limited administrative access to 'assistant' administrators without giving them access to the main password and the list configuration file. This is very similar to the "approve_passwd". parameter. A person knowing the "admin_passwd" may subscribe and unsubscribe people to/from the list. A person knowing the "approve_passwd" may send and forward messages to a moderated list. The "comments" parameter allows you to insert your own comments into the config file. I do not see the value of this since you may do the same by simply putting a comment "#" character in front of whatever comments you may wish to add. The "comments" parameter will, supposedly, survive a software upgrade while other embedded comments may not. The remaining parameters are technical in nature and should probably not be changed from their default values: mungedomain, resend_host, archive_dir, debug ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following is the default config file for a list named "test-test". It lists all the config parameters but without the leading explanation comments. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # admin_passwd [word] (test-test.admin) # The password for handling administrative tasks on the list. admin_passwd = test-test.admin # administrivia [bool] (yes) # Look for administrative requests (e.g. subscribe/unsubscribe) and # forward them to the list maintainer instead of the list. administrivia = yes # advertise [regexp_array] (undef) # If the requestor email address matches one of these regexps, then # the list will be listed in the output of a lists command. Failure # to match any regexp excludes the list from the output. The # regexps under noadvertise override these regexps. advertise << END END # announcements [bool] (yes) # If set to yes, comings and goings to the list will be sent to the # list owner. These SUBSCRIBE/UNSUBSCRIBE event announcements are # informational only (no action is required), although it is highly # recommended that they be monitored to watch for list abuse. announcements = yes # approve_passwd [word] (test-test.pass) # Password to be used in the approved header to allow posting to # moderated list, or to bypass resend checks. approve_passwd = test-test.pass # archive_dir [absolute_dir] (undef) # The directory where the mailing list archive is kept. This item # does not currently work. Leave it blank. archive_dir = # comments [string_array] (undef) # Comment string that will be retained across config file rewrites. comments << END END # date_info [bool] (yes) # Put the last updated date for the info file at the top of the # info file rather than having it appended with an info command. # This is useful if the file is being looked at by some means other # than majordomo (e.g. finger). date_info = yes # date_intro [bool] (yes) # Put the last updated date for the intro file at the top of the # intro file rather than having it appended with an intro command. # This is useful if the file is being looked at by some means other # than majordomo (e.g. finger). date_intro = yes # debug [bool] (no) # Don't actually forward message, just go though the motions. debug = no # description [string] (undef) # Used as description for mailing list when replying to the lists # command. There is no quoting mechanism, and there is only room # for 50 or so characters. description = # digest_archive [absolute_dir] (undef) # The directory where the digest archive is kept. This item does # not currently work. Leave it blank. digest_archive = # digest_issue [integer] (1) # The issue number of the next issue digest_issue = 1 # digest_maxdays [integer] (undef) # automatically generate a new digest when the age of the oldest # article in the queue exceeds this number of days. digest_maxdays = # digest_maxlines [integer] (undef) # automatically generate a new digest when the size of the digest # exceeds this number of lines. digest_maxlines = # digest_name [string] (test-test) # The subject line for the digest. This string has the volume and # issue appended to it. digest_name = test-test # digest_rm_footer [word] (undef) # The value is the name of the list that applies the header and # footers to the messages that are received by digest. This allows # the list supplied headers and footers to be stripped before the # messages are included in the digest. This keyword is currently # non operative. digest_rm_footer = # digest_rm_fronter [word] (undef) # Works just like digest_rm_footer, except it removes the front # material. Just like digest_rm_footer, it is also non-operative. digest_rm_fronter = # digest_volume [integer] (1) # The current volume number digest_volume = 1 # digest_work_dir [absolute_dir] (undef) # The directory used as scratch space for digest. Don't change # this unless you know what you are doing digest_work_dir = # get_access [enum] (list) /open;closed;list/ # One of three values: open, list, closed. Open allows anyone # access to this command and closed completely disables the command # for everyone. List allows only list members access, or if # restrict_post is defined, only the addresses in those files are # allowed access. get_access = list # index_access [enum] (open) /open;closed;list/ # One of three values: open, list, closed. Open allows anyone # access to this command and closed completely disables the command # for everyone. List allows only list members access, or if # restrict_post is defined, only the addresses in those files are # allowed access. index_access = open # info_access [enum] (open) /open;closed;list/ # One of three values: open, list, closed. Open allows anyone # access to this command and closed completely disables the command # for everyone. List allows only list members access, or if # restrict_post is defined, only the addresses in those files are # allowed access. info_access = open # intro_access [enum] (list) /open;closed;list/ # One of three values: open, list, closed. Open allows anyone # access to this command and closed completely disables the command # for everyone. List allows only list members access, or if # restrict_post is defined, only the addresses in those files are # allowed access. intro_access = list # maxlength [integer] (40000) # The maximum size of an unapproved message in characters. When # used with digest, a new digest will be automatically generated if # the size of the digest exceeds this number of characters. maxlength = 40000 # message_footer [string_array] (undef) # Text to be appended at the end of all messages posted to the # list. The text is expanded before being used. The following # expansion tokens are defined: $LIST - the name of the current # list, $SENDER - the sender as taken from the from line, $VERSION, # the version of majordomo. If used in a digest, no expansion # tokens are provided message_footer << END END # message_fronter [string_array] (undef) # Text to be prepended to the beginning of all messages posted to # the list. The text is expanded before being used. The following # expansion tokens are defined: $LIST - the name of the current # list, $SENDER - the sender as taken from the from line, $VERSION, # the version of majordomo. If used in a digest, only the expansion # token _SUBJECTS_ is available, and it expands to the list of # message subjects in the digest message_fronter << END END # message_headers [string_array] (undef) # These headers will be appended to the headers of the posted # message. The text is expanded before being used. The following # expansion tokens are defined: $LIST - the name of the current # list, $SENDER - the sender as taken from the from line, $VERSION, # the version of majordomo. message_headers << END END # moderate [bool] (no) # If yes, all postings to the list must be approved by the # moderator. moderate = no # moderator [word] (undef) # Send bounces to moderator instead of owner- moderator = # mungedomain [bool] (no) # If set to yes, a different method is used to determine a matching # address. When set to yes, addresses of the form user@dom.ain.com # are considered equivalent to addresses of the form user@ain.com. # This allows a user to subscribe to a list using the domain # address rather than the address assigned to a particular machine # in the domain. This keyword affects the interpretation of # addresses for subscribe, unsubscribe, and all private options. mungedomain = no # noadvertise [regexp_array] (undef) # If the requestor name matches one of these regexps, then the list # will not be listed in the output of a lists command. Noadvertise # overrides advertise. noadvertise << END END # precedence [word] (bulk) # Put a precedence header with value into the outgoing # message. precedence = bulk # purge_received [bool] (no) # Remove all received lines before resending the message. purge_received = no # reply_to [word] () # Put a reply-to header with value into the outgoing # message. If the token $SENDER is used, then the address of the # sender is used as the value of the reply-to header. This is the # value of the reply-to header for digest lists. reply_to = # resend_host [word] (undef) # The host name that is appended to all address strings specified # for resend. resend_host = # restrict_post [restrict_post] (undef) # If defined, only addresses listed in these files (colon or space # separated) can post to the mailing list. By default, these files # are relative to the lists directory. These files are also checked # when get_access, index_access, info_access, intro_access, # which_access, or who_access is set to 'list'. This is less useful # than it seems it should be since there is no way to create these # files if you do not have access to the machine running resend. # This mechanism will be replaced in a future version of # majordomo/resend. restrict_post = # sender [word] (owner-test-test) # When adding address to the list, strip off all comments etc, and # put just the raw address in the list file. In addition to the # keyword, if the file .strip exists, it is the same as # specifying a yes value. That yes value is overridden by the value # of this keyword. strip = yes # subject_prefix [word] (undef) # This word will be prefixed to the subject line, if it is not # already in the subject. The text is expanded before being used. # The following expansion tokens are defined: $LIST - the name of # the current list, $SENDER - the sender as taken from the from # line, $VERSION, the version of majordomo. subject_prefix = # subscribe_policy [enum] (open+confirm) /open;closed # One of three values: open, closed, auto; plus an optional # modifier: '+confirm'. Open allows people to subscribe themselves # to the list. Auto allows anybody to subscribe anybody to the list # without maintainer approval. Closed requires maintainer approval # for all subscribe requests to the list. Adding '+confirm', ie, # 'open+confirm', will cause majordomo to send a reply back to the # subscriber which includes a authentication number which must be # sent back in with another subscribe command. subscribe_policy = open+confirm # taboo_body [regexp_array] (undef) # If any line of the body matches one of these regexps, then the # message will be bounced for review. taboo_body << END END # taboo_headers [regexp_array] (undef) # If any of the headers matches one of these regexps, then the # message will be bounced for review. taboo_headers << END END # unsubscribe_policy [enum] (open) /open;closed;auto/ # One of three values: open, closed, auto. Open allows people to # unsubscribe themselves from the list. Auto allows anybody to # unsubscribe anybody to the list without maintainer approval. The # existence of the file .auto is the same as specifying # the value auto. Closed requires maintainer approval for all # unsubscribe requests to the list. In addition to the keyword, if # the file .closed exists, it is the same as specifying # the value closed. The value of this keyword overrides the value # supplied by any existent files. unsubscribe_policy = open # welcome [bool] (yes) # If set to yes, a welcome message (and optional 'intro' file) will # be sent to the newly subscribed user. welcome = yes # which_access [enum] (open) /open;closed;list/ # One of three values: open, list, closed. Open allows anyone # access to this command and closed completely disables the command # for everyone. List allows only list members access, or if # restrict_post is defined, only the addresses in those files are # allowed access. which_access = open # who_access [enum] (open) /open;closed;list/ # One of three values: open, list, closed. Open allows anyone # access to this command and closed completely disables the command # for everyone. List allows only list members access, or if # restrict_post is defined, only the addresses in those files are # allowed access. who_access = closed