Mailman Installieren

Was noch jemand ergänzen müsste:

• Eine generische virtuser/alias Konfiguration finden und dokumentieren.
  

http://listes.rezo.net/how.php
http://www.gnu.org/software/mailman/mailman-install/mail-server.html

• Skriptautomatisierung updaten
  http://hs.andreasloesch.de/pac-mm-install

Mailman installieren

(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)

Vielen Dank an alle Benutzer die Verbesserungen beisteuern!

Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn Mailman vom Paketadmin installiert wird, haben ausnahmslos alle Paketuser direkten Zugriff auf die Mailman-Daten, und bei Sicherheitslücken in Mailman wäre eventuell eine Rechte-Eskalierung auf Paketadmin-Ebene potentiell zu befürchten.

Dem Paketuser, unter dem Mailman installiert wird, können mehrere Subdomains aufschaltet werden, und Mailinglisten können auch die Domainnamen verwenden, die anderen Paketusern gehören.

Vorteil der Installation als Paketuser ist, dass nur dieser direkten Zugriff auf die Mailmandaten hat und mailman ohne Paketadminrechte läuft. Während der Emailauslieferung gelten (wie immer bei der Mailweiterleitung durch .forward-Dateien oder durch procmail) die Rechte des Paketusers, dem die Mailman-Installation gehört.

Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.

Einen User und eine Domain anlegen

Unter admin.hostsharing.net als xyz00 anmelden; den User xyz00-listen erzeugen; die Domain listen.example.de mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.

Mit ssh an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.de/htdocs-ssl/.htaccess löschen:

~$ echo "" > ~/doms/lists.example.de/htdocs-ssl/.htaccess

Die Default-Subdomains www.* löschen:

  ~$ rm -r doms/listen.example.de/subs/www/
  ~$ rm -r doms/listen.example.de/subs-ssl/www/

Sourcen besorgen und entpacken

Unter http://www.gnu.org/software/mailman/ die aktuelle Software besorgen. Dort findet sich ein Link zu den Mailman 2 Versionen (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden ...

~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz

... und entpacken:

~$ tar -xzvf mailman-2.1.29.tgz

Ab diesem Augenblick gibt es ein Verzeichnis namens mailman-2.1.29/. Darin liegt die nunmehr entpackte Quellcode der Mailman-Software. Nach dem Kompilieren (folgt unten) wird die fertig kompilierte, gebrauchsfähige Mailman-Software in dem zusätzlich vorhandenen Verzeichnis mailman/ liegen. (Dieses Verzeichnis wird beim Konfigurieren der Source als "prefix" angegeben.)

var-Verzeichnis für Log-Dateien anlegen

Bei der Installation als Paketuser (xyz00-listen):

~$ cd && mkdir -p mailman/var
~$ chmod 02775 mailman/var

Bei der Installation als Paketadmin (xyz00):

~$ cd && mkdir var/mailman
~$ chmod 02775 var/mailman

Mailman konfigurieren

In das Source-Verzeichnis wechseln:

~$ cd mailman-2.1.29

Bei der Installation als Paketuser:

     ~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \
             --with-username=xyz00-listen \
             --with-groupname=xyz00 \
             --with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \
             --with-cgi-gid=xyz00 \
             --with-mail-gid=xyz00

Bei der Installation als Paketadmin:

     ~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \
             --with-username=xyz00 \
             --with-groupname=xyz00 \
             --with-var-prefix=/home/pacs/xyz00/var/mailman \
             --with-cgi-gid=xyz00 \
             --with-mail-gid=nogroup

