David Abrahams wrote:

I'm trying to follow the directions for integrating Mailman with Sendmail, but I think they may be incomplete. It looks like there were orginally some instructions directed at installations like mine (a few users, a few mailing lists, *one* computer), and they were entirely replaced by instructions for installations where an entire host could be dedicated to serving mailman lists. There are oblique references to how much easier the mm-handler method is than the alternative "maintaining lists of aliases" but no details about what that alternative involves.

It involves maintaining a set of aliases in /etc/aliases for each list such as

## mailman mailing list mailman: "|/usr/local/mailman/mail/mailman post mailman" mailman-admin: "|/usr/local/mailman/mail/mailman admin mailman" mailman-bounces: "|/usr/local/mailman/mail/mailman bounces mailman" mailman-confirm: "|/usr/local/mailman/mail/mailman confirm mailman" mailman-join: "|/usr/local/mailman/mail/mailman join mailman" mailman-leave: "|/usr/local/mailman/mail/mailman leave mailman" mailman-owner: "|/usr/local/mailman/mail/mailman owner mailman" mailman-request: "|/usr/local/mailman/mail/mailman request mailman" mailman-subscribe: "|/usr/local/mailman/mail/mailman subscribe mailman" mailman-unsubscribe:"|/usr/local/mailman/mail/mailman unsubscribe mailman"

This can be done automatically. See <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.049.htp> and the post to which it refers.

I don't mind going the mm-handler way if it's more scalable, so I pointed a separate domain, lists.boost-consulting.com, at my server. But now I have to learn about virtual hosting with sendmail and figure out how to integrate my .mc file with the supplied mailman.mc and have the respective settings that are different only apply to the intended hosts. I don't know too much about sendmail (or email protocols in general, really), so this is turning into a big and risky project. Is there anyone here who can help me get this stuff configured without bringing my email system to its knees for too long?

Look at the 'automated' method referred to in the FAQ. You may decide you don't need to go the mm-handler route.

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

David Abrahams <dave@boost-consulting.com> writes:

All that said, the follow-up post really gives me pause: http://mail.python.org/pipermail/mailman-users/2004-June/037543.html

Is that a legitimate worry?

Whoops, I now see that by "this perl script" he's referring to mm-handler.

Thanks.

-- Dave Abrahams Boost Consulting www.boost-consulting.com

Mark Sapiro <msapiro@value.net> writes:

David Abrahams wrote:

...

Mark, thank you! This looks a *lot* easier than what I was trying to do, and perhaps the post even implies that what I was trying to do won't work:

"many people cannot use David Champion's mm-handler due to shared use of domains"

(what exactly does he mean by "shared use of domains?")

He means a given domain which is the recipient domain for both list mail and at least some non-list mail. mm-handler works best if the lists have their own domain which doesn't receive non-list mail.

So I gathered. That's what I was doing by trying to designate lists.boost-consulting.com as the domain for mailman. I think I'd still like to maintain that separation in case I need to switch to mm-handler someday.

Then Sendmail is configured so all the mail to that domain goes to mm-handler for delivery to Mailman. If there are other, non-list addresses in the same domain, they have to be handled via their own aliases 'ahead of' mm-handler.

Oh, so every regular user in that domain needs to be dealt with via an alias somehow?

If there are a lot of these, the problem of handling the non-list addresses becomes larger than the problem of handling list mail via aliases without mm-handler.

Of course, there are other MTAs (e.g., Exim) that can be configured to determine whether an address should be routed to Mailman by examining the Mailman file system to determine if a particular name is a Mailman list,

Yeah, we tried exim but failed to make exim to do SMTP AUTH via the same saslauthd that was being used for Cyrus, and the exim list was of little help to us, so we had to give up on it.

but with Sendmail, the easier way is probably the method referenced in the FAQ.

Thanks. If I hack up a Python script for this purpose I will post it here.

-- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams <dave@boost-consulting.com> writes:

Mark Sapiro <msapiro@value.net> writes:

...

Look at the 'automated' method referred to in the FAQ. You may decide you don't need to go the mm-handler route.

Heh, first hurdle:

The instructions at http://mail.python.org/pipermail/mailman-users/2004-June/037518.html start with

