mlmmj with openSMTPd and eQmail

This describes how to use mlmmj with openSMTPd and eQmail. It is assumed that you are familiar with both MTA's so far that they are up and running as well you read the mlmmj documentation or at least have it on site. There is mentioned eQmail always, but the instuctions are valid for qmail-1.03 and netqmail too.

And why two MTA's with one mailing list manager in one place?

• most steps are identical, the ones of the MTA which won't be used can be ignored
• to switch permanent or temporarily between the MTA's as easiest as possible
• load-balancing with different MTA's, backup MX or …

First there are some name conventions which will be used further:

• dyndn.es - this is the top domain
• lists.dyndn.es - this is a virtual subdomain name used by mailinglists
• user-support - name of the virtual user who owns the list (be aware of the minus sign)
• support - this is an alias for user-support and the <LISTNAME>
• /home/mails - the top level folder which contains all mail users (and their mails )
• /home/mails/lists - the spooldir of mlmmj
• vmu - a system account (virtual mail user) with id 65001
• vmg - a system group (virtual mail group) with id 65002

From this the list address is  support@lists.dyndn.es  . The list itself calls  user-support  (like the list owners name) and the home directory for now is  /home/mails/user-support  (this will be change sligthly later on). /* It is urgently recommended to use not a “+” or “-” sign in the user part of the list address. It is explained later on why. */ It is assumed that all mlmmj binaries are located in  /usr/local/bin  . If user vmu and/or group vmg doesn't exist on the system it is recommended to create them before proceed:

groupadd -g 65002 vmg
useradd -u 65001 -g 65002 -s /bin/nologin vmu

The UID and GID will be used later on. Alternative nobody/nogroup can be used too.

Before we start lets do a few thoughs about the organisation of lists. First let's see how mlmmj works. To create a new list there is the command  mlmmj-make-ml  , which creates a folder named by <listowner> (here  user-support  ) with the necessary files and folders of a list inside a spooldir (here  /home/mails  ).

In case that there is or will be more than one mailing list it is a good idea, to put all mailinglists in a subfolder (here  lists  ). The reason is that we have to create a cron job for maintenance later on. Usually there is one maintenance job for each list needed, by using a separate  lists  folder we can do one job for all lists. For this mandatory recommendation we create  /home/mails/lists  as spooldir:

mkdir /home/mails/lists

So from now on, the home directory of user-support is changed to  /home/mails/lists/user-support  . /* To include this mandatory recommendation there have to be the  lists  folder added to the path of the home directory, like  /home/mails/lists/user-support  .

creates the folders and files for a new mailinglist. The full command with the definitions above would be

/usr/local/bin/mlmmj-make-ml -L user-support -s /home/mails

All needed files and folders will be created directly in  /home/mails/user-support  , the home directory of the list owner. */

To get a cleaner structure it is maybe a good idea too, to use a subfolder  Listdir  inside the home of the list owner. This can be compared with Maildir, which separates its structure in a folder by default. Files like  .forward  and/or  .qmail  and similar ones can then (later on) be created outside the list directory. But for this we have to create the list owners home directory before we create the list itself:

mkdir -p /home/mails/lists/user-support
/usr/local/bin/mlmmj-make-ml -L Listdir -s /home/mails/lists/user-support

Add a new user  user-support  to the user table:

user-support   65001:65002:/home/mails/lists/user-support

and an alias to the aliases table:

support: user-support

Create a dot-forward file in the home directory of user-support:

echo "|/usr/local/bin/mlmmj-recieve -F -L /home/mails/lists/user-support/Listdir" > /home/mails/user-support/.forward

Add a new user to  /var/qmail/users/assign  :

+user-support:user-support:65001:65002:/home/mails/lists/user-support:::

and create a new alias

echo "user-support" >> /var/qmail/alias/.qmail-support

Create a dot-qmail file in the home directory of user-support

echo "|/usr/local/bin/mlmmj-recieve -F -L /home/mails/lists/user-support/Listdir" > /home/mails/user-support/.qmail

  Do not use dot-forward or preline in the  ~/.qmail  file! This will not work properly!

While mlmmj and openSMTPd uses the “+” (plus) sign as delimiter of address extensions on default, eQmail uses a “-” (minus) sign. So there are no changes necessary for openSMTPd, but three different ways to handle it with eQmail. Only one of them can be used at the same time.

Create a file  delimiter  in the control directory of the list:

echo "-" > /home/mails/user-support/Listdir/control/delimiter

On the first view this seems to be the easiest way. But the disadvantage is that the texts of mlmmj still contains the “+” sign. Means the information contains wrong mail addresses. The texts can be changed manually, but there perhaps situations that this have to be reverted or will be reverted by e.g. an update.

