Kavi Mailing List Manager Help

Chapter 3. How Mailing Lists Work

Mailing lists

A mailing list is a mailbox that accepts email from certain individuals and forwards the mail to subscribers. Mailing lists are used for one-way information dissemination between an technical standards organization and the public (i.e., newsletters) or to a select group (i.e., announce-only lists), or to conduct group discussions at various degrees of scope from public to private.

Mailing list are based on a relatively simple email forwarding mechanism similar to an email alias, except that mailing lists apply rules to govern access to list content and protect the quality of the content being distributed to the list. They also support features such as digests and archives that aliases do not. This is discussed in detail in Introduction to Mailing Lists and Aliases.

Back to top

Ezmlm and list configuration

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.

The Kavi Mailing List Manager uses ezmlm to configure a set of default list types that act as templates for actual lists. Each list type corresponds to one of the most common types of mailing lists. Mailing lists are created quickly by selecting the appropriate list type for the list you wish to create. For instance, if you were creating a newsletter, you would select the 'Newsletter' list type. The configuration of your new list will be based on the configuration of the underlying list type. You should study the documentation on default list types before attempting to create any lists.

List type configuration is set in the ezmlm-make argument string, which is exposed indirectly through super admin tools such as Add a List Type or Edit a List Type. Kavi Mailing List Manager also exposes this string directly so it can be manipulated by ezmlm experts. For information on specific ezmlm configuration options, see Ezmlm Quick Reference Guide.

Besides supporting features such as digests and archives, Ezmlm offers fine-grained control over permissions and processes, including who can subscribe, the subscription process, who can post, the posting process and who can view raw archives.

Back to top

Posting to mailing lists

Kavi uses qmail as its MTA, so qmail manages messages sent to and from Kavi Mailing List Manager mailing lists. For more information on qmail, see The Big Qmail Picture.

If you would like information on how to post a message to a mailing list, see the list's Policy and Usage Statement on Mailing List Home and review the list rules on posting. Public lists allow everyone to post, although posts may be sent for moderation. Private lists are only open to subscribers. You may also want to scan the short document on Composing Email to Post to a List before you post a message for the first time so you can avoid the most common pitfalls experienced by list newcomers.

All posts are screened at the firewall

Every company or organization that handles email must be protected by a firewall, so every email sent to a mailing list passes through a firewall where it is screened by virus and spam filters. As mentioned, anything caught by the spam filter is automatically deleted without any notification being generated. If the message contains a virused email attachment, the email is deleted, but the sender is warned. If the email passes the tests for malware and spam, it is sent to the mailing list where it may face further screening.

Posts are routed according to list rules

Once a message to be posted arrives at a mailing list, it is subject to rules that control posting. These rules frequently limit direct posting access to the higher levels of list users, such as subscribers or even moderators only. On the most restrictive lists, even moderator's posts are moderated. The software determines the sender's identity based on the sender's email address, looking for the email address on it's lists. It determines what kind of list user the sender is based on which list the email address is on, then applies the rules that apply to that level of list user. Depending on the list rules, the message may be routed directly to the list, to the moderation queue or the list may reject it outright.

Posting access control is somewhat complex, so there are several help documents that delve into this subject. If you aren't familiar with user levels (and why the mailing list thinks you are your email address), see List User Levels and Access Control. To learn more how moderated lists work, see Moderation.

How posts are routed

The way posts are routed is partly dependent on list rules and configuration. List may may be unmoderated, send all posts for moderation, or moderate public posts and allow subscribers, posters and moderators to post directly. If the list is unmoderated, public posts may be rejected, while other users messages are posted directly. If the list is moderated, posts from everyone except moderators may be rejected.

What the list can do with a message it receives:

Post it directly to the list

If subscribers are allowed to post directly, but public posts are moderated or rejected, only posts from subscribers, posters and moderators will be sent to be posted.

Send it to the moderation alias

If all posts are moderated, every message will be sent to the moderation alias. If only public posts are moderated, messages from unknown senders will be sent to the moderation alias. If all posts are moderated and only moderators are allowed to post, only messages from email addresses on the Moderator List will be sent to the moderation alias (and all others will be rejected).