Create /usr/local/sbin/mailman.aliases with these commands:

/bin/cp /home/mailman/data/aliases /etc/mailman.aliases /usr/bin/newaliases

but I have no /home/mailman/, nor any /usr/local/mailman/data/aliases (which is what I suppose is intended) on my system.

Perhaps /usr/local/mailman/data/aliases should contain

## mailman mailing list mailman: "|/usr/local/mailman/mail/mailman post mailman" mailman-admin: "|/usr/local/mailman/mail/mailman admin mailman" mailman-bounces: "|/usr/local/mailman/mail/mailman bounces mailman" mailman-confirm: "|/usr/local/mailman/mail/mailman confirm mailman" mailman-join: "|/usr/local/mailman/mail/mailman join mailman" mailman-leave: "|/usr/local/mailman/mail/mailman leave mailman" mailman-owner: "|/usr/local/mailman/mail/mailman owner mailman" mailman-request: "|/usr/local/mailman/mail/mailman request mailman" mailman-subscribe: "|/usr/local/mailman/mail/mailman subscribe mailman" mailman-unsubscribe:"|/usr/local/mailman/mail/mailman unsubscribe mailman"

?

Heh, and even if I do that, I don't end up with a /usr/local/sbin/mailman.aliases. It seems like something needs to tell newaliases about /etc/mailman.aliases, and the only thing I see in the instructions that could do it is a later step:

3. We have to tell sendmail about the new alias file.

