Kavi Mailing List Manager Help
Table of Contents
The Kavi Mailing List Manager employs ezmlm technology as the foundation of its mailing list management system. Ezmlm is powerful, scalable and well-integrated with qmail (an email management system from the same author). Ezmlm offers a rich set of features that provide additional security and fine-grained administrative controls that are not generally available in other mailing list management tools.
Since ezmlm is responsible for such a high percentage of mailing list behavior, this document refers the reader to other documents that explain specific aspects of mailing lists that are handled exclusively by ezmlm or by ezmlm in tandem with Kavi Mailing List Manager, including message posting, storage and subscriber management. This document assumes you are familiar with concepts introduced in How Mailing Lists Work and Access Control.Back to top
The Kavi Mailing List Manager bases mailing lists on preconfigured ezmlm templates called List Types. Each List Type corresponds to one of the most common types of mailing lists. These List Types allow new mailing lists to be created quickly. For instance, there is a default 'Newsletter' List Type that can be used to create newsletters.
List Type configuration determines whether features such as digests or archives are enabled (these are enabled in all default List Types) and offers fine-grained control over permissions and processes such as the posting process and who can subscribe via email or retrieve raw archives.Back to top
List Type configuration is set in the ezmlm-make argument string. The string is composed of a series of switches, represented by the letters of the alphabet which are either capital letters or lowercase depending on which way the switch is set. These switches are set through options available in Super Admin tools such as Add a List Type or Edit a List Type. Switches that aren't available through these options are set to default values that have proven appropriate for most mailing lists. The entire ezmlm-make argument string is exposed in these tools so that it can be manipulated directly by ezmlm experts.
Ezmlm arguments are used to configure Posting Access Controls, Subscribing Via Ezmlm Email Commands and Ezmlm Raw Archive Access, as explained in the Concepts document Access Control. The Appendix document Posting Access uses default List Types to illustrate the way that posting rules can be applied to different levels of list users.
Other ezmlm-make arguments are used to enable features such as digests, raw archives and trailer text. For more information, see List Features in the Appendix.
Detailed information on each of the options available in the ezmlm-make argument string and the meanings of each switch is available in the Ezmlm Quick Reference Guide in the Appendix.Back to top
As described in the Concepts document Email Commands, ezmlm supports an array of email commands, including subscribe and unsubscribe commands, commands used to retrieve messages from the raw ezmlm-idx archives, and commands used to moderate a mailing list. These are enabled in the ezmlm-make argument string.
If a mailing list is configured to accept subscription requests via email, public users can subscribe directly to Regular Subscriber and Digest Subscriber lists. Subscribers can also unsubscribe via email commands. If this feature is disabled in the ezmlm-make argument string, all subscriptions will have to be added through Kavi Mailing List Manager tools or, if this is a, through automated processes.
If a mailing list is configured to accept email archive retrieval commands, public users can retrieve messages from the raw ezmlm-idx email archives, as described in Ezmlm Raw Archive Access and the Concepts document on Mail Archives.
For each mailing list, ezmlm manages one or more Subscriber Lists, which may include 'Regular', 'Digest', 'Moderator', 'Allow', 'Poster' or 'Deny'. These are described in detail in the Concepts document Subscription Types and Subscriber Lists.
Subscriber Lists are managed by ezmlm, and the information in these lists is propagated to the Kavi Mailing List Manager database by periodic database synchronization operations. See the page help for the Synchronize Lists tool for more information.
Since the Kavi Mailing List Manager only recognizes email addresses, a subscriber's record in the Kavi Members database can only be located and updated if a subscriber submits an email subscription request from an address that appears in the Kavi Members database. This means that an individual in the Kavi Members database must send email subscription requests from their primary or alternate email address (assuming the website collects alternate addresses) to be properly identified and have their updated subscription information associated with their personal record. If the individual subscribes via email under an unknown address, the software has no way of connecting the subscription with the individual's database record. As far as the software is concerned, any unknown address on its subscriber lists is classified as a public subscriber.Back to top
This means that some of the public subscribers on lists that accept email subscription requests from the public actually belong to members who have subscribed under email addresses that aren't in the Kavi Members database. Because the subscribed address isn't connected with the individual, the subscription isn't accessible through User tools, and any updates performed on the individual's primary or secondary email address in the database won't be propagated to any list subscriptions where the individual is subscribed as a public user. Likewise, any updates to the addresses associated with the public subscriptions won't affect the primary or secondary email addresses in the Kavi Members database.
This discrepancy gives rise to several problems:
"List rot" is a corollary of the second law of thermal dynamics regarding an ordered system's tendency towards entropy. Every now and then a subscriber moves to a new job or ISP and the email address under which they are subscribed becomes invalid. You can expect some subscribers to update their addresses all of the time, and you can expect others to update their addresses some of the time, but you can't expect all subscribers to update their addresses all of the time. The tendency of the number of bad email addresses to grow over time is called list rot. Lists combat list rot with automated bounce handling.
Members expect the system to automagically divine their identity, even when they subscribe or post to a list under an email address that hasn't been added to their Member record. This is because people are able to conceptualize that an email address belongs to an individual human being who also happens to be a subscriber, whereas software has no ability to conceptualize whatsoever—to the Kavi Mailing List Manager, a subscriber is an email address on one of its subscriber lists. It can pass these addresses and subscription information to Kavi Members, and Kavi Members can associate the subscription information with a member record, but only if it finds a matching address in that member's record.
In consequence, user expectations are often surprised when they are unable to access a subscription or email address added via email, or when an address change performed through a Web tool doesn't update their address information on lists where they are public subscribers.
This same situation inhibits complete data capture of member list participation, but lists that accept public subscription requests are convenient for members because they can easily subscribe under a personal or temporary address. It is also the best way to facilitate a large public subscribership, which makes it ideal for newsletters.