Did you read any of the "other" documentation? Did you read the FAQ?
What version of sendmail are you running?
Number 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.
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.
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...
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.
The test-users file holds 5 lines
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.
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.
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
We have a an open, public list, that can be written to by anyone at a
single address. firstname.lastname@example.org. 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.
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.
demonstration sake and keeping aliases short, let's assume majordomo is
installed in /mj1945 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 /mj1945. You
also 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.
majordomo: "|/mj1945/wrapper majordomo"
test-users: "|/mj1945/wrapper resend -l test-users test-users-outgoing"
The test-users file is moved from /etc/mail to /mj1945/lists, and instead
of just short local names contains fully qualified email addresses.
Lesson 7 (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 the line to the right file.
email@example.com error:nouser User unknown
NOTE: The white space in that line must contain at least one TAB character.
majordomo: "|/mj1945/wrapper majordomo"
test-users: "|/mj1945/wrapper resend -l test-users test-users-outgoing,nobody"
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.
You should now have a working list.
PS. Any time you change the aliases file, you must execute the "newaliases"
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 in redhat by changing directories to /etc/mail
and executing "make all" or manually in the /etc/mail directory by
"makemap hash virtusertable < virtusertable"
Swapan Kumar Mitra wrote:
> I am using rehat linux 7.2, sendmail in a HP pavilion pc. I have installed
> majordomo 1.94.5 on the system successfully. Now I am unable to understand
> how to configure the NEWLIST, I went through the doc of NEWLIST. Can anybody
> explain through an example how I configure this.
> Looking for some immediate response.
From: "Swapan Kumar Mitra" <firstname.lastname@example.org>