Messages received by the moderation alias are forwarded to all moderators as well as the default list moderator 'listmoderator@listname.example.org'. When a message is received, a stub is added to track the message and record its status in the queue.

Send it to the rejection mailbox

If the list is configured to reject public posts but allow all others to post directly, only public posts will be rejected. If the list is configured so that only moderators can post and all other messages are rejected, all posts except those from addresses on the Moderator List will be rejected.

Messages sent to the rejection mailbox are packaged into rejection notifications and returned to their originating senders.

From the moderation queue, messages can be:

sent to the accept alias

Messages sent to this mailbox will be posted to the list, and forwarded to the moderation queue where the moderation stub that stores information about the action taken on each message in the queue will be updated.

sent to the reject alias

Messages sent to this mailbox will be returned to the sender with a rejection notice. The moderation stub that stores information about the action taken on each message in the queue will be updated.

automatically deleted

Messages in the moderation queue that aren't acted upon will eventually timeout and be returned to the sender with a notice. The moderation stub that stores information about the action taken on each message in the queue will be updated.

When a message is posted to the list, it is sent to the:

Regular Subscriber list

The Regular Subscriber list alias mailbox distributes the message to every user on the Regular Subscriber list.

Digest Subscriber list

If the list has a digest, the message is forwarded to a digest alias mailbox, where it is stored until the next digest is generated. Digests are configured so that they are generated after a set period of time or when the volume of messages reaches a set volume.

raw archives

If the list has raw archives, the message is forwarded to an archive mailbox, where it is either automatically added to the raw archives or stored until the next scheduled archive update, depending on list configuration.

List email construction

List email has certain features that distinguish it from email correspondence sent directly from person to person. Before a message is distributed to the list, the mailing list resets the information in certain fields. List email has these distinguishing features:

'To:'

First, the message is addressed to the list, so it has the listname in the 'To:' field instead of the individual subscriber's address. This protects subscriber's email addresses.

'From:'

To protect the poster's private email address, this field contains the mailing list name.

'Reply-To'

This field contains the address of a bounce handling mailbox. If an email sent to a subscriber bounces for any reason, the bounced email is returned to the address in the 'Reply-To' field rather than being sent to the list and distributed to all the list's subscribers. Instead, it is sent to be processed by an automated bounce handler. For more information, see Bounces and Automated Bounce Handling.

Note

These features sometimes result in list messages being misidentified as spam and deleted by spam filters. The spam filter may make this determination based on the fact that the 'To:' field doesn't contain the address of the intended receiver, or that the 'From:' and 'Reply-To' fields don't match.

Back to top

Database integration

The ezmlm subscriber lists

The Kavi Mailing List Manager maintains a set of four subscriber lists (i.e., Regular Subscriber, Digest Subscriber, Poster and Moderator). Depending on list configuration, people may be able to subscribe and unsubscribe to these lists via email. Public lists generally support this feature for all subscribers except moderators, who can only subscribe and unsubscribe through the Web tools for security reasons. People aren't allowed to subscribe to the Poster List, either, but if configuration allows, moderators can add posters via email, or subscribers can be added automatically or by administrators through Admin tools. Private lists tend not to accept subscribe and unsubscribe requests via email, forcing all subscription actions to be performed through the Kavi Mailing List Manager tools for the added security provided by authentication.

Subscribing through Web tools

When an individual is subscribed through Kavi Mailing List Manager tools, the primary email address is pulled from the Kavi® Members database. If the list is configured to use a Poster List and an alternate email address is stored in the database, the alternate email address is automatically added to the Poster List. If the subscriber's email address is changed through the Edit an Email Address tool, the Kavi Members database will be updated, and the address will be updated on all lists to which it is subscribed.

Subscribing via email

If a mailing list accepts subscription requests via email, users can subscribe and unsubscribe themselves directly to the Regular Subscriber and Digest Subscriber lists. Lists that accept email subscription requests may be configured to accept public requests (i.e., from unknown addresses), or may only accept requests from subscribers (i.e., from addresses on the Regular or Digest subscriber lists).

Database synchronization

These lists are managed by ezmlm, and the information in these lists is propagated to the Kavi Members database by periodic automatic or manual 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 Web site 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.

Ramifications

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 won't be 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.

Back to top