(Die Rückwärtsschrägstriche "\" am Zeilenende bedeuten, dass der Befehl in der nächsten Zeile weitergeht. Alternativ können alle Argumente in eine Zeile getippt werden.)

Mailman kompilieren

~/mailman-2.1.29$ make
~/mailman-2.1.29$ make install

Datenrechte prüfen

Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:

~/mailman-2.1.29$ cd ..      
~$ mailman/bin/check_perms -f

Die neue Mailman-Installation konfigurieren

Konfigurationsdatei mm_cfg.py editieren

~$ nano mailman/Mailman/mm_cfg.py
     

Eine Beispielkonfiguration für lists.example.com könnte so aussehen:

[...]
     ##################################################
     # Put YOUR site-specific settings below this line.
     # -*- python -*-

     DEFAULT_HOST_NAME = 'listen.example.de'
     DEFAULT_EMAIL_HOST = 'listen.example.de'
     DEFAULT_URL_HOST = 'listen.example.de'
     add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
     add_virtualhost(zweite.listendomain.de, zweite.listendomain.de)

     DEFAULT_SERVER_LANGUAGE = 'de'

     DEFAULT_URL_PATTERN = 'http://%s/'
 
     # Es wird der HS Mailversand für Bulkmail verwendet:
     SMTPHOST = 'localhost'
     SMTPPORT = 4587 
     SMTP_AUTH = True
     SMTP_USER = 'xyz00-listen'
     SMTP_PASSWD = 'das-passwort-des-o.-g.-users'
     SMTP_USE_TLS = True

In ~/mailman/Mailman/Defaults.py sieht man, was in mm_cfg.py alles angepasst werden kann.

CGI-Programme in die Domain kopieren

Bei der Installation als Paketuser:

Die fertig kompilierten CGIs von Mailman müssen in das CGI-Verzeichnis der Domain (oder der Domains), auf der das Webfrontend von Mailman laufen soll, kopiert werden. Symbolische Links sind nicht ausreichend.

~$ mkdir ~/doms/listen.example.de/cgi-ssl/mailman
~$ cp mailman/cgi-bin/* doms/listen.example.de/cgi-ssl/mailman/

Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:

~$ chmod g-s ~/doms/listen.example.de/cgi/mailman/*

Bei der Installation als Paketadmin:

Die CGI-Programme können im Mailman-Verzeichnis bleiben. Im CGI-Verzeichnis von jeder Domain, auf der das Mailman-Webfrontend laufen soll, werden symbolische Links dazu erstellt:

~$ cd doms/listen.example.de/cgi-ssl
~/doms/listen.example.de/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman

Mailman-Icons in die Domains kopieren

Die Icons können wahlweise verlinkt oder kopiert werden:

~$ cd doms/listen.example.de/htdocs-ssl
~/doms/listen.example.de/htdocs-ssl$ ln -s ../../../mailman/icons

oder

~$ cp -R mailman/icons doms/lists.example.com/htdocs-ssl/

Die Datei .htaccess bearbeiten

Bei einer dedizierten Mailman-Domain sollte man dafür sorgen, dass Mailman nicht nur unter https://listen.example.de/cgi-bin/mailman, sondern auch unter https://listen.example.de erreichbar ist.

Dazu werden in ~/doms/listen.example.de/htdocs-ssl/.htaccess folgende Rewrite-Anweisungen eintragen.

RewriteEngine On
RewriteCond	%{REQUEST_URI}		!^/icons/
RewriteRule	^(.*)$			/cgi-bin/mailman/$1
RewriteRule	^/cgi-bin/mailman/$	/cgi-bin/mailman/listinfo

Beachte dabei die zweite Zeile: Anfragen für Icons sollen nicht umgeschrieben werden.

Wenn Mailman z.B. auf einer als Unterverzeichnis angelegten Subdomain läuft und unter https://www.example.com/mailman statt https://www.example.com/cgi-bin/mailman erreichbar sein soll, hilft folgendes in der ~/doms/example.com/subs-ssl/www/.htaccess:

RewriteEngine On
RewriteCond	%{REQUEST_URI}		!^/icons/
RewriteRule    ^mailman/(.*)$          /cgi-bin/mailman/$1
RewriteRule    ^/cgi-bin/mailman/$	/cgi-bin/mailman/listinfo

(In diesem Fall kann die Zeile DEFAULT_URL_PATTERN... in der mm_cfg.py auskommentiert werden.)

Hauptpasswort setzen

Das "site password" ist in Mailman eine Art Generalschlüssel: es wird neben dem jeweiligen Admin- oder Moderator-Passwort überall in der Weboberfläche für sämtliche Mailing-Listen akzeptiert. Also vorsichtig wählen! Das "site password" einrichten mit dem Befehl:

~$ mailman/bin/mmsitepass

Cronjobs einrichten

In die Crontab werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:

* * * * *	~/mailman/bin/qrunner -o -r All
47 * * * *	rm -f ~/var/mailman/logs/qrunner

(Queuebearbeitung alle Minute, löschen der Verarbeitungslogs in der 47ten Minute jeder Std.)

Dies übernimmt die Funktion des qrunner-Dämons, der bei Mailman normalerweise laufen würde. Das Logfile wird gelöscht, da es sonst sehr schnell sehr groß wird.

Zudem müssen noch die Cronjobs aus ~/mailman/cron/crontab.in eingefügt werden.

crontab -l > mycronjobs.tmp
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp
crontab mycronjobs.tmp

Mailinglisten einrichten

Als erste Liste die "mailman" "site list" einrichten

Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.

Neue Liste anlegen:

~$ mailman/bin/newlist mailman
Enter the email of the person running the list: admin@xyz00.hostsharing.net
Initial mailman password:

Nur für die "mailman site list": Konfigurationsvorgaben laden.

~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman

Bei der Installation als Paketadmin:

~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman

(Diese Konfigurationsdatei nicht auf eigene Listen anwenden.)

Email Adressen einrichten

Bei der Installation als Paketuser erfolgt die Einrichtung der Emailadressen per hsadmin (virtusertable) und .forward Dateien. Anlegen mittels hsadmin CLI: [1]

Beispiel für lists.example.com und Paketuser xyz00-listen.

A) virtusertable:

  hsscript -u xyz00 -i
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})
  emailaddress.add ({set:{domain:'lists.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})

Im Homeverzeichnis des Users xyz00-listen werden anschließend entsprechende .forward-Dateien angelegt. Die Dateinamen und Inhalte dieser Dateien definieren den Aufruf von Mailman und die Aktion, die das Programm ausführen soll. Zum Beispiel wird die .forward-Datei .forward+mailman verwendet, wenn die Adresse mailman@lists.example.com eine Mail erhält. In der .forward-Datei steht nun der Aufruf mit dem Programm, an das die Mail übergeben wird, die gewünschte Aktion und der Namen der Liste:

  /home/pacs/xyz00/users/listen/mailman/mail/mailman [Aktion] [Listenname]

So wird das definiert für alle Aktionen für die Liste mailman.

B) .forward Dateien:

echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe

Administration

Administriert werden Listen über http://lists.example.com/admin/<listenname> und entweder dem Listenpasswort oder dem Site-Passwort.

Als erstes sollte man die Liste "mailman" selbst abonnieren. (http://lists.example.com/admin/mailman)

Bis auf das Anwenden der sitelist.cfg werden auch alle weiteren Listen nach obigem Schema angelegt, oder (bis auf das anlegen der virtusertable Einträge und aliase) über das Mailman Webinterface.

Das war's. Mailman ist jetzt fertig installiert und müsste sogar funktionieren ;)

Feintuning

Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...

Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)

Es kann natürlich sein, dass ich zuviel lösche, aber bei mir funktioniert's. Wenn ihr also sicher(er) sein wollt, dass euch der Mailman nicht um die Ohren fliegt, macht das nicht!

• ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.
• Die nicht benötigten Sprachen in ~/mailman/messages löschen.
• Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).
• ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.
• Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:
• in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:

# In a normal interactive Python environment, the japanese.pth and korean.pth
# files would be imported automatically.  But because we inhibit the importing
# of the site module, we need to be explicit about importing these codecs.
if not jaok:
    import japanese
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
# codecs installed, however leave the first import in there in case an upgrade
# changes this.
if not kook:
    import korean
    import korean.aliases

auskommentieren.

Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.

Man kann auch noch die Debug-Informationen aus den binaries strippen:

strip ~/mailman/mail/mailman
strip ~/mailman/cgi-bin/*

Falls die CGIs nicht gesymlinkt wurden:

strip ~/doms/lists.example.com/cgi/mailman/*

Multidomainfähigkeit

Seit Mailman 2.x kann eine Mailman-Installation unter gewissen Einschränkungen für mehrere Domains verwendet werden. Hier soll kurz gezeigt werden, was geht und wie es geht.

Anleitung

Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.

Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:

~$ mailman/bin/newlist listenname@lists.example.com

Es ist ggf. wichtig, dass in der mm_cfg.py eine entsprechende add_virtualhost-Direktive für www.example.com steht, die der Frontend-URL einen Host-Part für die Mailadressen zuordnet. Ist eine solche Direktive nicht vorhanden, so wird lists.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für Emailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. lists.example.com gerade zutrifft.)

Liegt das Frondend nicht auf der Maildomain ist es wichtig, dass ihr Mailman sagt, für welches die zugehörige Maildomain ist. Dies tut ihr in der Datei ~/mailman/Mailman/mm_cfg.py:

Also z.B.

DEFAULT_URL_HOST = 'www.example.com'
DEFAULT_EMAIL_HOST = 'lists.example.com'
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)

und

add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')

Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind. Alle weiteren add_virtualhost-Direktiven ordnen einem Hostnamen für das Webfrontend (z.B. www.zoopnet.de) einen Hostpart für die Adresse der Mailinglisten (z.B. lists.zoopnet.de) zu.

Tip von Raimund Specht: Lässt man den zweiten Parameter weg, also schreibt z.B. add_virtualhost('www.example.org'), dann benutzt Mailman als Hostpart alles was nach dem ersten Punkt steht, hier also example.org als Maildomain.

Prinzipiell war's das. Man muss die Listeneinträge natürlich immer in die richtige virtusertable eintragen, und für gleichnamige Mailinglisten auf verschiedenen Domains (mailman@*) verschidene +Ergänzungen bzw. aliase verwenden. :)

Probleme

Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.

Tips und Tricks

URL Änderungen

Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt. Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:

~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url>

<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.

Weitere Cron-Jobs zur Mailinglisten Verwaltung

Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:

< In Arbeit >

Referenzen

Lösung zur installation als Domainadmin statt Paketadmin: https://lists.hostsharing.net/archiv/support/2009-June/019414.html
Ältere Anleitung für Installation als Domain-Admin: <http://lists.hostsharing.net/archiv/support/2005-January/012426.html>
"Kleine Tools" auf http://hs.andreasloesch.de, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist

---