A major domus

Posted: 18th March 2015 by knoppi in Computer Stuff, Linux
Tags: , ,

For several projects I recently felt the urge to dive into the world of mailing lists. Since I prefer having full control over such things rathern than delegating them somewhere, my first step was looking into my own webhosting package. It includes the the possibility to set up majordomo-mailinglists – I don’t know the exact number, it is nowhere stated, but the number email-adresses which for my package is 500, might be a limit – which, most likely, is sufficient.
My demands for a mailing list are the following ones.

  • little administration, high control
  • easy for users
  • preferably a closed list with control over external visitors
  • controllability of the mail header up to a certain degree
  • a cool unsubscribe-by-mail feature
  • an archive available

And some minor features which I’m going to explain in more detail later.

Can this be accomplished with majordomo? Are there other caveats not visible at this point?

I am no expert on mailing lists in general and on majordomo in special. An important feature, hence, is documentation, so I can quickly step into this topic.
Documentation of Majordomo seems quite complete, since it is already a very old project, so half a day of reading and playing around brought great advances.
A lot of the features and problems listed here might be normal or just a result of the particular configuration my webhoster has chosen.

Most of my webpages are lying at all-inkl.com.
They have preinstalled Majordomo 1.94.5, which is the current stable release from January 19th, 2000 (more about this later).
Also, when searching on google for Majordomo the instructions on the all-inkl-website appear as the second result.

They assign quit clumsy names to mailing lists. The website I want do create a mailing list for is the subdomain sub of my domain domain.tld.
If I chose the “name” listname it gets actually converted to listname-sub-domain-tls and the related email-addresses are even more complicated:

listname-sub-domain-tls@sub.domain.tld
owner-listname-sub-domain-tls@sub.domain.tld
listname-sub-domain-tls-request@sub.domain.tld

I, hence, created an email-forwarder listname@sub.domain.tld pointing to listname-sub-domain-tls@sub.domain.tld.

To accomplish to above stated aims I, now, cofigured my mailing list using standard majordomo commands found in the Majordomo FAQ, the all-inkl HOWTO, and some Majordomo configration documentation.

Most of the settings can be left on their default values, so I only set specific values using the following commands:


newconfig %%list-name%% %%admin_password%%
# description: a short description
description = Discussion board %%list-shortname%%

# Comment string that will be retained across config file rewrites.
comments << END This is a sample configuration file for a main list. END # passwords admin_passwd = %%admin_password%% approve_passwd = %%approve_password%% # administrivia [bool] (yes)
# No, because the footer contains the unsubscribe info which very
# often results in BOUNCE
administrivia = no

# restrict_post - external posts are not desired
restrict_post = %%list-name%%

# access settings -
# should be overwritten by restrict_post, this is the minimum standard
get_access = list
index_access = list
info_access = open
intro_access = list
which_access = list
who_access = list

# message footer with unsubscribe info
message_footer << END - --- You receive this mail because you subscribed to the %%list-shortname%% mailing list. For unsubscribing from the list send an *empty* message %%list-shortname%%-unsubscribe@%%domain.tld%% END # additional mail headers useful for some mail clients message_headers << END List-Id: $LIST List-Unsubscribe:
-
END

# moderation
moderate = no

# reply_to - the email-forwarder
reply_to = %%list-shortname%%@%%domain.tld%%

# strip - yes, no need for real names
strip = yes

# subject_prefix - none, sorting by list-id is better
subject_prefix =

# subscribe_policy and unsubscribe_policy: users choice, thanks to
# announcements I can notice the changes
subscribe_policy = open+confirm
unsubscribe_policy = open+confirm

Replace the elements between double %-signs with the corresponding values where %%list-name%% is the full name of the mailinglist while %%list-shortname%% is the abbreviation we installed the email-forwarder for.
In order to obtain a full configuration file with explicitly stating all the omitted values, and since I haven’t tried if the mailinglist is working at all with this rudimentary configuration, we immediately send

writeconfig %%list-name%% %%admin_password%%

to majordomo@sub.domain.tld.

A lot of the aforementioned criteria should be fulfilled by now. We still lack the cull unsubscribe-address which is already mentioned in the message-footer.
To this end we set up a second mailing list listname-unsubscribe with the same game about mail-forwarders as before.
This second list has exactly one member: majordomo@sub.domain.tld (you can add more members for debugging reasons).
The relevant elements of the configuration file are:


newconfig %%unsubscribe-list-name%% %%admin_password%%
admin_passwd = %%admin_passwd%%
approve_passwd = %%approve_passwd%%

# noone else should gain any control over this list
get_access = closed
index_access = closed
info_access = closed
intro_access = closed
subscribe_policy = closed
unsubscribe_policy = closed
which_access = closed
who_access = closed

# unsubscribe lists should not be seen by lists requests
noadvertise << END /./ END # these two entries are actually responsible for the unsubscribe request message_fronter << END unsubscribe %%list-name%% END reply_to = $SENDER

The subsequent

writeconfig %%unsubscribelist-name%% %%admin_password%%

completes the configuration.
Now, sending a mail to listname-unsubscribe@sub.domain.tld triggers, independent of the content of the mail body, an unsubscribe request. Thanks to our main mailing list's settings we have to confirm this, so noone else can unsubscribe us easily.

Actually, that's already quite fine. But the setup of digest and archives is so badly documented - and, moreover, seems to be simple only if you have your own server.
This ist the point where I gave up, also leaving these questions open:

  1. Why majordomo?
  2. Whouldn't I choose a more modern mailing list systrem?
  3. Are there important security issues?

I will choose one of the free mailing laist hosters available on the net.