Nevertheless we need one more alias to handle all address extensions. In the qmail alias folder do;

ln -s .qmail-support .qmail-support-default

As of the way how eQmail handles aliases these necessary ones have to be created (exactly so):

cd /var/qmail/alias
ln -s .qmail-support .qmail-support+subscribe
ln -s .qmail-support .qmail-support+subscribe-default
ln -s .qmail-support .qmail-support+confsub-default
ln -s .qmail-support .qmail-support+unsubscribe
ln -s .qmail-support .qmail-support+confunsub-default
ln -s .qmail-support .qmail-support+help
ln -s .qmail-support .qmail-support+get-default
ln -s .qmail-support .qmail-support+faq
ln -s .qmail-support .qmail-support+owner

This looks like much more work like changing the delimmiter of mlmmj, but it isn't. The advantage is that the mailing list can be used by eQmail and openSMTPd without any changes. For subscribes are two aliases necessary,  .qmail-<LISTNAME>+subscribe  and  .qmail-<LISTNAME>+subscribe-default  . The first one is to subscribe to the regular list through address <LISTNAME>+subscribe, the second one (with suffix “-default”) is a.o. for address <LISTNAME>+subscribe-digest. At least there have to be an alias for every address extension delimited by a “+” sign, although if it will be disabled by mlmmj later on.

The delimiter for address extensions (eQmail uses the term user extensions) is configurable through the eQmail sources. Edit the file  conf-break  and change the delimiter to “+”. Afterwards recompile and reinstall eQmail. This way should be used by more experienced users.

The virtual users of the MTA's have to be the owner of the list with read/write access. As they are mapped to the id's of vmu:vmg:

cd /home/mails/lists
chown -R vmu:vmg user-support

It is recommended to create a scheduled maintenance job by the mlmmj docs for each list by default. This can be done with one job for all lists if they are inside a folder directly. As we use a  Listdir  we have to create a new folder and a symlink:

$ cd /home/mails/lists
$ mkdir maintenance
$ cd maintenance
$ ln -s ../user-support user-support

Create a link for each mailinglist. Thus a cronjob will be like

0 */2 * * * /usr/bin/mlmmj-maintd -F -d /home/mails/lists/maintenance

This is just a recommendation. There are other solutions possible to do the maintenance job also. For one list simply do

0 */2 * * * /usr/bin/mlmmj-maintd -F -L /home/mails/lists/user-support/Listdir

Last but not least there are some options, so called tunables, for better list control. Some of them are highly recommended, others more or less important. Some examples:

ls -1 /home/mails/lists/user-support/Listdir/control
delimiter
footer
listaddress
nonomailsub
owner
subonlypost

Many of them are boolean, means a functionality will be turned on if a file exists (e.g.  subonlypost  ). In practise it is perhaps a good idea to put the description inside, so we don't have to refer back to the documentation in any case. Also, creating a folder inside  control  and moving boolean files into it or back makes it easy to switch a functionality on or off quite quickly.

After the wished configuration is done it is time to test it. Assuming the address extension delimiter is “+”, do:

1. subscribe to the list by sending a mail to support+subsribe@lists.dyndn.es
2. confirm the subscribe request
3. send a mail to support+help@lists.dyndn.es and support+faq@lists.dyndn.es (read the content of the mails from mlmmj)
4. send a normal mail to the list support@lists.dyndn.es
5. check out support+get-1@lists.dyndn.es
6. subscribe to digest and nomail
7. unsubscribe from the list (test digest and nomail unsubscribes as well)

Troubleshooting hints:

• to set mlmmj back into its initial state after tests, simply delete all content in  Listdir/archive  and set the  index  to 0
• the extension <LISTNAME>+get-N will not work properly if the mail N doesn't exits (no error mail)
• there is a <LISTNAME>+list extension mentioned, but does nothing at all (AFAIK)
• there can be multiple subscribes with the same email address, which affects unsubscribes too (this bug is solved since mlmmj-1.2.18.1)

There is another thing to mention that could be happen: if there is an exim MTA somewhere on the way - e.g. a ISP relay MTA or the recipients (subscribers) MTA - maybe some mails with address extensions will bounce. This affects e.g. subscribe confirmation mails, where the sender address is like

         <LISTNAME>+bounces-confsub-123456790ABCDEF-user=example.com@lists.dyndn.es 

Perhaps the reason is that these exim MTA's have to be configured for mlmmj through  mlmmj_router  and/or  mlmmj_transport  (see mlmmj documentation).