List:       majordomo-docs
Subject:    mailing lists 101
From:       Daniel Liston <dliston () sonny ! org>
Date:       2005-05-08 19:18:29
Message-ID: 427E6605.9050908 () sonny ! org
[Download RAW message or body]

This is mostly a reprint from my post in December 2002.

Did you read all of the "other" documentation?  Did you read the FAQ?
What version of sendmail are you running?

The one thing to wrap your brain around, is that majordomo does not
send your messages out or receive them from the internet.  Majordomo
only talks to sendmail (the MTA on your local machine).  This is done
through the sendmail aliases file in your /etc directory.  If sendmail
is not properly configured, it can prevent majordomo from working.

Let me make several assumptions before continuing. (Prerequisites)
1.  Sendmail can send and receive internet email on your machine.
2.  You are not virtually hosted. (your domain lives on your machine)
3.  You understand how /etc/aliases works for routing email.
4.  You are aware of sendmail security policies and how to work with them.

Lesson 1 (Sendmail aliases)
You can have a mailing list without majordomo.  This will not be a managed
list (at least not automatically), but a list just the same.  All you have
to do is create an alias (in /etc/aliases) with a name you want to use to
reference all the people that will get a copy of your message. For example,
test-users.  This list will have a membership of 5 local users.  Hence, the
line in the /etc/aliases file will look like this...

test-users: dan,joe,tom,dick,harry

Lesson 2 (Scaling up)
You can see where this would not scale well to 10s or 100s of list members.
It scales even worse if your members are not local to your machine.  The
MTA (mail transport agent), usually sendmail or compatible, allows for this
with :include: files.  These are files that contain one email address per
line (in this case).  We tend to create unique aliases when we use an these
:include: files.  Then we can redirect one alias to the other.

test-users: test-users-outgoing
test-users-outgoing: :include:/etc/mail/test-users

The test-users file holds 5 lines
dan
joe
tom
dick
harry

Lesson 3 (RFC 2142)
What if somebody that has their email address listed in your test-users
file decides they are tired of being the recipient of your endless testing?
Who do they write to?  The concept of -request and -approval appear.

test-users: test-users-outgoing
test-users-outgoing: :include:/etc/mail/test-users
test-users-request: test-users-approval
test-users-approval: you

Lesson 4 (Legacy - sendmail)
You have all these aliases laid out nice and logically.  Somebody writes to
the list and it redirects to the outgoing include file.  Somebody wants to
be added to or removed from your list, they write to the list-request email
address which gets redirected to the approval person for action.  Now to
complete the list aliases, if you do not take the action quickly enough, or
someone has a suggestion about the list, the -owner address.

test-users-owner: owner-test-users
owner-test-users: me

Lesson 5 (Oua La)
Noticing the constant redirection/rerouting of addresses?  Out of all the
aliases we created, we only want our list members to be aware of three of
them.  The test-users, test-users-request, and test-users-owner addresses.
Test-users-outgoing, test-users-approval, and owner-test-users are the
aliases that actually do the work.  In reality, there is nothing stopping
end users (or non-users) from sending messages directly to any of the six
aliases.

Summary (Done, but where's majordomo?)
We have a an open, public list, that can be written to by anyone at a
single address.  test-users@some.domain.  We have provided an address
for users and non-users to write to with requests, and a superior of
that address (the owner) for sending complaints or suggestions.  This
was all done with 6 lines in the /etc/aliases file, and 5 lines (at least
initially) in a file we created called test-users in a directory that
fits sendmail's vision of security.

/etc/aliases
test-users: test-users-outgoing
test-users-outgoing: :include:/etc/mail/test-users
test-users-request: test-users-approval
test-users-approval: you
test-users-owner: owner-test-users
owner-test-users: me

/etc/mail/test-users
dan
joe
tom
dick
harry

Lesson 6 (Introducing Majordomo)
Our list owners and moderators are tired of editing things by hand every
time somebody changes there mind about membership to our list.  We want
some security over who can write to or join out list, and we want it to
happen automagically.  Now we get to majordomo.  First we have to make a
path to majordomo files and directories that sendmail approves of.  There
can not be any group or world "writable" directories in the path to our
lists, and the lists themselves (our :include: files) can not be world or
group writable without making changes to the sendmail configuration.

For demonstration sake and to keep aliases short, let's assume majordomo
is installed in /mj1 and you have copied sample.cf to /etc/majordomo.cf.
You have a majordomo user and group created and it's home directory is
defined in the passwd file and the majordomo.cf file as /mj1.

You want to redirect mail from the majordomo mailbox to the majordomo
script (again by using aliases).  There are only minor changes required
to your aliases file to support this.

/etc/aliases
majordomo: "|/mj1/wrapper majordomo"
majordomo-owner: owner-majordomo
owner-majordomo: me
test-users: "|/mj1/wrapper resend -l test-users test-users-outgoing"
test-users-outgoing: :include:/mj1/lists/test-users
test-users-request: test-users-approval
test-users-approval: you
test-users-owner: owner-test-users
owner-test-users: me

We added three aliases and changed two.  The majordomo aliases introduce
the concept of delivery through a "pipe" to a program.  That program is
the majordomo wrapper.  This is used to redirect mail from the majordomo
mailbox to the majordomo program.

Our test-users alias still redirects to test-users-outgoing, but now we
can examine, control, and restrict which messages get into the list. The
resend utility is what actually reads and enforces your test-users.config
file.

The test-users file is moved from /etc/mail to /mj1/lists, and instead
of just short local names contains fully qualified email addresses.

/mj1/lists/test-users
dan@example.com
joe@example.com
tom@example.com
dick@example.com
harry@example.com

Lesson 7 (Sendmail Security)
To prevent sendmail from advertising your aliases, we need to modify the
aliases file just slightly, and to prevent outsiders from writing directly
to the alias with the :include: file, we need to enable another feature of
sendmail called virtusertable.  Redhat has this enabled by default, so all
we have to do is add a line to the right file.

/etc/mail/virtusertable
test-users-outgoing@example.com		error:nouser User unknown

NOTE: The white space in that line must contain at least one TAB character.

/etc/aliases
nobody: /dev/null
majordomo: "|/mj1/wrapper majordomo"
majordomo-owner: owner-majordomo
owner-majordomo: me,
test-users: "|/mj1/wrapper resend -l test-users test-users-outgoing,nobody"
test-users-outgoing: :include:/mj1/lists/test-users
test-users-request: test-users-approval
test-users-approval: you,
test-users-owner: owner-test-users
owner-test-users: me,

NOTE: We added commas to the right hand side expansion/redirection of the
owner aliases (you and me) and ,nobody to in the list alias.  The nobody
alias probably already existed, but I show it here for completeness. This
also allows for a little documented feature of sendmail that will deliver
messages to owner-<alias> in the event <alias> is undeliverable.

IMPORTANT:  Any time you change the aliases file, you must execute the
"newaliases" or "sendmail -bi" command from the shell prompt.
If you change sendmail.cf or any other flat text file that is only read
at sendmail startup, you must restart sendmail.
Lastly, sendmail expects the virtusertable to be in database form before it
can read it.  This is done manually in the /etc/mail directory with this
command; "makemap hash virtusertable < virtusertable".

Best regards,
Dan Liston