Next: How to set up a simple list with SQL support, Previous: Why not to use an SQL database with ezmlm, Up: ezmlm support for SQL databases
The basic philosophy is that the database can be on any host (if you use SENDER restrictions, connectivity to the main host is more important than to the sublists), and you choose the database and ‘table root’ names. The default database is ‘ezmlm’ and the default table root is ‘list’. Each list has a separate table root. Any number of lists can share a database.
The main list address table is named with the table root only, others have that name with various suffixes. In the following ‘list’ is used as the table root.
For each of the above tables, there is a ‘*_slog’ table that contains one row per transaction against the corresponding address table. The entries contain a time stamp, the subscription address; a direction indicator (- for removals, ‘+’ for additions); a type indicator (blank for ezmlm-manage, ‘m’ for “manual”, ‘p’ for “probe”, i.e. bounce handling; and the subscriber ‘From:’ line contents (only additions and only when made by ezmlm-manage or by ezmlm-sub(1) -n).
For both the list and the digest list, there are a pair of tables that log messages:
The digest list is created similarly, except that it is
ezmlm-get(1) that originates the message and
creates the cookie. This is done in ‘list_digest_cookie’.
The codes 2 for “receipt received” and -1 for “bounce” are entered by ezmlm-receipt(1) at the main list. This program is configured instead of ezmlm-return(1) if the main list was set up with ezmlm-make -w6. ezmlm-receipt(1) checks the cookie of messages addresses to ‘mainlocal-return-receipt@mainhost’ and if correct enters the ‘receipt received’ code. This address is normally in the subscriber database with a hash of 98, so that each list sends a message to the address after all subscriber addresses.
Bounces of sublist messages should not lead to removal of the sublist from the database. ezmlm-receipt(1) will instead log the bounce to the ‘list_mlog’ table. It will also store up to 50 bounces in the bounce directory. This helps error detection and diagnosis. After the first 50 bounces, no more bounces are stored, until you manually remove the old ones. This is to prevent filling up your hard disk in case a configuration error causes a deluge of bounces.
The digest list is treated in the same manner. Here, the tables is ‘list_digest_mlog’ and the feedback address is ‘mainlocal-digest-return-receipt@mainhost’.