<HTML>
<HEAD>
<!-- =================================================================== -->
<META HTTP-EQUIV="EXPIRES" CONTENT="Fri, 02 Feb 1996 11:04:53 PDT 1996">
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<META NAME="KEYWORDS" CONTENT="MajorCool, Majordomo, Web, CGI, mailing list">
<META NAME="DESCRIPTION" CONTENT="MajorCool is a Web interface to Majordomo. This is an installed copy; the definitive site for MajorCool info is http://ncrinfo.ncr.com/pub/contrib/unix/MajorCool/">
<!-- =================================================================== -->
<TITLE>MajorCool Configuration</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff">
<DIV ALIGN=CENTER>
<TABLE WIDTH=100% BORDER=0 ALIGN=CENTER VALIGN=TOP>
<TR>
<TD WIDTH=520 ALIGN=CENTER VALIGN=MIDDLE>
<DIV ALIGN=CENTER>
<IMG SRC="../icons/mc_cool_banner.gif" ALT="[MajorCool]" ALIGN=MIDDLE>
<H3 ALIGN=CENTER>MajorCool: A Web Interface To Majordomo</H3>
<FONT SIZE=-1><!--META-->(This is a copy of the <I>MajorCool</I> <A HREF="http://ncrinfo.ncr.com/pub/contrib/unix/MajorCool/">master</A> documentation set)</FONT>
</DIV>
</TD>
<TD ALIGN=RIGHT VALIGN=TOP>
<FONT SIZE=2>
<A HREF="index.htm">Introduction</A><BR>
<A HREF="usage.htm">Usage</A><BR>
<A HREF="prereq.htm">System Requirements</A><BR>
<A HREF="install.htm">Installation</A><BR>
<B>Configuration</B><BR>
<A HREF="future.htm">Future Direction</A><BR>
<A HREF="support.htm">Licensing, FAQs, & Credits</A><BR>
</FONT>
</TD>
</TR>
</TABLE>
</DIV>
<HR>
<P><I>MajorCool</I> is a 2-piece application. Most of the work is done
by the <CODE>majorcool.pl</CODE> script which is installed in the
<I>Majordomo</I> <CODE>$homedir</CODE>. This script is run under the
<I>Majordomo</I> <CODE>wrapper</CODE> program to ensure that all
permissions are honored accordingly.
<P>A CGI "shim" is used to link the world of the Web to the
<CODE>wrapper</CODE>-based world of <I>MajorCool</I>. Since the
<CODE>wrapper</CODE> procedure provides a limited environment (and does
not pass parent env-vars), the sole purpose of the "shim" is to pass
needed CGI variables to the <I>MajorCool</I> routine. This CGI is
installed using the name that was entered during the
<CODE>Configure</CODE> session for the appropriate <CODE>cf</CODE>
file.
<P>Customizing the operation of <I>MajorCool</I> can involve both
<A HREF="#CONFIG">install-time</A> and <A HREF="#PREFS">run-time</A>
configuration. These settings control all the HTML, Cascading Style
Sheets, and Javascripts which are dynamically generated by the
<CODE>majorcool.pl</CODE> script -- there are no external HTML/CSS
"source files".
<P>Although <I>MajorCool</I> was designed primarily as a site
administration tool with a complete view of <U>all</U> lists on a
server, it also supports a <A HREF="#REMOTE">remote</A> mode for
embedding individual actions (e.g., <CODE>subscribe</CODE>) in external
(non-<I>MajorCool</I>) Web pages.
<A NAME="CONFIG">
<H2>Site Configuration</H2>
</A>
<P>Basic behavior of the <I>MajorCool</I> application is controlled
by the <CODE>majorcool_XXXX.cf</CODE> configuration file (where
"<CODE>XXXX</CODE>" comes from the named <CODE>XXXX.sh</CODE> source
file output by <CODE>Configure</CODE> -- <CODE>default.sh</CODE> by
default). The config tool will take the <CODE>majorcool.cf.common</CODE>
base file, append a selected <CODE>siteaddr/</CODE> file, and then
perform variable substitutions to create an installed
<CODE>majorcool_XXXX.cf</CODE> file.
<P>NOTE: If the installed <CODE>cf</CODE> file is changed, be sure to
update the appropriate <CODE>sh</CODE> and/or the template
<CODE>majorcool.cf.common</CODE> as appropriate, or else the changes
will be lost the next time <CODE>Configure</CODE> is run.
<P>The <A HREF="#VARIABLES">configuration variables</A> in the
<CODE>cf</CODE> file determine <I>MajorCool</I>'s level of security,
visual presentation, and its integration with the local site. Most of
these settings are directly supported by the <CODE>Configure</CODE>
tool and thus will probably not require digging into any of the Perl
code. If any local modifications are to be done, they will likely
involve the support of the <CODE>siteaddr()</CODE> functions for
interfacing to external name-to-address conversion tools.
<A NAME="SITEADDR">
<H3><CODE>siteaddr()</CODE> External Query Interfaces</H3>
</A>
<P><I>MajorCool</I> provides an ability to interface with external
functions that provide name-to-address conversions. For example, the
NCR e-mail infrastructure utilizes a <I>Rolodex</I>-style database tool
to allow delivery based on name as well as traditional host addresses.
Thus, my own address is both <CODE>bhoule@www.sandiegoca.ncr.com</CODE>
and <CODE>Bill.Houle@SanDiegoCA.NCR.COM</CODE>. While <I>Majordomo</I>
can be configured to know the equivalencies between
<CODE>bhoule@www.sandiegoca.ncr.com</CODE> and
<CODE>bhoule@sandiegoca.ncr.com</CODE> (via the
<CODE>$mungedomain</CODE> option), it cannot handle the address mapping
when provided by an external function.
<P>It was decided that, given our addressing complexities,
<I>MajorCool</I> would be infinitely more useful if it was aware of the
mapping equivalencies provided by external functions such as the NCR
<I>Rolodex</I>. Taking the output of these external functions, we can
build regular expression pattern matching strings that are used to
determine list membership. By using regular expressions rather than
fixed strings (as <I>Majordomo</I> does), <I>MajorCool</I> is able to
identify list members by their multiple valid addresses.
<P>The interface to these external functions is through
<CODE>siteaddr()</CODE> functions contained in the
<I>MajorCool</I> <CODE>cf</CODE> file. The main <CODE>siteaddr()</CODE>
routine accepts a single string (as prompted for on the BROWSE
screen), and returns a 3-value tuple:
<OL>
<LI>The "friendly name" of the address matched by the function,
e.g., a "real name". This value is used for display purposes only.
<LI>The preferred e-mail address to be associated with this user.
<LI>A regular expression to match any address as appropriate for this
user. See the <A HREF="#REGEXPS">additional comments</A> below for more
about this matching functionality.
</OL>
<P>For example, the resultant NCR <CODE>siteaddr()</CODE> on "Houle"
might return the tuple
<PRE>(
"Bill Houle",
"Bill.Houle@SanDiegoCA.NCR.COM",
"/^Bill\.Houle$|^Bill\.Houle@|^bhoule@.*\.sandiegoca\.ncr\.com$/"
)
</PRE>
The latter regexp defines address matching patterns for (respectively):
my unqualified <I>Rolodex</I> address, fully-qualified <I>Rolodex</I>
address, and any host-based address in my domain that matched my login-id.
<H4>Pre-Defined <CODE>siteaddr()</CODE> Interfaces</H4>
<P>The default <I>MajorCool</I> distribution includes 6 sample
<CODE>siteaddr/</CODE> files:
<UL>
<LI><B>simple</B> -- No external address mapping needed; addresses are
returned as-is.
<LI><B>domain</B> -- If the address is local to the <I>Majordomo</I>
domain (<CODE>$whereami</CODE>), then both fully-qualified and
username-only addresses will match. If not in the domain, no mapping occurs.
<LI><B>domain-smtp</B> -- Same as <I>domain</I>, except additional
local validation is performed against SMTP and DNS MX records to verify
the user. If not in the domain, no mapping occurs.
<LI><B>ncr-rolo</B> -- Queries the <CODE>rolo</CODE> program (a simple
text-file database used by <I>NCR Corporation</I> to provide
<I>First.Lastname</I> to <I>user@host.domain</I> address mapping).
<LI><B>ncr-rolo.socal</B> -- Same as <I>ncr-rolo</I>, except specially
tailored for the shared domain configuration of <I>NCR Southern
California</I>.
<LI><B>ncr-ldap</B> -- Uses the <CODE>ldapsearch</CODE> program
(available from the University of Michigan) to query the NCR X.500
Associate Directory.
</UL>
<P>Other examples of external programs that could be used for
customized <CODE>siteaddr()</CODE> functions include <I>YP/NIS</I> or
<I>Ph</I>. (If you develop any functions that would be of interest to
others, please send them to me so that they can be included in
future releases.)
<H4>Building Your Own External Interface</H4>
<P>To build your own <CODE>siteaddr()</CODE> interface, you need to
develop a Perl include file that defines 3 objects:
<DL>
<DT><B><CODE>%siteaddr</CODE></B></DT>
<DD>The <CODE>%siteaddr</CODE> associative array, which is
used to define various text messages that appear on
<I>MajorCool</I> screens. The <CODE>prompt</CODE> value
defines the prompt for the field whose date that will be
passed to the <CODE>siteaddr()</CODE> function, while the
<CODE>browse</CODE>, <CODE>modify</CODE>, <CODE>create</CODE>,
<CODE>rename</CODE>, and <CODE>delete</CODE> strings can be
used to further explain features & functions on the forms
for the associated modules.
</DD>
<DT><B><CODE>siteaddr()</CODE></B></DT>
<DD>The <CODE>siteaddr()</CODE> function, which generates
the 3-value tuple providing the real name, primary address,
and regular expression matching parameters to the
<I>MajorCool</I> application.
</DD>
<DT><B><CODE>by_siteaddr()</CODE></B></DT>
<DD>The <CODE>by_siteaddr()</CODE> function, which is used to
provide a customizable address sorting mechanism. Since the
<CODE>siteaddr()</CODE> interface function defines a set of
addresses that <I>MajorCool</I> uses to support multiple
address classes, it may also be valuable to sort list members
according to an order appropriate for your local address
definitions.
</DD>
</DL>
<P>Your <CODE>siteaddr()</CODE> may require some user interaction
such as selecting a specific address from an externally provided list
of possible matches. You may output HTML from within your function
in order to to provide this interaction. If you perform interaction
via HTML, you must be cognizant of <I>MajorCool</I>'s support for
multipart-MIME and be sure to pass any form arguments back to the
calling BROWSE module -- see the <CODE>ncr-rolo</CODE> file which is
a good example of this technique.
<P>If you implement your own <CODE>siteaddr()</CODE> function, please
note the special comment format used by <CODE>Configure</CODE> to
support their installation:
<UL>
<LI>'<CODE>#~</CODE>' indicates text to be extracted and used as the
file "explanation" during the install.<PRE>
#~This is file foo.
#~The text can span multiple lines.</PRE>
<LI>'<CODE>#+</CODE>' indicates a variable dependency. The named
variable will be prompted for during configuration; the value will
be stored in the generated <CODE>config.sh</CODE> and substituted on
all files.<PRE>
#+BINDIR</PRE>
</UL>
<A NAME="REGEXPS">
<H4>Regular Expression Matching</H4>
</A>
<P>The regular expression pattern matching capabilities of
<I>MajorCool</I> are very powerful. They can also be very dangerous.
A poorly constructed regexp may result in lists being accessible and
incorrectly appearing to be subscribed. The functionality is primarily
intended for string matching, and any use of metacharacters should be
done with the utmost care. For example, you would not want to allow
an input to generate a regexp such as <CODE>/\w+@.*/</CODE> -- every
address on a list might be matched!
<P>Regexp matching is completely optional. To minimize the danger to
functions that have no use for a pattern match, a null regexp value
can be returned by the <CODE>siteaddr()</CODE> function. In this
case, <I>MajorCool</I> will perform a straight text comparison of
the address parameter, identical to the behavior of <I>Majordomo</I>
itself.
<P>If you utilize the regexp functionality, it is imperative that all
efforts are made to ensure that inputs to <CODE>siteaddr()</CODE> are
carefully scrutinized and no improper expressions are generated.
<A NAME="MODULES">
<H3>Modules</H3>
</A>
<P><I>MajorCool</I> functions are designed around 4 modules which
determine which <I>Majordomo</I> actions are accessible: BROWSE
(View/Change List Subscription Status), MODIFY (Administer an
Existing List), CREATE (Create a New List), and DELETE (Delete an
Existing List). Each of these modules can be selectively enabled or
disabled in any given config file.
<P>If a module is disabled, it's form or menu selection will not be
shown on the main screen and any sub-functions that depend on this
action being present will fail. The state of the enabled modules is
contained in the <CODE>%modules</CODE> variable within the
<I>MajorCool</I> <CODE>cf</CODE> file. For example, the setting
of<PRE>
<CODE>%modules = (
browse, 1,
modify, 1,
create, 0,
rename, 0,
delete, 0,
};</CODE></PRE>
corresponds to a <I>MajorCool</I> configuration with the end-user
and list-admin functionality active, but the list create/rename/delete
functionality turned off. Normally, the <CODE>Configure</CODE>
process will handle the setting of status for the various modules.
<A NAME="VARIABLES">
<H3>Other Config Variables</H3>
</A>
<DL>
<DT><B><CODE>$sitename</CODE></B></DT>
<DD>The site or installation location name to be used in page titles.
</DD>
<P>
<DT><B><CODE>$sitehome</CODE></B></DT>
<DD>The URL of the site's "home page". This address will be used as
the destination for the "HOME" button.
</DD>
<P>
<DT><B><CODE>$header</CODE></B>/<B><CODE>$footer</CODE></B></DT>
<DD>Optional header/footer pages to incorporate "look and feel"
into <I>MajorCool</I> pages. If not present, <I>MajorCool</I>
will provide beginning & ending <HTML> and <BODY>
tags, resulting in a white page background. If a different look
is desired, or a site wishes to incorporate its standard style,
alternate files may be specified as header and footer pages.
The footer should implement closing BODY and HTML tags, while
the header should provide a beginning BODY tag. (<I>MajorCool</I>
will always generate the opening HTML tag, since it also
generates the document HEAD section.)
</DD>
<P>
<DT><B><CODE>$opt_hiddenlists</CODE></B></DT>
<DD>If disabled (<CODE>0</CODE>), the MODIFY portion
of the <I>MajorCool</I> opening screen will display a pick-list
of all lists available for configuration. Since the pick-list is
displayed before the user address is collected, there is no
attention paid to advertise/noadvertise settings. Sites wishing
to honor advertise settings will want to enable (<CODE>1</CODE>)
this option to force the owner to explicitly enter the list name.
Some older browsers will have trouble with long pick-lists, which
is another valid reason for using this feature.
</DD>
<P>
<DT><B><CODE>$opt_hiddenpasswd</CODE></B></DT>
<DD>If disabled (<CODE>0</CODE>), the <CODE>admin_passwd</CODE>
setting will appear as a plain-text field on an equal level with all
other fields on the list configuration screen. If enabled
(<CODE>1</CODE>), the password field would be elevated to a "secret"
double-entry process within a separate form. Sites wishing to protect
their users from accidental changes or "glance-at-the-screen"
compromises might prefer this option.
</DD>
<P>
<DT><B><CODE>$opt_noadvertise</CODE></B></DT>
<DD><I>Majordomo</I> can be configured to advertise lists to its
members even if the list is not normally advertised. Unfortunately,
to enable/disable this behavior, the appropriate source lines must
be commented in/out. This setting achieves the same function
in <I>MajorCool</I> programatically rather than via code changes.
</DD>
<P>
<DT><B><CODE>$opt_trustident</CODE></B></DT>
<DD><I>Majordomo</I> authenticates the user based on the e-mail
address. If an address is forged for any particular command,
there is some semblance of security because the e-mail result
will be sent to the forged address rather than the forger. Now
consider <I>MajorCool</I>: it is possible to masquerade as another
user via the Web, and unlike <I>Majordomo</I>, there is no failsafe
security -- results will be visible onscreen. If
<CODE>$opt_trustident</CODE> is disabled (<CODE>0</CODE>),
<I>MajorCool</I> will try to provide some hint of the same failsafe
<I>Majordomo</I> security. Results of accessing "private" list
options (e.g. <CODE>private_who/who_access=list</CODE>) will be
returned via mail rather than displayed onscreen.
</DD>
<P>
<DT><B><CODE>$opt_cmdverify</CODE></B></DT>
<DD>Enabling this option tells <I>MajorCool</I> to generate
<I>Majordomo</I> commands and mail them to the user rather
than sending them through the list processor. It would be
the responsibility of the user to then forward the resulting
commands back to <I>Majordomo</I>. This option is called
"instruct" mode because in the process of re-sending the
commands, the user might become familiar with <I>Majordomo</I>
syntax. However, it is also known as "paranoia mode" because
the underlying intent was to treat this as an added safety
measure for the security-conscious. With this option enabled,
no commands can ever be directly executed by a user with a
falsified Web identity, since e-mail is used to let the "true"
user confirm the actions.
</DD>
<P>
<DT><B><CODE>$opt_subverify</CODE></B></DT>
<DD>A less comprehensive version of <CODE>$opt_cmdverify</CODE>,
this setting will cause all subscribe/unsubscribe requests
to be converted to command form and returned to the user via
e-mail. The idea is that the user will then forward the mail
back to <I>Majordomo</I>. This eliminates authentication
insecurities at the cost of an extra step for the user.
</DD>
<P>
<DT><B><CODE>$opt_sendcf</CODE></B></DT>
<DD>Set this variable to 0 if you do not wish to offer list
admins the ability to request a configuration file sent via
e-mail (i.e., the <I>Majordomo</I> <CODE>config</CODE>
command). Remember: the user will always have this option
via e-mail command unless <I>Majordomo</I> itself is
modified.
</DD>
<P>
<DT><B><CODE>$opt_cfcomments</CODE></B></DT>
<DD>Configuration files normally are stored with full
comments included. By disabling this variable
(<CODE>0</CODE>), only the keyword variables and their
values will be saved.
</DD>
<P>
<DT><B><CODE>$opt_multipart</CODE></B></DT>
<DD>The Netscape browser supports an experimental MIME type
called 'multipart-mixed-replace'. With this MIME type,
continued output can replace any previous screen displays.
This feature, known as "server push", can be used to provide
a sort of "please wait" status screen while <I>MajorCool</I>
performs some of the more time-intensive tasks. Normally,
<I>MajorCool</I> will detect which browser supports the
"push" functionality and offer it accordingly, or you can
disable (<CODE>0</CODE>) this update feature altogether.
</DD>
<P>
<DT><B><CODE>$opt_prefsreturn</CODE></B></DT>
<DD><I>MajorCool</I> can save "state" when presenting the
Preferences module such that the user will be returned to
the prior screen after the Prefs changes are applied. This
is a cool feature that makes Prefs a modal function and
allows the user to tweak Prefs settings and instantly see
their effects. The downside to this feature is that the
"state" that is saved will often include list password data
that may be written to your Web server access logs [see <B>A
Note About Web Server Security</B> on the <A HREF="prereq.htm">
Requirements page</A>]. If disabled (<CODE>0</CODE>), security
is increased at the cost of minor functionality.
</DD>
<P>
<DT><B><CODE>$opt_robots</CODE></B></DT>
<DD>Some Internet search engines, crawlers, and "spiders"
honor the "ROBOTS" META tag protocol. Setting this value
determines how compliant Robots will react to <I>MajorCool</I>.
If disabled (<CODE>0</CODE>), the program instance will not
be indexed by these agents.
</DD>
<P>
<DT><B><CODE>$opt_scansteps</CODE></B></DT>
<DD>When <I>MajorCool</I> scans the server for member subscription
status and list access rights, it can be a time-consuming
process. Setting a non-zero value will keep the user aware
of the progress of this scan by giving a list countdown. The
value set here is the step interval for this countdown (eg,
150..100..50..). Smaller numbers mean more frequent updates,
and a corresponding increase in transmitted data and cached
pages. This feature requires the MultiPart (<CODE>$opt_multipart</CODE>)
option to be enabled and a browser that supports this MIME
content.
</DD>
<P>
<DT><B><CODE>@admin_keywords</CODE></B></DT>
<DD>This list defines which (and in what order) fields are presented
to the list administrator in the "basic" view of the MODIFY
screen. Please note that the distributed
<CODE>majorcool.cf.common</CODE> file contains many NCR-specific
keywords that can be removed if not implemented locally.
(There is no harm if they remain, though.)
</DD>
<P>
<DT><B><CODE>$list_create_cmd</CODE></B></DT>
<DD>If present (and executable), the referenced program will be
invoked for any list-creation request, assuming an argument list of
<PRE>-d {description} -o {owner} -p {passwd} listname</PRE>
You can write your own creation program, or use the script found
in the <CODE>contrib/</CODE> directory.
<P>
Regardless of the setting, all requests for new lists will be
mailed to the <I>Majordomo-owner</I> address. The context of
the setup will determine whether this mailing is an actual
request or merely an FYI following the
<CODE>$list_create_cmd</CODE> action.
<P>
NOTE: Because <I>MajorCool</I> itself runs under <CODE>wrapper</CODE>
permissions, the specified program will inherit the same privileges.
There is no need to include "<CODE>wrapper</CODE>" as part of the
<CODE>$list_create_cmd</CODE> path.
</DD>
<P>
<DT><B><CODE>$list_rename_cmd</CODE></B></DT>
<DD>If present (and executable), the referenced program will be
invoked for any list-renaming request, assuming an argument list of
<PRE>-o {owner} -p {passwd} oldlist newlist</PRE>
You can write your own creation program, or use the script found
in the <CODE>contrib/</CODE> directory.
<P>
Regardless of the setting, all requests for list renaming will
be mailed to the <I>Majordomo-owner</I> address. The context
of the setup will determine whether this mailing is an actual
request or merely an FYI following the
<CODE>$list_rename_cmd</CODE> action.
<P>
NOTE: Because <I>MajorCool</I> itself runs under <CODE>wrapper</CODE>
permissions, the specified program will inherit the same privileges.
There is no need to include "<CODE>wrapper</CODE>" as part of the
<CODE>$list_rename_cmd</CODE> path.
</DD>
<DT><B><CODE>$list_delete_cmd</CODE></B></DT>
<DD>If present (and executable), the referenced program will be
invoked for any list-deletion request, assuming an argument list of
<PRE>-o {owner} -p {passwd} listname</PRE>
You can write your own creation program, or use the script found
in the <CODE>contrib/</CODE> directory.
<P>
Regardless of the setting, all requests for list deletion will
be mailed to the <I>Majordomo-owner</I> address. The context
of the setup will determine whether this mailing is an actual
request or merely an FYI following the
<CODE>$list_delete_cmd</CODE> action.
<P>
NOTE: Because <I>MajorCool</I> itself runs under <CODE>wrapper</CODE>
permissions, the specified program will inherit the same privileges.
There is no need to include "<CODE>wrapper</CODE>" as part of the
<CODE>$list_delete_cmd</CODE> path.
</DD>
</DL>
<A NAME="PREFS">
<H2>Per-User Preferences</H2>
</A>
<P>The configuration settings above reflect site-wide preferences for
<I>MajorCool</I> operation. In addition to the per-site settings,
<I>MajorCool</I> offers several options for individual per-user
preferences. These preferences are implemented via HTTP "Cookies".
Cookies are tokens saved in each user's client config and exchanged as
part of the HTTP handshake between browser and the <I>MajorCool</I>
application.
<!--This more detailed section augments the cursory coverage in USAGE.HTM-->
<!--BEGIN PREFS-->
<BR>
<H3>General Options</H3>
<DL>
<P>
<DT><B><CODE>Allow Browser To Cache Pages</CODE></B></DT>
<DD>Browsers can, in the interest of performance, save visited pages
in their cache for easier recall. In the case of <I>MajorCool</I>,
a cached page may reflect the state of some <I>Majordomo</I> data
relative only to the current <I>MajorCool</I> session, even though
changes may have been performed via e-mail or other Web
users. With the Cache setting, users may enable or disable the
caching of page data depending upon their own personal preferences.
If caching is disabled, "backing up" to a previous screen will
require the browser to re-query for current data.
</DD>
<P>
<DT><B><CODE>Enable <I>Style Sheet</I> Font Control (Where Supported)</CODE></B></DT>
<DD>If your browser supports HTML 4.0 "<I>Style Sheets</I>" (CSS),
you may tailor the font family and point size used on all
<I>MajorCool</I> pages to suit your liking. This preference can
be used to toggle CSS support.
</DD>
<P>
<DT><B><CODE>Default Font Face & Point Size</CODE></B></DT>
<DD>Requires CSS support in the browser and the above <B><I>Style
Sheet</I> Font Control</B> preference enabled. Since not all
browsers support Style Sheets or some of the referenced fonts,
these settings will have no apparent effect if unsupported.
</DD>
<P>
<DT><B><CODE>Use <I>JavaScript</I> Enhancements</CODE></B></DT>
<DD><I>JavaScript</I> offers some neat user-interface "bells
& whistles" such as the ability to update the browser
status line or swap images when "moused over". Most browsers
will ignore what they can't understand, so there is no harm
for those applications that do not support <I>JavaScript</I>.
Naturally, none of these effects are particularly critical to
the operation of <I>MajorCool</I>, but they are certainly
"cool". However if a user finds them more "annoying" than
"cool", they can be disabled.
</DD>
<P>
<DT><B><CODE>Sort Subscriber List in BROWSE and MODIFY Views</CODE></B></DT>
<DD>With large lists, it can be difficult at times to locate
specific addresses for verification, modification, or deletion.
Users may prefer to have the subscriber list sorted (using the
site-configured <CODE>by_siteaddr()</CODE> function).
</DD>
<P>
<DT><B><CODE>Use 'Menu' Style User Interface</CODE></B></DT>
<DD><I>MajorCool</I> can display configured modules (e.g.,
BROWSE, MODIFY, CREATE, DELETE, and PREFS) in two ways. In
"Menu" mode, a selection of buttons is present across the
top of the screen, with the 'active' (i.e., selected) action
occupying the space between the header and footer. The
alternative to Menu mode is to forego the button-bar and
the concept of an 'active' action, showing all available
actions on the main page. Menu mode is enabled by default.
</DD>
<P>
<DT><B><CODE>Default Action for Menu Mode</CODE></B></DT>
<DD>When in "Menu" mode, the initial screen shown on start-up
or restart will be the first available module from the list
of BROWSE/MODIFY/CREATE/DELETE. This preference is used to
override that ordering and start specifically at a particular
module. For example, in a BROWSE/MODIFY configuration, a
list owner may choose MODIFY as the preferred action if that
is the most frequently performed <I>MajorCool</I> activity.
Selecting a module that has been disabled by the site admin
will have no effect.
</DD>
<P>
<DT><B><CODE>Default Screen Width</CODE></B></DT>
<DD>The default screen size of <I>MajorCool</I> is designed
to easily fit on a 640 pixel wide screen typical of most
personal computers (your browser window may need to be
widened accordingly). You can set your own desired pixel
width, or even have the data follow the current width of the
browser by setting the width to '100%'.
</DD>
<P>
<DT><B><CODE>Use Images for Form Buttons</CODE></B></DT>
<DD><I>MajorCool</I> can be very graphics-intensive, all the
way down to its use of images for traditional SUBMIT
buttons. Some people find the plain-Jane SUBMIT/RESET
buttons more effective (not to mention faster to load), so
the use of images for FORM buttons can be enabled or
disabled.
</DD>
<P>
<DT><B><CODE>Tool Tips on Button Bars</CODE></B></DT>
<DD>Tool Tips are available on the top (Menu Mode) and bottom
button bars. Simply hold the mouse over the button and a window
will pop up describing its function in more detail. Tool
Tips require <B><I>JavaScript</I> Enhancements</B> enabled
(above).
</DD>
</DL>
<BR>
<H3>Browse Options</H3>
<DL>
<P>
<DT><B><CODE>Show Nested Lists As Hyperlinks</CODE></B></DT>
<DD>Subscriber lists may contain other local lists as members.
These can be displayed as hyperlinks to facilitate the browsing
of the nested list details.
</DD>
<P>
<DT><B><CODE>Link to Subscribers When Following Nested Lists</CODE></B></DT>
<DD>Nested lists can be linked to either the Detail view of
the referenced list, or directly to the subscriber list itself.
Detail view is the default link type.
</DD>
<P>
<DT><B><CODE>Show Line Numbers In Subscriber List</CODE></B></DT>
<DD>The subscriber list can be displayed with line numbers
to ease viewing/searching. Note that these line numbers are
not stored as part of the <I>Majordomo</I> list and are not
permanently bound to individual addresses. In other words,
the subscriber #1 in "sorted" mode may not be the same as
subscriber #1 in the unsorted display.
</DD>
</DL>
<BR>
<H3>Modify Options</H3>
<DL>
<P>
<DT><B><CODE>Use 2-Column Table For Configuration File</CODE></B></DT>
<DD><I>MajorCool</I> will, by default, display the list
configuration file as a 2-column table: keywords on the
left, values on the right. Although this makes it easy to
locate keywords, it can make for a very wide display. If
disabled, a more compact single-column format is used.
</DD>
<P>
<!--DT><B><CODE>Show All Fields Of Configuration File</CODE></B></DT>
<DD>A typical <I>Majordomo</I> config file has over 40 variables,
many of which are seldom needed for basic list administration.
This preference setting toggles between "basic" and "full"
config mode, where "basic" mode shows only the keywords defined
by the site admin in the <CODE>@admin_keywords</CODE> definition.
</DD>
<P-->
<DT><B><CODE>Show Help With Configuration File Fields</CODE></B></DT>
<DD><I>Majordomo</I> provides field-level help descriptions as
comments in the list config file. If Help is enabled, these
comments will also be visible on-screen when editing the list
configuration. Since these comments use a significant amount of
screen real estate, experienced users may disable their display.
</DD>
<P>
<DT><B><CODE>Show Majordomo Subsystem For Each Configuration Field</CODE></B></DT>
<DD><I>Majordomo</I> consists of multiple subsystems -- the
aliasing/address setup, the archive program, the digest program,
the <I>Majordomo</I> command processor, and the list itself.
This option will indicate which subsystem each keyword applies
to.
<P>
<DT><B><CODE>Maximum Size Supported By Browser TextArea</CODE></B></DT>
<DD>List member files are edited using what is called a
TEXTAREA element. On many browsers, the number of bytes that
can fit within a TEXTAREA is limited, which can cause a
problem when managing lists with many subscribers. Changing
the value of this Preference will not change the capability
of the browser -- only the manufacturer can do that. However,
what this value will do is implement a threshold at which
<I>MajorCool</I> will attempt to take alternative actions in
order to get around the limitation. Alternative actions
include switching to 'append' mode, or editing a subset of
the list that matches a pattern.
</DD>
</DL>
<!--END PREFS-->
<A NAME="REMOTE">
<H2>Remote Invocation & Embedded Buttons</H2>
</A>
<P>Certain <I>Majordomo</I> list functions such as <CODE>subscribe</CODE>,
<CODE>unsubscribe</CODE>, <CODE>info</CODE>, <CODE>intro</CODE>, and
<CODE>who</CODE> can be accessed independent of the normal site-wide
BROWSE view. By using the <CODE>remote</CODE> interface, one-touch buttons
can be embedded in external Web pages to invoke <I>MajorCool</I> remotely.
(Since it is a subset of the BROWSE functionality, the BROWSE module must
be enabled; there is no way to have BROWSE disabled and still have
access to <CODE>remote</CODE> mode.)
<P>To access the remote interface of <I>MajorCool</I>, a FORM must
be used meeting the following requirements:
<UL>
<LI>A form <CODE>ACTION</CODE> referring to your <I>MajorCool</I>
instance. The form <CODE>METHOD</CODE> can be either <VAR>GET</VAR>
or <VAR>PUT</VAR>.
<BR>
<FONT SIZE=-1>
e.g.<BR>
<B><FORM ACTION="http://listserv/cgi-bin/majordomo" METHOD=GET></B></FONT>
<P>
<LI>An <CODE>action</CODE> variable (usually a <CODE>hidden</CODE>
element) set to <VAR>remote</VAR>.
<BR>
<FONT SIZE=-1>
e.g.<BR>
<B><INPUT TYPE=hidden NAME=action VALUE=remote</B>></FONT>
<P>
<LI>A <CODE>list</CODE> variable identifying the list that
this operation will apply to. This can be implemented as a hidden,
text, pull-down, or other element as required.
<BR>
<FONT SIZE=-1>
e.g.<BR>
<B><INPUT TYPE=hidden NAME=list VALUE=list-name></B></FONT>
<P>
<LI>A <CODE>command</CODE> variable identifying the command that
will be applied to the list. This can be implemented as a hidden,
text, pull-down, or other element as required.
<BR>
<FONT SIZE=-1>
e.g.<BR>
<B><INPUT TYPE=hidden NAME=command VALUE=subscribe></B></FONT>
<P>
<LI>A <CODE>siteaddr</CODE> text element, which is where the
user will enter their e-mail address (or other suitable input for the
<CODE>siteaddr()</CODE> function). This is the same type of input as
would be expected of the <I>MajorCool</I> instance if it were not
accessed remotely. In other words, if your installation's main screen
expects an X.500 attribute, your remote form must also. NOTE: This field
is required even for non-subscription requests, since commands such as
<CODE>who</CODE> and <CODE>info</CODE> often use the e-mail address
to validate access privileges.
<BR>
<FONT SIZE=-1>
e.g.<BR>
<B><INPUT TYPE=text NAME=siteaddr></B></FONT>
<P>
</UL>
<P>You can combine these elements to provide a variety of remote
invocation styles:
<FONT SIZE=-1>
<UL>
<H4>Basic Subscription</H4>
<FORM ACTION="/cgi-bin/majordomo" METHOD=GET>
<INPUT TYPE=hidden NAME=action VALUE=remote>
<INPUT TYPE=hidden NAME=list VALUE=list1>
<INPUT TYPE=hidden NAME=command VALUE=subscribe>
Address <INPUT TYPE=text NAME=siteaddr>
<INPUT TYPE=submit VALUE=Subscribe>
</FORM>
<H4>Subscription Pick-List</H4>
<FORM ACTION="http://sparc/cgi-bin/majordomo" METHOD=GET>
<INPUT TYPE=hidden NAME=action VALUE=remote>
<INPUT TYPE=hidden NAME=command VALUE=subscribe>
Address <INPUT TYPE=text NAME=siteaddr>
<SELECT NAME=list>
<OPTION VALUE=list1>list1
<OPTION VALUE=list2>list2
<OPTION VALUE=list3>list3
</SELECT>
<INPUT TYPE=submit VALUE=Subscribe>
</FORM>
<H4>Command Choice</H4>
<FORM ACTION="http://sparc/cgi-bin/majordomo" METHOD=GET>
<INPUT TYPE=hidden NAME=action VALUE=remote>
<INPUT TYPE=hidden NAME=list VALUE=list1>
<INPUT TYPE=radio NAME=command VALUE=subscribe CHECKED>subscribe
<INPUT TYPE=radio NAME=command VALUE=unsubscribe>unsubscribe
<INPUT TYPE=radio NAME=command VALUE=info>info
<INPUT TYPE=radio NAME=command VALUE=intro>intro
<INPUT TYPE=radio NAME=command VALUE=who>who
<BR>
Address <INPUT TYPE=text NAME=siteaddr>
<INPUT TYPE=submit VALUE="Do It!">
</FORM>
</UL>
</FONT>
<P>As might be expected with <I>MajorCool</I>, this remote invocation
offers more functionality than the basic <I>Majordomo</I> mail-based
interaction, providing:
<UL>
<LI>on-screen display (where allowed) of <CODE>info</CODE>,
<CODE>intro</CODE>, and <CODE>who</CODE> query results
<LI>immediate feedback of <CODE>subscribe</CODE> and
<CODE>unsubscribe</CODE> status
<LI><CODE>siteaddr()</CODE> address translation & equivalencies
</UL>
<HR>
<A HREF="install.htm">[Previous: Install]</A>
<A HREF="future.htm">[Next: Future]</A>
<A HREF=".">[Top: Intro]</A>
<A HREF="..">[Home]</A>
<A HREF="mailto:Bill.Houle@SanDiegoCA.NCR.COM">[Feedback]</A>
<CENTER>
</BODY>
</HTML>
syntax highlighted by Code2HTML, v. 0.9.1