view release on metacpan or  search on metacpan

t/data/spin/text/input/mjqmail  view on Meta::CPAN

domain system, described in section 2.3, but this requires that you have
the ability to set up a DNS MX record for a separate host name that will
only be handling mailing list mail.  A more complicated solution that
doesn't require that is to use the qmail-users mechanism as described in
section 2.4.

Under either approach, you'll need to set up .qmail files to handle the
incoming mail, which will now be delivered according to .qmail files in
the Majordomo user's home directory and with the UID and GID of the
delivery program already set to the appropriate user and group.  The
simplest way to handle this is to create .qmail files in the Majordomo
user's home directory similar to those described in section 2.1, except
leaving off the wrapper.  For example, if Majordomo were installed in
/var/qmail/majordomo, .qmail-LIST would just contain:

    |/var/qmail/majordomo/resend -l LIST LIST-outgoing

Also create a .qmail file containing:

    |/var/qmail/majordomo/majordomo

and a .qmail-owner file containing the e-mail address of the Majordomo
administrator.

There are two ways to deal with the fact that the standard Majordomo
sender address for list mail is owner-LIST instead of the more natural (at
least for qmail) LIST-owner.  One is to create then create
.qmail-owner-LIST files for each list (and add a line to users/append as
mentioned in the previous section if you're using qmail-users).  Another,
more natural approach is to change Majordomo to use LIST-owner.  To do
that, go through the .config files for each of your mailing lists and
change the "sender" setting to LIST-owner instead of the default.  You'll
also want to install a small to majordomo to make that the default for new
lists and for times when the configuration file couldn't be read.  You can
get that patch from:

    <https://www.eyrie.org/~eagle/software/mjqmail/>

The last issue to be aware of in eliminating the wrapper is that the
wrapper sets a variety of environment variables which will now no longer
be set.  The only one that actually causes problems is MAJORDOMO_CF.
Since it won't be set, all of the Majordomo programs will fall back on
/etc/majordomo.cf, which probably isn't correct.  If it's not, edit all
Majordomo programs you're running from aliases (resend, majordomo,
request-answer, etc.), search for MAJORDOMO_CF, and change the fallback
path to the correct path for majordomo.cf.

------------------------------

Subject: 2.3. Using virtual domains

A virtual domain allows you to delegate an entire domain to a particular
user.  Using virtual domains requires that you have sufficient control
over your DNS to set up a particular hostname just for your mailing lists.
You'll need to be able to pick an address, like lists.example.com, and set
up an MX record for it pointing to your mail server.  If you're not able
to do this, use the qmail-users mechanism described in the next section.

Choose the subdomain that you're going to give to Majordomo (such as
lists.example.com).  Add a line to /var/qmail/control/virtualdomains that
looks like:

    lists.example.com:lists

replacing lists.example.com with your virtual domain and lists with your
Majordomo user.  All addresses in that domain will now be handled by
.qmail files in the Majordomo user's home directory (well, after qmail is
restarted or qmail-send gets a HUP signal).  See the qmail-send man page
for more details.

It's possible to use the virtual domain system under qmail 1.03 or later
to delegate individual addresses rather than whole domains to a particular
user.  This would potentially allow one to use virtual domains even
without a separate hostname and MX record for mailing lists.  That would
require listing every individual list address in the virtualdomains file,
though, so using the qmail-users mechanism is probably simpler for that
case.

------------------------------

Subject: 2.4. Using qmail-users

The qmail-users man page, along with the documentation for qmail-pw2u and
qmail-newu, contains the full details on how the qmail-users mechanism
works, but basically qmail-pw2u is run on the password file to generate a
list of addresses mail is accepted at, what UID and GID to switch to when
delivering mail for a user, and where to deliver the mail (the user's home
directory).

Assuming that Majordomo is installed in /var/qmail/majordomo, create
/var/qmail/users/mailnames if it doesn't exist and add the following:

    lists:lists:majordomo

(replacing lists with the name of your Majordomo user).  This will be used
for the standard majordomo and majordomo-owner addresses.  Then, for each
list, add a line to /var/qmail/users/subusers of the form:

    LIST:lists:LIST:

(again, replacing lists with the name of your Majordomo user and replacing
LIST by the name of the list).  After this is done and you run qmail-pw2u,
all incoming mail to LIST and LIST-anything will be controlled by .qmail
files in Majordomo's home directory.

(Note that you may not want the home directory of the Majordomo user to be
the same as the Majordomo installation directory, for various reasons.
One reason to make them different is that qmail-pw2u likes to have the
home directory of a user be owned by that user and you may not want to
have the directory containing the main Majordomo scripts owned by the
Majordomo user for security reasons.)

If you're not going to patch Majordomo to use LIST-owner addresses instead
of owner-LIST addresses, you may also want to add the line:

    +owner-:lists:401:201:/var/qmail/majordomo:-:owner-:

to /var/qmail/users/append, replacing the user, UID, GID, and home
directory as appropriate for your installation, so that all mail addressed
to owner-anything will be handled by the Majordomo user.