Subscription Security

 

Who May Join?

By default, ListManager lists are "open", meaning no administrator needs to approve a member. You may make individual lists private, closed, or password protected in Utilities: List Settings: New Subscriber Policy: Security.

 

Furthermore, you may wish to restrict your mailing list to only allow subscription requests performed using the web interface. For instance, you could put your web interface on an Internal-access only web server, so that outsiders cannot get to it. This would allow you to have an "open" mailing list, where people in your company could join by getting to the web interface form, but outsiders could not. Subscription options may be selected in Utilities: List Settings: New Subscriber Policy.

 

ListManager also supports explicit banning of members, and the "reverse banning". The ban member feature would allow you, for instance, to ban someone who was an employee of a competing company from joining your mailing list.

 

Reverse banning is a setting which allows you to ban everyone except those that match your pattern. An excellent use of this feature is to have a corporate mailing list that is open, so that anyone in your company can join easily and automatically, but that nobody from the outside can join. To do this, you would tell ListManager to ban all addresses not having your corporate domain name on their email address, for example "acme.com".

 

Private Lists

A private mailing list is one where only people who a list administrator as personally approved are allowed to join the mailing list.

 

With a private mailing list, people can request to join the mailing list, by filling out the Join web page or sending in an email request. With a private list, people who request to join are not enabled until the list administrator approves them. Whenever someone requests to join, the list administrator(s) can receive notification of the join request, and approve or reject them.

 

To create a Private mailing list, create a mailing list as you normally would, using the Create Mailing List web page. Then, in Utilities: List Settings: New Subscriber Policy: Security, select Private.

 

After you have created your list, you will want to create a member who is a list administrator, and who receives the email notifications of the join requests. Go to Utilities: Administration: Administrators: List Admins to create additional list administrators.

 

Now, whenever someone asks to join the mailing list, you will receive an email notification of their request. You will then be able to approve or reject them with an email command, and the notification message will tell you which commands to send back to approve or reject the person.

 

Confirmed Subscriptions

ListManager can send a "confirmation request" when a person asks to subscribe to a mailing list. The confirmation request message is sent to the email address that was subscribed. The person must receive this confirmation request message, and reply to it, in order for the membership to be activated. With a confirmed subscription, ListManager has proven that the email address given to it is indeed the email address of the person who requested the subscription.

 

Confirmed subscriptions prevent two problems:

 

1. People sometimes join a mailing list under a fake email address, in order to post harassing or otherwise inappropriate messages to the mailing list. With a confirmed subscription, people must use an email address that they can receive email at, which provides a "paper trail" that points back to a real person.

 

2. In order to harass other people, some malicious people will subscribe the other person to mailing lists that the person never asked to be signed up to. If enough mailing lists are involved, the person may receive a huge amount of email and this can be a real inconvenience to them. This is especially a problem when a web form is used to subscribe people, as it is very easy to enter someone else's email address in that form. Confirmed subscription solve this problem, because the person being abused gets the confirmation request, and does not confirm, so that they membership is never activated.

 

You may configure subscription confirmations in Utilities: List Settings: New Subscriber Policy: Confirmation.

 

Unsubscribing

There are many ways to unsubscribe from a ListManager mailing list:

 

    Log into the discussion forum interface, select My Forums, and click "unsubscribe" next to a list.

    Send the command "unsubscribe listname" to listmanager@your-server-name.com.

    Send the command "unsubscribe listname your-email-address" to listmanager@your-server-name.com.

    Forward any posting you receive from a mailing list to the unsubscribe-listname@your-server-name.com address.

    Click on an unsubscribe link provided in an email message.

 

If an unsubscribe request is made with the "unsubscribe" command sent to listmanager@this-ListManager-server.com, as in "unsubscribe jazztalk", then the person named in the From: field is unsubscribed. If the email address named in the From: field is not a member, ListManager returns a message to that person saying that they could not be unsubscribed.

 

ListManager also provides the option of naming an email address on the "unsubscribe" command line, such as the command "unsubscribe jazztalk bob@example.com". In such a case, if unsubscribe confirmation are enabled for the list, then a confirmation message is sent to the subscriber, then ensure that they are same person and not that someone else is trying to unsubscribe them.

 

When mail is received at the "unsubscribe-listname@…" address, ListManager tries to determine who the subscriber is and automatically removes them. In most situations, this works very well.

 

The ListManager unsubscribing logic for unsubscribe requests received at the "unsubscribe-listname@…" is fairly sophisticated, and here is how it works. When ListManager receives a message to the "unsubscribe-listname@…" address, ListManager goes through the following steps:

 

First looks for X-Lyris-Member-ID in the header. If it's there, that's who gets unsubscribed. This catches almost all cases, except when the forwarding program strips out the headers (such as in this example).

Looks for a purgeid tag in the header (X-Lyris-To:) and then in the body. If it's there, that person gets unsubscribed. Note: purgeid tags are "cleaned up" before they are re-posted to a list (i.e., in quoted message), by removing the square brackets. In the example below, the square bracketed email address clearly identifies "wantsoff", so that who gets unsubscribed. Also note that MS-Mail generated addresses with the text [SMTP:...] are correctly skipped by ListManager.

3. Looks at the Return-Path (the MAIL FROM:<> sender), and sees if it's a member. If it is, then this is likely a forwarded message, and unsubscribe that person. Pegasus Mail does this.

Finally, if none of the above is valid, the person named in the From: header is unsubscribed.

You may have ListManager always send unsubscribe confirmations, or only when the unsubscribe request is questionable (e.g., when the address being unsubscribed is different from that in the email header).