Kavi Help CenterKavi Mailing List Manager Help
| Chapter 16. Access Control | ||
|---|---|---|
 |
Part I. Concepts | 
|
Table of Contents
The Kavi® Mailing List Manager offers a number of ways to control access to mailing list content depending on the organization's goals and policies and the purpose served by the list. Since mailing list content is accessible through email as well as through webtools, both of these routes must be considered when implementing access controls.
Mailing lists are a natural way for technical standards organizations to provide openness and transparency into the organization to members, potential members and the community at large. They help raise interest in the organization and can offer nonmembers a way to contribute to the goals of the organization.
- Openness
An mailing list can be as open and inclusive as desired. Or not. It can be open to contributions from the general public, to subscribers only or selectively moderated. There are certain trade-offs that need to be considered when making this decision. The more inclusive the mailing list, the less control that the organization has over the quality and type of content being distributed through the list. The purpose of the list has to be considered when deciding how open the list should be to those who may want to contribute content.
- Transparency
Transparency is dependent on how accessible mailing list content is to whomever might be interested in subscribing or viewing archives. Are links to the mailing list available on Public Areas of the website so the public can subscribe directly or access the archives? Do you have to be a logged-in account holder to subscribe or view archives or is the mailing list hidden unless you are already a subscriber?
Unfortunately, there is a downside to complete openness and transparency. A mailing list that is entirely open to the public is entirely open to spam. A mailing list that allows everyone to subscribe and access archives can't be used to exchange sensitive information. So, some form of access control is a necessity for almost every list. Yet the more open and transparent a mailing list is, the more power it has to reach the community outside the organization, to harness external input and foster broad adoption of standards developed in the organization. So, it is important to consider the trade-offs between open and controlled access and select the combination of controls that is most appropriate for the list's purpose.
Reasons to control access:
To protect the quality of list content
To protect the privacy of list content
Organizations want to sponsor mailing lists that reflect well on the organization and serve the purpose for which they were created. There are three key access points where controls can be set.
Mailing list access control points:
posting messages
subscribing
archives
There is some interaction between these three control points. The ability to post to a mailing list is based on a list user classification system that separates users into public versus subscribers, and enforces different access rules on different kinds of subscribers. The way that mailing lists manage different kinds of subscribers is explained in more detail in Subscription Types and Subscriber Lists. So in order to control the ability to post, the ability to subscribe has to be controlled as well. Access to archives is also based on list user classification.
There are two basically independent access routes: access via email and access via the Web. Access via email is set in the ezmlmezmlm-make argument string in the List Type on which the mailing list is based. Access via Kavi Mailing List Manager tools is set at the list level when a mailing list is added or edited.
The interactions between the controls set on these two different kinds of access routes can be complex. The basic layer of access controls are ezmlm access controls implemented in the List Type. When an administrator creates a mailing list, the most important task is to select a List Type that enforces appropriate controls on email access, particularly on the ability to post messages and to use ezmlm email commands to subscribe and retrieve archives. The options set at the list level only control Web-based access. It is possible for an inexperienced administrator to set up a mailing list with wide-open email access and restricted Web access.
A user accessing Kavi Mailing List Manager User Tools has been authenticated at login, so the system is able to recognize this user as a Kavi® Members account holder. But when a mailing list receives an email it can only recognize "who" sent the message by finding the envelope sender then checking to see if the sender is on one of its Subscriber Lists. If the sender is subscribed, then the mailing list "recognizes" the sender. The mailing list determines what level of access to grant the sender based on configurable rules set in the ezmlm-make argument string and and which Subscriber Lists the sender's email address is on. If it doesn't find the address, it classifies the sender as 'public', and most lists are configured to reject (or at least moderate) messages from public senders.
Many of the issues encountered by mailing list administrators and list users revolve around the dichotomy of the human versus the system perspective of sender identity. A human recognizes "who" sent an email by their name or username and associates this information with an actual human being. If a list users posts one message from their email account at work, then sends a second message from their personal email account, we humans will recognize that these messages were sent by the same person. But a mailing list only recognizes "who" sent an email if the sender's email address is on its Subscriber Lists. If this list user's business email account is subscribed as their primary address, the mailing list recognizes the sender of the first email message as a subscriber. But if this list user's personal email address isn't subscribed, the mailing list doesn't recognize the sender so the sender is classified as public. Since most mailing lists grant a higher level of access to subscribers than to the general public, the first message may be accepted and the second may be rejected or moderated, and the list user may not immediately understand why.
Back to topThere are two somewhat different hierarchical systems of user classification at work in a Kavi Mailing List Manager mailing list. The first is the system we've been describing, which is the ezmlm classification system that applies to email access. The second is the Kavi Members user classification system, which applies to access through Kavi Mailing List Manager webtools. This section presents a simplified view of how these two classification systems categorize users by level.
There are three levels of subscribers in ezmlm. These are derived from subscriber classes described in detail in Subscription Types and Subscriber Lists. Moderators have the highest level of privileges, subscribers are next, and public senders have the lowest level of privileges. There are two exceptions to this hierarchy, and both apply only to posting access. If the mailing list supports an Allow List, subscribers on the Allow List are classified as subscribers, but only when submitting messages to be posted. These privileges do not extend to email commands used to manage subscriptions or retrieve archives. The second exception is subscribers on the Deny List. These senders email addresses are blocked from posting, even if they would otherwise be eligible to post.
Ezmlm Subscriber Level Definitions
- moderator level
-
When a moderated mailing list receives an email from a sender using an email address subscribed to the 'Moderator List', the mailing list classifies the sender as a moderator. A moderator is the most privileged kind of list user, and their posts are always accepted, although the message may be sent to the moderation queue. Whatever level of permissions apply to subscribers are generally extended to moderators. The only exceptions are that moderators can't subscribe or unsubscribe to the Moderator List via email, and mailing list posts aren't distributed to the Moderator List (although moderators can certainly add Regular or Digest subscriptions for themselves if the mailing list accepts subscribe commands). The moderator may be able to access raw ezmlm archives that are closed to lower levels of list users.
Only moderators can use email moderation commands, which allow them to accept or reject messages that have been submitted to the mailing list for posting, and add users to the Allow List or Deny List if desired. See Moderation for more information.
- subscriber level
When a mailing list receives an email from a sender using an email address subscribed to the Regular Subscriber or Digest Subscriber Lists, the mailing list classifies the sender as a subscriber. It applies any rules that control subscriber access to email commands used to subscribe or retrieve raw archives. It also responds to messages submitted for posting according to the rules set for subscribers, making exceptions for users on the Allow or Deny Lists as mentioned previously.
- public (or non-subscriber)
-
When a mailing list receives an email command from a sender using an email address that isn't on any of its subscriber lists, or is only on the Allow or Deny List, the mailing list classifies the sender as public. This is the least privileged class of list user, and with the exception of public mailing lists, the email command is likely to be rejected unless it is an unsubscribe request.
When a mailing list receives a message to be posted from a sender using an email address that isn't on the Regular Subscriber, Digest Subscriber or Allow Lists, it classifies the sender as public. Unless this mailing list allows the public to post directly (which is extremely unlikely because the mailing list would be inundated with spam), the message is rejected or sent to the moderation queue according to list rules. Of course, if the sender is on the Deny List, the message is rejected.
There are four list user access levels that can be set in Kavi Mailing List Manager tools: public, account holder, subscriber and administrator. Kavi Mailing List Manager determines user level based on whether the user has an account and can log in, whether the user is shown as subscribed to this mailing list, and whether the user is an administrator.
When a mailing list is added or edited, the administrator can set Web Availability to determine the conditions under which links to the mailing list and subscription management tools are displayed, and set Web Archive Availability to determine which list users see the link to the Web archives.
Kavi Mailing List Manager List User Level Definitions
- admin
A logged-in, authenticated user who has access to Admin Area tools. When a mailing list is configured to be visible to administrators only, links to tools used to manage subscriptions are only displayed in Admin Area tools. Account holders who are subscribed to the mailing list see a link to the list on My Mailing Lists and can visit Mailing List Home but won't see the Change Subscription link. This setting is used for the most private kinds of mailing lists.
- subscriber
A logged-in, authenticated user who is already subscribed to this mailing list. When a mailing list is configured to be visible to subscribers only, account holders who are subscribed to the mailing list see a link to the list on My Mailing Lists, but this link isn't displayed to account holders who are not subscribed. When the subscribed account holder visits Mailing List Home, the Change Subscription link is visible. If this mailing list has Web archives, a link to the archives is also visible unless archives access is Administrators Only.
- account holder
A logged-in, authenticated user. When a mailing list is configured to be visible to account holders only, all account holders will see a link to the list on My Mailing Lists. When the account holder visits Mailing List Home they will see links to tools used to subscribe or unsubscribe. If this mailing list has Web archives, a link to the archives is displayed unless they are set to be visible to administrators only or subscribers only.
- public
A user who isn't logged in, and therefore, not authenticated. Links to the mailing list are displayed only if the list is publicly available. Same goes for the archives.
Similar but somewhat different methods of access control are available depending on the access route (i.e., whether this is is email access or Web access). Control of both routes is based on list user level, however there is some variation in the classification systems because users on the Web can be authenticated and identified as account holders, but when managing email access the software can only identify the email address of the envelope sender and see whether this address is on one of its Subscriber Lists. Access control usually includes a combination of automated controls—such as hiding links or rejecting email based on list user level—and manual controls such as moderation. Moderation is described in depth in the Concepts document Mailing List Moderation.
The true visibility and availability of a mailing list is the sum of both these parts. For example, to determine what level of list user has access to mailing list archives, you have to consider access settings for both routes. Generally, access through email is set more tightly because list users using this access route aren't authenticated. For example, a mailing list that is intended for use by account holders rather than the general public could be based on a List Type that only accepts archive retrieval commands from subscribers (moderators would also have access). But when the mailing list is added, access to the Web-based archives might be subscriber-only, or available to all account holders. So the raw archives might be subscriber-only while the Web archives are visible to all account holders.
Ezmlm provides separate controls for the three main access points, so that different access rules can be applied to subscribe commands, archive retrieval commands and message posting. The archives available through ezmlm email commands are raw archives only. The availability of Web-based archives is controlled through Kavi Mailing List Manager. Note that message posting is controlled exclusively through ezmlm; list-level settings only contribute indirectly by helping control the ability to subscribe through Kavi Mailing List Manager tools. If access to email commands used to subscribe and unsubscribe or retrieve archives is controlled, the mailing list will reject list users below the allowed level or reject all these email commands. Posting control mechanisms available in ezmlm include sending posts for moderation as well as rejecting them.
When a mailing list is added or edited through Kavi Mailing List Manager tools, the administrator can set Web access rules that show or hide links to Mailing List Home, the Web-based archives and subscription-management tools based on the user's Kavi Mailing List Manager List User Levels.
Restrictions on the posting process are designed to protect the quality of content distributed through the mailing list. Mailing list posting rules are determined by the List Type option 'Who can post to the list?' or by directly setting a combination of m/M, o/O, u/U and y/Y arguments in the ezmlm-make argument string. Information about posting access configuration of a particular List Type or mailing list is available through many Kavi Mailing List Manager tools, including the Manage Mailing Lists tool set. Posting rules should be published to list users through the mailing list's Policy and Usage Statement.
These rules are based on the sender's Subscriber Level, as previously described. More information on this subject is available in Subscription Types and Subscriber Lists. For more information on the different ezmlm posting access configurations, see the Appendix document Posting Access.
Back to topAs we've already seen, there are two routes that can be used to add mailing list subscriptions: email commands or Kavi Mailing List Manager webtools. If access to mailing list subscriptions is going to be controlled effectively, both of these routes need to be controlled, and the access control measures in place for each of these routes need to work harmoniously and make sense with the other.
Most administrators spend the majority of their time working with webtools so there is a tendency to think in terms webtools first and ezmlm email command access second, but list configuration works the other way around. The first consideration is the configuration of the List Type on which the mailing list is based. Make sure that the subscription access settings in the List Type are appropriate for the purpose that the mailing list is created to serve. If the List Type is a good fit for the use case, its easy to select Web availability settings that line up well.
There are two options at the list type level that work in combination to set access to ezmlm email subscription commands. The first switch, 'Subscription model' (S/s), defines whether the mailing list accepts email subscription commands from any list users at all. If set to -s, the mailing list rejects all email subscription commands. If set to -S, the mailing list does accept email subscription commands, but checks to see how the 'Public subscription requests' (P/p) argument is set. If -P is set, email subscription commands from public senders are rejected, so only subscribers are able to use email subscription commands. If -p is enabled, the mailing list accepts email subscription commands from all senders.
Ezmlm-make arguments
- -Sp combination
The -Sp combination is appropriate for mailing lists that are open to public subscribers.
- -SP combination
The -SP combination is appropriate for mailing lists that want to exercise some control over subscription via email without closing this route off altogether. When this combination is set, new subscribers have to be added via webtools, but users can change their subscription type, subscribe alternate email addresses and unsubscribe via email.
- -s
The -s setting is used when you want to close off the email subscription route and force all users to subscribe via webtools.
The 'List Availability' option is set when adding or editing a mailing list to control who can view and subscribe to the mailing list.
List Availability settings
- Public
Links to view and subscribe to the mailing list are displayed in Public Areas, so anyone can subscribe via webtools.
- Account Holders Only
All logged-in users see links to visit Mailing List Home and can subscribe directly to the mailing list.
- Subscribers Only
This setting prevents account holders from subscribing through webtools. The link to visit Mailing List Home is only displayed if the user is listed as a subscriber in the Kavi Mailing List Manager database, so a current subscriber has access to tools used to change subscription type or unsubscribe. However, an account holder who isn't currently subscribed won't see a link to this mailing list on the My Mailing Lists page and can't subscribe through webtools.
- Administrators Only
This setting renders the mailing list virtually invisible to everyone except administrators. This setting is generally used for admin-only discussion lists. In the event that a non-administrator is subscribed to this mailing list, the subscriber won't be able to visit Mailing List Home and won't have access to the Web archives or tools needed to manage this subscription. It is rare to subscribe users who can't manage their own subscriptions except in the case of small, mandatory announcements lists.
There is a trade-off between security and ease of use. Private lists disable public subscriptions on both routes, forcing non-subscribers to login and be authenticated before subscribing. This approach has several benefits, including improved user data capture and security, but it does make subscribing and unsubscribing less convenient from the user perspective. 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.
Open lists aren't necessarily public, they are simply accessible to a broader set of potential subscribers and give subscribers greater autonomy and control over their own subscriptions. These includes lists that allow the public to subscribe directly and lists that are accessible to any account holder. These include newsletters whose purpose is to reach the greatest possible subscribership and large, inclusive discussions.
There are also two routes that can be used to access mailing list archives. Arguments set in the List Type level control whether mailing lists based on this List Type have any archives at all and if so, whether the raw ezmlm-idx archives are accessible via email commands. Assuming the List Type does support archives, the 'Web Archive Visibility' option at the list level determines whether web-viewable MHonArc archives are created and if so, what level of list users has access to these archives through webtools. For more information, see Mailing List Archives.
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.
List Type settings
- Do not archive list messages (-A)
If this option is set, the list won't have any archives at all, since web-accessible archives are based on raw archives.
- Messages archived for moderator retrieval only (-ab)
To access the raw archives with email commands, the email must have originated from an email address subscribed to the Moderator List.
- Messages archived for subscriber retrieval (-aBg)
To access the raw archives with email commands, the email must have originated from an email address subscribed as a digest or regular subscriber.
- Messages archived for public retrieval (-aBG)
Anyone can use email commands to access the raw archives, providing the underlying List Type accepts public email commands.
These settings are only relevant if raw archiving is enabled in the List Type. If the 'List Archives' option is set to 'Do not archive list messages' in the List Type, mailing lists based on this List Type won't support archives of any kind, since Web archives are derived from the raw ezmlm-idx archives.
Note
Web archives can be hidden temporarily by editing the list and switching this setting when desired.
'Web Archive Visibility' settings
- Public
-
These archives can be displayed in the Public area of the website. Users do not have to login to see these archives. This setting is generally used for lists that are open to public subscriptions.
This is compatible with any ezmlm setting as long as raw archiving is enabled.
- Account holders only
-
Users who are logged in can see these archives.
This is most compatible with ezmlm settings that only accept ezmlm archive retrieval commands from subscribers.
- List subscribers
-
Logged-in mailing list subscribers can see these archives.
This is most compatible with ezmlm settings that only accept ezmlm archive retrieval commands from subscribers.
- Administrators only
-
The Web archives are only visible to administrators.
This is most compatible with ezmlm settings that disallow ezmlm archive retrieval commands altogether or limit access to moderators only.
- Do NOT show Web archives
-
The Web archives are hidden from everyone except system administrators, who can access the archives via URL.
Since it takes some system resources to create Web archives, they aren't generated unless they will be used, so this setting is only used when you need to hide web archives temporarily for a list that is not yet ready to go live, or for a committee that has been deactivated but not yet removed from the site or when some maintenance needs to be performed on the archives.
This is most compatible with ezmlm settings that disallow ezmlm archive retrieval commands altogether.
|
|
 |
|
| Chapter 15. Mailing List Archives |  |
Chapter 17. Application Integration |