in /etc/mail/sendmail.mc find this line: define(ALIAS_FILE', /etc/aliases')dnl and change it to: define(ALIAS_FILE', /etc/aliases,/etc/mailman.aliases')dnl Run a make (or otherwise refresh sendmail.cf and then restart sendmail

Now when we run newaliases, it will rebuild both alias files.

Am I missing something? I feel like I'm groping around in the dark here.

-- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams wrote:

Heh, and even if I do that, I don't end up with a /usr/local/sbin/mailman.aliases.

You have to create /usr/local/sbin/mailman.aliases with execute permission and containing

/bin/cp /usr/local/mailman/data/aliases /etc/mailman.aliases /usr/bin/newaliases

It seems like something needs to tell newaliases about /etc/mailman.aliases, and the only thing I see in the instructions that could do it is a later step:

It is the

POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/local/sbin/mailman.aliases'

That tells the process to run that file in order to update system aliases from the /usr/local/mailman/data/aliases that the process creates/updates.

3. We have to tell sendmail about the new alias file.

in /etc/mail/sendmail.mc find this line: define(ALIAS_FILE', /etc/aliases')dnl and change it to: define(ALIAS_FILE', /etc/aliases,/etc/mailman.aliases')dnl Run a make (or otherwise refresh sendmail.cf and then restart sendmail

Now when we run newaliases, it will rebuild both alias files.

Am I missing something? I feel like I'm groping around in the dark here.

Here's what happens:

1. You create /usr/local/sbin/mailman.aliases with execute permission and containing

/bin/cp /usr/local/mailman/data/aliases /etc/mailman.aliases /usr/bin/newaliases

This will actually be run later.

2. You put in mm_cfg.py

MTA='Postfix' POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/local/sbin/mailman.aliases'

What this does is it tells Mailman's bin/genaliases and list creation/deletion processes to run Mailman/MTA/Postfix.py as part of the process to deal with aliases. This in turn updates data/aliases (a fixed file name) and then invokes POSTFIX_ALIAS_CMD to update the system aliases. That command runs the script in /usr/local/sbin/mailman.aliases (as root) to copy the aliases to /etc/mailman.aliases (This is necessary because of point 1. in the post at <http://mail.python.org/pipermail/mailman-users/2004-June/037518.html>) and run /usr/bin/newaliases to update Sendmail's database.

Now Mailman aliases are being automatically maintained in /etc/mailman.aliases, but none of this actually happens until step 5. of the above post's instructions.

3. You add /etc/mailman.aliases to Sendmail's configuration so Sendmail will use that file.

You do the other steps as outlined in the post.

Does this help?

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro <msapiro@value.net> writes:

David Abrahams wrote:

...

Heh, and even if I do that, I don't end up with a /usr/local/sbin/mailman.aliases.

You have to create /usr/local/sbin/mailman.aliases with execute permission and containing

/bin/cp /usr/local/mailman/data/aliases /etc/mailman.aliases /usr/bin/newaliases

Oh! The substitution of that word "containing" for the post's "with" made all the difference. :)

I read "create this file with these commands" as, "use these commands to create /usr/local/sbin/mailman.aliases"

It is the

POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/local/sbin/mailman.aliases'

That tells the process to run that file in order to update system aliases from the /usr/local/mailman/data/aliases that the process creates/updates.

Sure.

2. You put in mm_cfg.py

MTA='Postfix' POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/local/sbin/mailman.aliases'

What this does is it tells Mailman's bin/genaliases and list creation/deletion processes to run Mailman/MTA/Postfix.py as part of the process to deal with aliases. This in turn updates data/aliases (a fixed file name) and then invokes POSTFIX_ALIAS_CMD to update the system aliases. That command runs the script in /usr/local/sbin/mailman.aliases (as root) to copy the aliases to /etc/mailman.aliases (This is necessary because of point 1. in the post at <http://mail.python.org/pipermail/mailman-users/2004-June/037518.html>) and run /usr/bin/newaliases to update Sendmail's database.

Now Mailman aliases are being automatically maintained in /etc/mailman.aliases, but none of this actually happens until step 5. of the above post's instructions.

Uh-huh. But now I have all the products mentioned in step 5 except for mailman.aliases.db. I guess 2 out of 3 ain't bad, but... any clues?

Does this help?

Pretty good, thanks, but still a mystery lurks. Where's mailman.aliases.db?

-- Dave Abrahams Boost Consulting www.boost-consulting.com

Mark Sapiro <msapiro@value.net> writes:

David Abrahams wrote:

...

Uh-huh. But now I have all the products mentioned in step 5 except for mailman.aliases.db. I guess 2 out of 3 ain't bad, but... any clues?

If /etc/mailman.aliases is properly referenced in the sendmail configuration, the /usr/bin/newaliases command in the /usr/bin/newaliases script should create/update the /etc/mailman.aliases.db file.

Did you remember "Run a make (or otherwise refresh sendmail.cf and then restart sendmail" from step 3?

Yep. I was editing "boost.mc" so in /etc/mail I did

make boost.cf cp boost.cf sendmail.cf make restart

Another problem I'm been having is the inability to get past the end of

http://www.gnu.org/software/mailman/mailman-install/node40.html

i.e.

 review the site list's configuration via the admin pages.
 You should also subscribe yourself to the site list. 

<20 minutes of flailing later>...oooh, http://my-domain/mailman/admin works

I guess it would be good if the instructions would tell me how to find that :)

-- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams <dave@boost-consulting.com> writes:

Yep. I was editing "boost.mc" so in /etc/mail I did

make boost.cf cp boost.cf sendmail.cf make restart

Problem solved: I was pointing sendmail at the wrong path for the mailman.aliases file.

[/etc/aliases was just a symlink to /etc/mail/aliases, so I was pointing sendmail at /etc/mail/mailman.aliases, but of course that was wrong. I needed to be specifying /etc/mailman.aliases.]

Anyway, thanks very much; it all seems to be working now.

Say, if I really want to distinguish lists.mydomain.com from mydomain.com, is there any reason I can't still set up a virtual mail host and tack an automated updating of the virtusers file as shown in http://www.ddj.com/dept/architect/184413752?pgno=4 onto /usr/local/sbin/mailman.aliases ?

Thanks again,

-- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams wrote:

Pardon me, but isn't the GID with which to execute cgi scripts? Or are you saying that mailman's CGI scripts need to execute with the same GID as sendmail? If so, why?

Mailman's CGI scripts must run as group 'mailman' (or whatever is specified as the mailman group). Therefore, the wrappers are in the mailman group and SETGID.

For security reasons (to prevent anyone from running a wrapper), the wrappers check to be sure the original group of the caller was the expected group. It's this expected GID that is set via the --with-cgi-gid option to configure, but as you note, you are installing a packaged Mailman (a FreeBSD port) so this really doesn't apply, at least if the packager set it up right.

See <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.016.htp>

-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan