-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathmailman-install.txt
1652 lines (1294 loc) · 71.3 KB
/
mailman-install.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
#GNU mailman - installation Manual About this document... About this
document...
Previous Page Up one Level Next Page GNU Mailman - Installation Manual
__________________________________________________________________
GNU Mailman - Installation Manual
Barry Warsaw
barry (at) list dot org
Release 2.1
January 11, 2020
Front Matter
Abstract:
This document describes how to install GNU Mailman on a POSIX-based
system such as Unix, MacOSX, or GNU/Linux. It will cover basic
installation instructions, as well as guidelines for integrating
Mailman with your web and mail servers.
The GNU Mailman website is at http://www.list.org
1 Installation Requirements
Please note that the information on this page may be out of date. Check
for the latest installation information on the Mailman wiki.
GNU Mailman works on most POSIX-based systems such as Unix, MacOSX, or
GNU/Linux. It does not currently work on Windows. You must have a mail
server that you can send messages to, and a web server that supports
the CGI/1.1 API. Apache makes a fine choice for web server, and mail
servers such as Postfix, Exim, Sendmail, and qmail should work just
fine.
To install Mailman from source, you will need an ANSI C compiler to
build Mailman's security wrappers. The GNU C compiler gcc works well.
You must have the Python interpreter installed somewhere on your
system. As of this writing, Python 2.4.4 is recommended, but see the
wiki page above for the latest information.
2 Set up your system
Before installing Mailman, you need to prepare your system by adding
certain users and groups. You will need to have root privileges to
perform the steps in this section.
2.1 Add the group and user
Mailman requires a unique user and group name which will own its files,
and under which its processes will run. Mailman's basic security is
based on group ownership permissions, so it's important to get this
step right^1. Typically, you will add a new user and a new group, both
called mailman. The mailman user must be a member of the mailman group.
Mailman will be installed under the mailman user and group, with the
set-group-id (setgid) bit enabled.
If these names are already in use, you can choose different user and
group names, as long as you remember these when you run configure. If
you choose a different unique user name, you will have to specify this
with configure's --with-username option, and if you choose a different
group name, you will have to specify this with configure's
--with-groupname option.
On Linux systems, you can use the following commands to create these
accounts. Check your system's manual pages for details:
% groupadd mailman
% useradd -c"GNU Mailman" -s /no/shell -d /no/home -g mailman mailman
2.2 Create the installation directory
Typically, Mailman is installed into a single directory, which includes
both the Mailman source code and the run-time list and archive data. It
is possible to split the static program files from the variable data
files and install them in separate directories. This section will
describe the available options.
The default is to install all of Mailman to /usr/local/mailman^2. You
can change this base installation directory (referred to here as
$prefix) by specifying the directory with the --prefix configure
option. If you're upgrading from a previous version of Mailman, you may
want to use the --prefix option unless you move your mailing lists.
Warning: You cannot install Mailman on a filesystem that is mounted
with the nosuid option. This will break Mailman, which relies on setgid
programs for its security. If this describes your environment, simply
install Mailman in a location that allows setgid programs.
Make sure the installation directory is set to group mailman (or
whatever you're going to specify with --with-groupname) and has the
setgid bit set^3. You probably also want to guarantee that this
directory is readable and executable by everyone. For example, these
shell commands will accomplish this:
% cd $prefix
% chgrp mailman .
% chmod a+rx,g+ws .
Warning: The installation directory, $prefix, cannot be the same
directory that the source tarball has been unpacked to and in which you
run configure, but it can, if you wish, be a subdirectory, e.g.,
$prefix/src.
You are now ready to configure and install the Mailman software.
3 Build and install Mailman
3.1 Run configure
Before you can install Mailman, you must run configure to set various
installation options your system might need.
Note: Take special note of the --with-mail-gid and --with-cgi-gid
options below. You will probably need to use these.
You should not be root while performing the steps in this section. Do
them under your own login, or whatever account you typically use to
install software. You do not need to do these steps as user mailman,
but you could. However, make sure that the login used is a member of
the mailman group as that that group has write permissions to the
$prefix directory made in the previous step. You must also have
permission to create a setgid file in the file system where it resides
(NFS and other mounts can be configured to inhibit setgid settings).
If you've installed other GNU software, you should be familiar with the
configure script. Usually you can just cd to the directory you unpacked
the Mailman source tarball into, and run configure with no arguments:
% cd mailman-<version>
% ./configure
% make install
The following options allow you to customize your Mailman installation.
--prefix=dir
Standard GNU configure option which changes the base directory
that Mailman is installed into. By default $prefix is
/usr/local/mailman. This directory must already exist, and be
set up as described in 2.2.
--exec-prefix=dir
Standard GNU configure option which lets you specify a different
installation directory for architecture dependent binaries.
--with-var-prefix=dir
Store mutable data under dir instead of under the $prefix or
$exec_prefix. Examples of such data include the list archives
and list settings database.
--with-python=/path/to/python
Specify an alternative Python interpreter to use for the wrapper
programs. The default is to use the interpreter found first on
your shell's $PATH.
--with-username=username-or-uid
Specify a different username than mailman. The value of this
option can be an integer user id or a user name. Be sure your
$prefix directory is owned by this user.
--with-groupname=groupname-or-gid
Specify a different groupname than mailman. The value of this
option can be an integer group id or a group name. Be sure your
$prefix directory is group-owned by this group.
--with-mail-gid=group-or-groups
Specify an alternative group for running scripts via the mail
wrapper. group-or-groups can be a list of one or more integer
group ids or symbolic group names. The first value in the list
that resolves to an existing group is used. By default, the
value is the list mailman, other, mail, and daemon.
Note: This is highly system dependent and you must get this
right, because the group id is compiled into the mail wrapper
program for added security. On systems using sendmail, the
sendmail.cf configuration file designates the group id of
sendmail processes using the DefaultUser option. (If commented
out, it still may be indicating the default...)
Check your mail server's documentation and configuration files
to find the right value for this switch.
--with-cgi-gid=group-or-groups
Specify an alternative group for running scripts via the CGI
wrapper. group-or-groups can be a list of one or more integer
group ids or symbolic group names. The first value in the list
that resolves to an existing group is used. By default, the
value is the the list www, www-data, and nobody.
Note: The proper value for this is dependent on your web server
configuration. You must get this right, because the group id is
compiled into the CGI wrapper program for added security, and no
Mailman CGI scripts will run if this is incorrect.
If you're using Apache, check the values for the Group option in
your httpd.conf file.
--with-cgi-ext=extension
Specify an extension for cgi-bin programs. The CGI wrappers
placed in $prefix/cgi-bin will have this extension (some web
servers require an extension). extension must include the
leading dot.
--with-mailhost=hostname
Specify the fully qualified host name part for outgoing email.
After the installation is complete, this value can be overriden
in $prefix/Mailman/mm_cfg.py.
--with-urlhost=hostname
Specify the fully qualified host name part of urls. After the
installation is complete, this value can be overriden in
$prefix/Mailman/mm_cfg.py.
--with-gcc=no
Don't use gcc, even if it is found. In this case, cc must be
found on your $PATH.
3.2 Make and install
Once you've run configure, you can simply run make, then make install
to build and install Mailman.
4 Check your installation
After you've run make install, you should check that your installation
has all the correct permissions and group ownerships by running the
check_perms script. First change to the installation (i.e. $prefix)
directory, then run the bin/check_perms program. Don't try to run
bin/check_perms from the source directory; it will only run from the
installation directory.
If this reports no problems, then it's very likely <wink> that your
installation is set up correctly. If it reports problems, then you can
either fix them manually, re-run the installation, or use
bin/check_perms to fix the problems (probably the easiest solution):
* You need to become the user that did the installation, and that
owns all the files in $prefix, or root.
* Run bin/check_perms -f
* Repeat previous step until no more errors are reported!
Warning: If you're running Mailman on a shared multiuser system, and
you have mailing lists with private archives, you may want to hide the
private archive directory from other users on your system. In that
case, you should drop the other execute permission (o-x) from the
archives/private directory. However, the web server process must be
able to follow the symbolic link in public directory, otherwise your
public Pipermail archives will not work. To set this up, become root
and run the following commands:
# cd <prefix>/archives
# chown <web-server-user> private
# chmod o-x private
You need to know what user your web server runs as. It may be www,
apache, httpd or nobody, depending on your server's configuration.
5 Set up your web server
Congratulations! You've installed the Mailman software. To get
everything running you need to hook Mailman up to both your web server
and your mail system.
If you plan on running your mail and web servers on different machines,
sharing Mailman installations via NFS, be sure that the clocks on those
two machines are synchronized closely. You might take a look at the
file Mailman/LockFile.py; the constant CLOCK_SLOP helps the locking
mechanism compensate for clock skew in this type of environment.
This section describes some of the things you need to do to connect
Mailman's web interface to your web server. The instructions here are
somewhat geared toward the Apache web server, so you should consult
your web server documentation for details.
You must configure your web server to enable CGI script permission in
the $prefix/cgi-bin to run CGI scripts. The line you should add might
look something like the following, with the real absolute directory
substituted for $prefix, of course:
Exec /mailman/* $prefix/cgi-bin/*
or:
ScriptAlias /mailman/ $prefix/cgi-bin/
Warning: You want to be very sure that the user id under which your CGI
scripts run is not in the mailman group you created above, otherwise
private archives will be accessible to anyone.
Copy the Mailman, Python, and GNU logos to a location accessible to
your web server. E.g. with Apache, you've usually got an icons
directory that you can drop the images into. For example:
% cp $prefix/icons/*.{jpg,png} /path/to/apache/icons
You then want to add a line to your $prefix/Mailman/mm_cfg.py file
which sets the base URL for the logos. For example:
IMAGE_LOGOS = '/images/'
The default value for IMAGE_LOGOS is /icons/. Read the comment in
Defaults.py.in for details.
Configure your web server to point to the Pipermail public mailing list
archives. For example, in Apache:
Alias /pipermail/ $varprefix/archives/public/
where $varprefix is usually $prefix unless you've used the
--with-var-prefix option to configure. Also be sure to configure your
web server to follow symbolic links in this directory, otherwise public
Pipermail archives won't be accessible. For Apache users, consult the
FollowSymLinks option.
If you're going to be supporting internationalized public archives, you
will probably want to turn off any default charset directive for the
Pipermail directory, otherwise your multilingual archive pages won't
show up correctly. Here's an example for Apache, based on the standard
installation directories:
<Directory "/usr/local/mailman/archives/public/">
AddDefaultCharset Off
</Directory>
Also, you may need to specifically allow access to Mailman's
directories. For example, in Apache, the above Directory block may need
something like
Require all granted
or
Order allow,deny
Allow from all
depending on the Apache version and similarly for the $prefix/cgi-bin/
directory.
Now restart your web server.
6 Set up your mail server
This section describes some of the things you need to do to connect
Mailman's email interface to your mail server. The instructions here
are different for each mail server; if your mail server is not
described in the following subsections, try to generalize from the
existing documentation, and consider contributing documentation updates
to the Mailman developers.
Under rare circumstances or due to mis-configuration, mail to the
owner(s) of the 'mailman' site-list (see section 8) can bounce. In
order to prevent a mail loop this mail is sent with envelope from
mailman-loop which is normally aliased as
mailman-loop: $varprefix/data/owner-bounces.mbox
but which can be aliased to any, always deliverable, local address or
file. If you are using the Postfix MTA integrated as described in
section 6.1, this alias will be generated automatically. In all other
cases, you should install this alias along with your normal system
aliases.
6.1 Using the Postfix mail server
Mailman should work pretty much out of the box with a standard Postfix
installation. It has been tested with various Postfix versions up to
and including Postfix 2.11.3 (as of April 2016).
In order to support Mailman's optional VERP delivery, you will want to
disable luser_relay (the default) and you will want to set
recipient_delimiter for extended address semantics. You should comment
out any luser_relay value in your main.cf and just go with the
defaults. Also, add this to your main.cf file:
recipient_delimiter = +
Using "+" as the delimiter works well with the default values for
VERP_FORMAT and VERP_REGEXP in Defaults.py.
When attempting to deliver a message to a non-existent local address,
Postfix may return a 450 error code. Since this is a transient error
code, Mailman will continue to attempt to deliver the message for
DELIVERY_RETRY_PERIOD - 5 days by default. You might want to set
Postfix up so that it returns permanent error codes for non-existent
local users by adding the following to your main.cf file:
unknown_local_recipient_reject_code = 550
Finally, if you are using Postfix-style virtual domains, read the
section on virtual domain support below.
6.1.1 Integrating Postfix and Mailman
You can integrate Postfix and Mailman such that when new lists are
created, or lists are removed, Postfix's alias database will be
automatically updated. The following are the steps you need to take to
make this work.
In the description below, we assume that you've installed Mailman in
the default location, i.e. /usr/local/mailman. If that's not the case,
adjust the instructions according to your use of configure's --prefix
and --with-var-prefix options.
Note: If you are using virtual domains and you want Mailman to honor
your virtual domains, read the 6.1 section below first! Then come back
here and do these steps.
* Add this to the bottom of the $prefix/Mailman/mm_cfg.py file:
MTA = 'Postfix'
The MTA variable names a module in the Mailman/MTA directory which
contains the mail server-specific functions to be executed when a
list is created or removed.
* Look at the Defaults.py file for the variables POSTFIX_ALIAS_CMD
and POSTFIX_MAP_CMD command. Make sure these point to your
postalias and postmap programs respectively. Remember that if you
need to make changes, do it in mm_cfg.py.
* Run the bin/genaliases script to initialize your aliases file.
% cd /usr/local/mailman
% bin/genaliases
Make sure that the owner of the data/aliases and data/aliases.db
file is mailman, that the group owner for those files is mailman,
or whatever user and group you used in the configure command, and
that both files are group writable:
% su
% chown mailman:mailman data/aliases*
% chmod g+w data/aliases*
* Hack your Postfix's main.cf file to include the following path in
your alias_maps variable:
/usr/local/mailman/data/aliases
Note that there should be no trailing .db. Do not include this in
your alias_database variable. This is because you do not want
Postfix's newaliases command to modify Mailman's aliases.db file,
but you do want Postfix to consult aliases.db when looking for
local addresses.
You probably want to use a hash: style database for this entry.
Here's an example:
alias_maps = hash:/etc/postfix/aliases,
hash:/usr/local/mailman/data/aliases
* When you configure Mailman, use the --with-mail-gid=mailman switch;
this will be the default if you configured Mailman after adding the
mailman owner. Because the owner of the aliases.db file is mailman,
Postfix will execute Mailman's wrapper program as uid and gid
mailman.
That's it! One caveat: when you add or remove a list, the aliases.db
file will updated, but it will not automatically run postfix reload.
This is because you need to be root to run this and suid-root scripts
are not secure. The only effect of this is that it will take about a
minute for Postfix to notice the change to the aliases.db file and
update its tables.
6.1.2 Virtual domains
Note: This section describes how to integrate Mailman with Postfix for
automatic generation of Postfix virtual_alias_maps for Mailman list
addresses. Mailman's support of virtual domains is limited in that list
names must be globally unique within a single Mailman instance, i.e.,
two lists may not have the same name even if they are in different
domains.
Postfix 2.0 supports ``virtual alias domains'', essentially what used
to be called ``Postfix-style virtual domains'' in earlier Postfix
versions. To make virtual alias domains work with Mailman, you need to
do some setup in both Postfix and Mailman. Mailman will write all
virtual alias mappings to a file called, by default,
/usr/local/mailman/data/virtual-mailman. It will also use postmap to
create the virtual-mailman.db file that Postfix will actually use.
First, you need to set up the Postfix virtual alias domains as
described in the Postfix documentation (see Postfix's virtual(5)
manpage). Note that it's your responsibility to include the
virtual-alias.domain anything line as described manpage (in recent
Postfix this is not required if the domain is included in
virtual_alias_domains in main.cf); Mailman will not include this line
in virtual-mailman. You are highly encouraged to make sure your virtual
alias domains are working properly before integrating with Mailman.
Next, add a path to Postfix's virtual_alias_maps variable, pointing to
the virtual-mailman file, e.g.:
virtual_alias_maps = <your normal virtual alias files>,
hash:/usr/local/mailman/data/virtual-mailman
assuming you've installed Mailman in the default location. If you're
using an older version of Postfix which doesn't have the
virtual_alias_maps variable, use the virtual_maps variable instead.
The default mappings in virtual-mailman map list addresses in virtual
domains to unqualified local names as in:
[email protected] mylist
[email protected] mylist-request
# and so on...
In some Postfix configurations it may be necessary to qualify those
local names as for example:
[email protected] mylist@localhost
[email protected] mylist-request@localhost
# and so on...
If this is the case, you can include
VIRTUAL_MAILMAN_LOCAL_DOMAIN = 'localhost'
or whatever qualification is needed in mm_cfg.py.
Next, in your mm_cfg.py file, you will want to set the variable
POSTFIX_STYLE_VIRTUAL_DOMAINS to the list of virtual domains that
Mailman should update. This may not be all of the virtual alias domains
that your Postfix installation supports! The values in this list will
be matched against the host_name attribute of mailing lists objects,
and must be an exact match.
Here's an example. Note that this example describes an unusual
configuration. A more usual configuration is described next. Say that
Postfix is configured to handle the virtual domains dom1.ain, dom2.ain,
and dom3.ain, and further that in your main.cf file you've got the
following settings:
myhostname = mail.dom1.ain
mydomain = dom1.ain
mydestination = $myhostname, localhost.$mydomain
virtual_alias_maps =
hash:/some/path/to/virtual-dom1,
hash:/some/path/to/virtual-dom2,
hash:/some/path/to/virtual-dom2
If in your virtual-dom1 file, you've got the following lines:
dom1.ain IGNORE
@dom1.ain @mail.dom1.ain
this tells Postfix to deliver anything addressed to dom1.ain to the
same mailbox at mail.dom1.com, its default destination.
In this case you would not include dom1.ain in
POSTFIX_STYLE_VIRTUAL_DOMAINS because otherwise Mailman will write
entries for mailing lists in the dom1.ain domain as
[email protected] mylist
[email protected] mylist-request
# and so on...
The more specific entries trump your more general entries, thus
breaking the delivery of any dom1.ain mailing list.
However, you would include dom2.ain and dom3.ain in mm_cfg.py:
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['dom2.ain', 'dom3.ain']
Now, any list that Mailman creates in either of those two domains, will
have the correct entries written to
/usr/local/mailman/data/virtual-mailman.
In a more usual configuration, dom1.ain would not be a virtual domain
at all as in the following:
myhostname = mail.dom1.ain
mydomain = dom1.ain
mydestination = $myhostname, $mydomain localhost.$mydomain
virtual_alias_maps =
hash:/some/path/to/virtual-dom2,
hash:/some/path/to/virtual-dom2
In this case too, you would include dom2.ain and dom3.ain in mm_cfg.py:
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['dom2.ain', 'dom3.ain']
As in the previous section with the data/aliases* files, you want to
make sure that both data/virtual-mailman and data/virtual-mailman.db
are user and group owned by mailman.
6.1.3 An alternative approach
Fil [email protected] has an alternative approach based on virtual maps and
regular expressions, as described at:
* (French) http://listes.rezo.net/comment.php
* (English) http://listes.rezo.net/how.php
This is a good (and simpler) alternative if you don't mind exposing an
additional hostname in the domain part of the addresses people will use
to contact your list. I.e. if people should use [email protected]
instead of [email protected].
6.2 Using the Exim mail server
Note: This section is derived from Nigel Metheringham's ``HOWTO - Using
Exim and Mailman together'', which covers Mailman 2.0.x and Exim 3. It
has been updated to cover Mailman 2.1 and Exim 4. The updated document
is here: http://www.exim.org/howto/mailman21.html and is recommended
over the information in the subsections below if you are using Exim 4.
There is no Mailman configuration needed other than the standard
options detailed in the Mailman install documentation. The Exim
configuration is transparent to Mailman. The user and group settings
for Mailman must match those in the config fragments given below.
6.2.1 Exim configuration
The Exim configuration is built so that a list created within Mailman
automatically appears to Exim without the need for defining any
additional aliases.
The drawback of this configuration is that it will work poorly on
systems supporting lists in several different mail domains. While
Mailman handles virtual domains, it does not yet support having two
distinct lists with the same name in different virtual domains, using
the same Mailman installation. This will eventually change. (But see
below for a variation on this scheme that should accommodate virtual
domains better.)
The configuration file excerpts below are for use in an already
functional Exim configuration, which accepts mail for the domain in
which the list resides. If this domain is separate from the others
handled by your Exim configuration, then you'll need to:
* add the list domain, ``my.list.domain'' to local_domains
* add a ``domains=my.list.domain'' option to the director (router)
for the list
* (optional) exclude that domain from your other directors (routers)
Note: The instructions in this document should work with either Exim 3
or Exim 4. In Exim 3, you must have a local_domains configuration
setting; in Exim 4, you most likely have a local_domains domainlist. If
you don't, you probably know what you're doing and can adjust
accordingly. Similarly, in Exim 4 the concept of ``directors'' has
disappeared - there are only routers now. So if you're using Exim 4,
whenever this document says ``director'', read ``router''.
Whether you are using Exim 3 or Exim 4, you will need to add some
macros to the main section of your Exim config file. You will also need
to define one new transport. With Exim 3, you'll need to add a new
director; with Exim 4, a new router plays the same role.
Finally, the configuration supplied here should allow co-habiting
Mailman 2.0 and 2.1 installations, with the proviso that you'll
probably want to use mm21 in place of mailman - e.g., MM21_HOME,
mm21_transport, etc.
6.2.2 Main configuration settings
First, you need to add some macros to the top of your Exim config file.
These just make the director (router) and transport below a bit
cleaner. Obviously, you'll need to edit these based on how you
configured and installed Mailman.
# Home dir for your Mailman installation -- aka Mailman's prefix
# directory.
MAILMAN_HOME=/usr/local/mailman
MAILMAN_WRAP=MAILMAN_HOME/mail/mailman
# User and group for Mailman, should match your --with-mail-gid
# switch to Mailman's configure script.
MAILMAN_USER=mailman
MAILMAN_GROUP=mailman
6.2.3 Transport for Exim 3
Add this to the transports section of your Exim config file, i.e.
somewhere between the first and second ``end'' line:
mailman_transport:
driver = pipe
command = MAILMAN_WRAP \
'${if def:local_part_suffix \
{${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
{post}}' \
$local_part
current_directory = MAILMAN_HOME
home_directory = MAILMAN_HOME
user = MAILMAN_USER
group = MAILMAN_GROUP
6.2.4 Director for Exim 3
If you're using Exim 3, you'll need to add the following director to
your config file (directors go between the second and third ``end''
lines). Also, don't forget that order matters - e.g. you can make
Mailman lists take precedence over system aliases by putting this
director in front of your aliasfile director, or vice-versa.
# Handle all addresses related to a list 'foo': the posting address.
# Automatically detects list existence by looking
# for lists/$local_part/config.pck under MAILMAN_HOME.
mailman_director:
driver = smartuser
require_files = MAILMAN_HOME/lists/$local_part/config.pck
suffix_optional
suffix = -bounces : -bounces+* : \
-confirm+* : -join : -leave : \
-owner : -request : -admin
transport = mailman_transport
6.2.5 Router for Exim 4
In Exim 4, there's no such thing as directors - you need to add a new
router instead. Also, the canonical order of the configuration file was
changed so routers come before transports, so the router for Exim 4
comes first here. Put this router somewhere after the ``begin routers''
line of your config file, and remember that order matters.
mailman_router:
driver = accept
require_files = MAILMAN_HOME/lists/$local_part/config.pck
local_part_suffix_optional
local_part_suffix = -admin : -bounces : -bounces+* : \
-confirm : -confirm+* : \
-join : -leave : \
-owner : -request : \
-subscribe : -unsubscribe
transport = mailman_transport
6.2.6 Transports for Exim 4
The transport for Exim 4 is the same as for Exim 3 (see 6.2; just copy
the transport given above to somewhere under the ``begin transports''
line of your Exim config file.
6.2.7 Additional notes
Exim should be configured to allow reasonable volume - e.g. don't set
max_recipients down to a silly value - and with normal degrees of
security - specifically, be sure to allow relaying from 127.0.0.1, but
pretty much nothing else. Parallel deliveries and other tweaks can also
be used if you like; experiment with your setup to see what works.
Delay warning messages should be switched off or configured to only
happen for non-list mail, unless you like receiving tons of mail when
some random host is down.
6.2.8 Problems
* Mailman will send as many MAIL FROM/RCPT TO as it needs. It may
result in more than 10 or 100 messages sent in one connection,
which will exceed the default value of Exim's
smtp_accept_queue_per_connection value. This is bad because it will
cause Exim to switch into queue mode and severely delay delivery of
your list messages. The way to fix this is to set Mailman's
SMTP_MAX_SESSIONS_PER_CONNECTION (in $prefix/Mailman/mm_cfg.py) to
a smaller value than Exim's smtp_accept_queue_per_connection.
* Mailman should ignore Exim delay warning messages, even though Exim
should never send this to list messages. Mailman 2.1's general
bounce detection and VERP support should greatly improve the bounce
detector's hit rates.
* List existence is determined by the existence of a config.pck file
for a list. If you delete lists by foul means, be aware of this.
* If you are getting Exim or Mailman complaining about user ids when
you send mail to a list, check that the MAILMAN_USER and
MAILMAN_GROUP match those of Mailman itself (i.e. what were used in
the configure script). Also make sure you do not have aliases in
the main alias file for the list.
6.2.9 Receiver Verification
Exim's receiver verification feature is very useful - it lets Exim
reject unrouteable addresses at SMTP time. However, this is most useful
for externally-originating mail that is addressed to mail in one of
your local domains. For Mailman list traffic, mail originates on your
server, and is addressed to random external domains that are not under
your control. Furthermore, each message is addressed to many recipients
- up to 500 if you use Mailman's default configuration and don't tweak
SMTP_MAX_RCPTS.
Doing receiver verification on Mailman list traffic is a recipe for
trouble. In particular, Exim will attempt to route every recipient
addresses in outgoing Mailman list posts. Even though this requires
nothing more than a few DNS lookups for each address, it can still
introduce significant delays. Therefore, you should disable recipient
verification for Mailman traffic.
Under Exim 3, put this in your main configuration section:
receiver_verify_hosts = !127.0.0.1
Under Exim 4, this is probably already taken care of for you by the
default recipient verification ACL statement (in the RCPT TO ACL):
accept domains = +local_domains
endpass
message = unknown user
verify = recipient
which only does recipient verification on addresses in your domain.
(That's not exactly the same as doing recipient verification only on
messages coming from non-127.0.0.1 hosts, but it should do the trick
for Mailman.)
6.2.10 SMTP Callback
Exim's SMTP callback feature is an even more powerful way to detect
bogus sender addresses than normal sender verification. Unfortunately,
lots of servers send bounce messages with a bogus address in the
header, and there are plenty that send bounces with bogus envelope
senders (even though they're supposed to just use an empty envelope
sender for bounces).
In order to ensure that Mailman can disable/remove bouncing addresses,
you generally want to receive bounces for Mailman lists, even if those
bounces are themselves not bounceable. Thus, you might want to disable
SMTP callback on bounce messages.
With Exim 4, you can accomplish this using something like the following
in your RCPT TO ACL:
# Accept bounces to lists even if callbacks or other checks would fail
warn message = X-WhitelistedRCPT-nohdrfromcallback: Yes
condition = \
${if and {{match{$local_part}{(.*)-bounces\+.*}} \
{exists {MAILMAN_HOME/lists/$1/config.pck}}} \
{yes}{no}}
accept condition = \
${if and {{match{$local_part}{(.*)-bounces\+.*}} \
{exists {MAILMAN_HOME/lists/$1/config.pck}}} \
{yes}{no}}
# Now, check sender address with SMTP callback.
deny !verify = sender/callout=90s
If you also do SMTP callbacks on header addresses, you'll want
something like this in your DATA ACL:
deny !condition = $header_X-WhitelistedRCPT-nohdrfromcallback:
!verify = header_sender/callout=90s
6.2.11 Doing VERP with Exim and Mailman
VERP will send one email, with a separate envelope sender (return
path), for each of your subscribers - read the information in
$prefix/Mailman/Defaults.py for the options that start with VERP. In a
nutshell, all you need to do to enable VERP with Exim is to add these
lines to $prefix/Mailman/mm_cfg.py:
VERP_PASSWORD_REMINDERS = Yes
VERP_PERSONALIZED_DELIVERIES = Yes
VERP_DELIVERY_INTERVAL = Yes
VERP_CONFIRMATIONS = Yes
(The director (router) above is smart enough to deal with VERP
bounces.)
6.2.12 Virtual Domains
One approach to handling virtual domains is to use a separate Mailman
installation for each virtual domain. Currently, this is the only way
to have lists with the same name in different virtual domains handled
by the same machine.
In this case, the MAILMAN_HOME and MAILMAN_WRAP macros are useless -
you can remove them. Change your director (router) to something like
this:
require_files = /virtual/${domain}/mailman/lists/${lc:$local_part}/config.pck
and change your transport like this:
command = /virtual/${domain}/mailman/mail/mailman \
${if def:local_part_suffix \
{${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}}
{post}} \
$local_part
current_directory = /virtual/${domain}/mailman
home_directory = /virtual/${domain}/mailman
6.2.13 List Verification
This is how a set of address tests for the Exim lists look on a working
system. The list in question is [email protected], and
these commands were run on the mems-exchange.org mail server ("% "
indicates the Unix shell prompt):
% exim -bt quixote-users
router = mailman_main_router, transport = mailman_transport
% exim -bt quixote-users-request
router = mailman_router, transport = mailman_transport
% exim -bt quixote-users-bounces
router = mailman_router, transport = mailman_transport
% exim -bt quixote-users-bounces+luser=example.com
router = mailman_router, transport = mailman_transport
If your exim -bt output looks something like this, that's a start: at
least it means Exim will pass the right messages to the right Mailman
commands. It by no means guarantees that your Exim/Mailman installation
is functioning perfectly, though!
6.2.14 Document History
Originally written by Nigel Metheringham [email protected]. Updated
by Marc Merlin [email protected] for Mailman 2.1, Exim 4.
Overhauled/reformatted/clarified/simplified by Greg Ward
6.3 Using the Sendmail mail server
Warning: You may be tempted to set the DELIVERY_MODULE configuration
variable in mm_cfg.py to 'Sendmail' when using the Sendmail mail
server. Don't. The Sendmail.py module is misnamed - it's really a
command line based message handoff scheme as opposed to the SMTP scheme
used in SMTPDirect.py (the default). Sendmail.py has known security
holes and is provided as a proof-of-concept only^4. If you are having
problems using SMTPDirect.py fix those instead of using Sendmail.py, or
you may open your system up to security exploits.
6.3.1 Sendmail ``smrsh'' compatibility
Many newer versions of Sendmail come with a restricted execution
utility called ``smrsh'', which limits the executables that Sendmail
will allow to be used as mail programs. You need to explicitly allow
Mailman's wrapper program to be used with smrsh or Mailman will not
work. If mail is not getting delivered to Mailman's wrapper program and
you're getting an ``operating system error'' in your mail syslog, this
could be your problem.
One good way of enabling this is:
* Find out where your Sendmail executes its smrsh wrapper
% grep smrsh /etc/mail/sendmail.cf
* Figure out where smrsh expects symlinks for allowable mail
programs. At the very beginning of the following output you will
see a full path to some directory, e.g. /var/adm/sm.bin or similar:
% strings $path_to_smrsh | less
* cd into /var/adm/sm.bin, or where ever it happens to reside on your
system - alternatives include /etc/smrsh, /var/smrsh and
/usr/local/smrsh.
% cd /var/adm/sm.bin
* Create a symbolic link to Mailman's wrapper program:
% ln -s /usr/local/mailman/mail/mailman mailman
6.3.2 Integrating Sendmail and Mailman
David Champion has contributed a recipe for more closely integrating
Sendmail and Mailman, such that Sendmail will automatically recognize
and deliver to new mailing lists as they are created, without having to
manually edit alias tables.
In the contrib directory of Mailman's source distribution, you will
find four files:
* mm-handler.readme - an explanation of how to set everything up
* mm-handler - the mail delivery agent (MDA)
* mailman.mc - a toy configuration file sample
* virtusertable - a sample for RFC 2142 address exceptions
6.3.3 Performance notes
One of the surest performance killers for Sendmail users is when
Sendmail is configured to synchronously verify the recipient's host via
DNS. If it does this for messages posted to it from Mailman, you will
get horrible performance. Since Mailman usually connects via localhost
(i.e. 127.0.0.1) to the SMTP port of Sendmail, you should be sure to
configure Sendmail to not do DNS verification synchronously for
localhost connections.
6.4 Using the Qmail mail server
There are some issues that users of the qmail mail transport agent have
encountered. None of the core maintainers use qmail, so all of this
information has been contributed by the Mailman user community,
especially Martin Preishuber and Christian Tismer, with notes by Balazs
Nagy (BN) and Norbert Bollow (NB).
* You might need to set the mail-gid user to either qmail, mailman,
or nofiles by using the --with-mail-gid configure option.
BN: it highly depends on your mail storing policy. For example if
you use the simple ~alias/.qmail-* files, you can use `id -g
alias`. But if you use /var/qmail/users, the specified mail gid can
be used.
If you are going to be directing virtual domains directly to the
mailman user (using ``virtualdomains'' on a list-only domain, for
example), you will have to use --with-mail-gid=gid of mailman
user's group. This is incompatible with having list aliases in
~alias, unless that alias simply forwards to mailman-listname*.
* If there is a user mailman on your system, the alias mailman-owner
will work only in ~mailman. You have to do a touch .qmail-owner in
~mailman directory to create this alias.
NB: An alternative, IMHO better solution is to chown root ~mailman,
that will stop qmail from considering mailman to be a user to whom
mail can be delivered. (See ``man 8 qmail-getpw''.)
* In a related issue, if you have any users with the same name as one
of your mailing lists, you will have problems if list names contain