Mailing lists are a natural way for technical standards organizations to provide openness and transparency to members, potential members and the community at large. They help raise awareness and interest in the organization, and can offer nonmembers a way to contribute to the goals of the organization.

The principal of access control is diametrically opposed to the principals of openness and transparency, so these competing goals must be balanced when defining list policy, and the trade-off between the loss of openness and transparency and the benefits of access control must be considered. Unless a list is to be entirely open to the public (and therefore, entirely open to spam), some form of access control is a necessity.

Publicly subscribable lists or lists with publicly viewable web archives are only useful to share information your organization wants everyone to see. Public lists with unrestricted posting are wide open to spammers, and usually become so flooded with spam that other mailing list users abandon the list. For this reason, perfectly open and transparent lists are rare.

Most organizations and their members expect the lists they sponsor to be relatively free from spam because of the drain on system resources and list users' time. They also host lists that need to be kept private so the list can be used to exchange potentially sensitive information.

Private lists, such as those that serve work groups, may require subscribers to be added by administrators to prevent unauthorized people from subscribing themselves to the list. Archive access is probably limited to subscribers. Private lists usually only grant direct posting privileges to subscribers, but can make exceptions for posts from trusted non-subscribers by designating posters or approving individual posts. These non-subscribers may not be allowed to view list content, even though they are allowed to post.

There are three levels of subscribers, derived from ezmlm subscriber types. Moderators have the highest level of privileges, subscribers are next, followed by the public. Posters are a special case, as only certain kinds of lists support a Poster List, but in these cases, posters have the same posting priveleges as subscribers (i.e., they can post directly to the list).

There are three member levels derived from Kavi Members, but in this hierarchy a 'member' is defined as any user who appears in the Kavi Members database and can login to the My Account page.

As mentioned, Kavi Members manages user authentication and uses types and roles assigned to the user to determine the user's member level and access to Web pages. Member levels define whether lists and archives are visible on pubic or Member pages, or only on Admin pages, in which case they are effectively invisible to the general membership.

Access control includes automated controls, such as automatic rejection of posts by certain levels of users, and manual controls, such as moderated posting. Moderation is used in tandem with automated access control mechanisms, as described in depth in List Moderation.

List configuration, especially configuration inherited from the underlying list type, determines the level of access a user must have in order to post, access archives or subscribe. For more information on list types and how they interact with list level settings, see List Types. For examples of preconfigured list types, see Default List Types.

There are two options at the list type level that are used to limit the ability to subscribe. The 'Public subscription requests' option defines whether lists of this type accept subscription requests from public senders via email, and the 'Subscription model' option defines whether users are allowed subscribe themselves directly or if subscriptions can only be added by administrators (i.e., a moderated subscription process).

The 'List Availability' option at the list level is used to limit list visibility by controlling which member level pages the mailing list will be displayed upon. If set to 'public', then anyone can see and subscribe to the list through public pages. If set to 'members only', logged-in users will be able to subscribe to the list. If set to 'administrators only', the list will be virtually invisible. The list won't appear on Member pages and subscriptions will have to be added by administrators.

The 'Public subscription requests' option is set to 'No' for the private default list types, including 'Announce Only', so that all subscribe and unsubscribe actions must be performed through the web pages for private lists. This approach has several benefits, including improved user data capture and security. However, it does make subscribing and unsubscribing less convenient from the user perspective. The option is set to 'Yes' for public default list types, including 'Newsletter'.

Approximately half of the default list types have the 'Subscription model' option set to 'Open subscription model with confirmation', which allows users to subscribe themselves to lists of this type, providing the 'List Availability' option for an individual list is set to display the list to users at their member level. If the 'List Availability' option is set to 'administrators only' for a particular list, the 'open' setting at the list type level is rendered virtually meaningless. If it is set to 'public', anyone will be able to view and subscribe to the list. A public newsletter is the most common use case for this combination of settings.

The 'Closed subscription model with confirmation' setting is used for private, "invitation-only" lists. On these kinds of lists, users can only be subscribed or unsubscribed by administrators. These types of lists are well-suited for small, select groups that use the list to exchange potentially sensitive information, such as an organization's board of directors, work groups, technical committees, marketing committees and task-oriented teams. This setting is also appropriate for lists used to distribute targeted announcements to select groups of people as opposed to the general public.

Depending on list configuration, raw archives may be retrieved using Email Address Commands. If access is restricted, the email must have originated from an email address subscribed at the appropriate subscriber level or above.

Remember that these list-level settings will be irrelevant if the 'List Archives' option at the list type level is set to 'Do not archive list messages', because lists with this type of configuration do not support archives. Period.