16736
Kommentar: Postfix-Setup vereinfacht
|
17666
Typo
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 2: | Zeile 2: |
Diese Seite beschreibt die Installation und Einrichtung von [[https://sympa.org|Sympa]], Postfix und Nginx/Apache unter [[https://debian.or|Debian]] Stretch. | Diese Seite beschreibt die Installation und Einrichtung von [[https://sympa.org|Sympa]], Postfix und Nginx oder Apache unter [[https://debian.or|Debian]] Bullseye. |
Zeile 7: | Zeile 7: |
Ab 6.1.22 bringt Sympa [[https://www.sympa.org/manual/dmarc|DMARC]]-Funktionalität mit - diese Version ist erst in Buster enthalten. Gleich welche Version es ist:{{{ | * Sympa mit `apt` installieren:{{{ |
Zeile 9: | Zeile 9: |
Bei der Installation wird gleich die Datenbank mit eingerichtet. Dies kann auch [[https://www.sympa.org/manual/database|manuell]] durchgeführt werden. | * Bei der Installation wird gleich die Datenbank mit eingerichtet. Dies kann auch [[https://www.sympa.community/manual/install/setup-database.html|manuell]] durchgeführt werden. |
Zeile 13: | Zeile 13: |
* Alias maps: für jede Liste werden eigene Alias-Einträge konfiguiert * Transport maps: lediglich allgemeine Konfiguration der Listendomain Die alias-maps-Variante ist in der offiziellen [[https://sympa-community.github.io/manual/install/configure-mail-server-postfix.html|Sympa-Dokumentation]] beschrieben. Die Nutzung der transport map vereinfacht die Konfiguration also erheblich. Diese wird im Folgenden auch beschrieben. * Anpassen der {{{master.cf}}}:{{{ |
* Alias-Maps: für jede Liste werden eigene Alias-Einträge konfiguriert * Transport-Maps: allgemein gültige Konfiguration der Listendomain Die Alias-Maps-Variante ist in der offiziellen [[https://www.sympa.community/manual/install/configure-mail-server-postfix.html|Sympa-Dokumentation]] beschrieben. Die Nutzung der Transport-Map vereinfacht die Konfiguration jedoch erheblich. Diese wird im Folgenden auch beschrieben. * Anpassen der `/etc/postfix/master.cf`:{{{ |
Zeile 20: | Zeile 20: |
flags=hqRu user=sympa argv=/usr/lib/sympa/lib/sympa/queue ${recipient} | flags=hqRu null_sender= user=sympa argv=/usr/lib/sympa/lib/sympa/queue ${recipient} |
Zeile 22: | Zeile 22: |
flags=hqRu user=sympa argv=/usr/lib/sympa/lib/sympa/bouncequeue ${nexthop} }}} * In der {{{sympa.conf}}} wird der Pfad zum [[https://de.wikipedia.org/wiki/Mail_Transfer_Agent|MTA]] festgelegt - wichtig ist hier, das "Postfix to Sendmail compatibility interface" zu nutzen und nicht {{{/usr/sbin/postfix}}}:{{{ |
flags=hqRu null_sender= user=sympa argv=/usr/lib/sympa/lib/sympa/bouncequeue ${user}@${domain} sympabounce2 unix - n n - - pipe flags=hqRu null_sender= user=sympa argv=/usr/lib/sympa/lib/sympa/bouncequeue sympa@${domain} }}} * In `/etc/sympa/sympa/sympa.conf` wird der Pfad zum [[https://de.wikipedia.org/wiki/Mail_Transfer_Agent|MTA]] festgelegt - wichtig ist hier, das "Postfix to Sendmail compatibility interface" zu nutzen und nicht `/usr/sbin/postfix`:{{{ |
Zeile 26: | Zeile 28: |
* Zur Nutzung der Transport maps wird die alias-Funktionalität von Sympa deaktiviert - {{{sympa.conf}}}:{{{ | * Zur Nutzung der Transport-Maps wird die Alias-Funktionalität von Sympa unter `/etc/sympa/sympa/sympa.conf` deaktiviert:{{{ |
Zeile 28: | Zeile 30: |
* Folgende Einstellungen gehören nun in die {{{main.cf}}}:{{{ | * Folgende Einstellungen gehören nun in die `/etc/postfix/main.cf`:{{{ |
Zeile 34: | Zeile 36: |
transport_maps = regexp:/etc/postfix/sympa_transport_misc, regexp:/etc/postfix/sympa_transport}}} * Die Map für Aliasnamen wird festgelegt<<FootNote([[https://sympa-community.github.io/manual/customize/basics-addresses.html|Hintergrund]] zum Mapping für {{{sympa-request}}})>> - {{{/etc/postfix/sympa_virtual_alias}}}:{{{ /^sympa-(owner|request)\@listen\.example\.org$/ postmaster@example.org}}} * Die definierte transport-map-Tabelle wird nun gefüllt - {{{/etc/postfix/sympa_transport}}}:{{{ /^.*-owner\@listen\.example\.org$/ sympabounce:$1@listen.example.org /^.*\@listen\.example\.org$/ sympa: }}} * Damit die Mailverarbeitung von Sympa mit dem beschriebenen {{{-owner}}}-Mapping korrekt funktioniert, muss der {{{return_path_suffix}}} in der [[https://sympa-community.github.io/manual/man/sympa.conf.5.html|Standardeinstellung]] ({{{-owner}}}) belassen werden. * Damit die Abweisung von [[#Reject von ungültigen Empfängern|ungültigen Empfängeradressen]] korrekt funktioniert und wichtige Sympa-Adressen nicht abgelehnt werden, wird nun eine zweite transport-map-Tabelle angelegt - {{{/etc/postfix/sympa_transport_misc}}}:{{{ /^abuse-feedback-report\@listen\.example\.org$/ sympabounce:sympa@listen.example.org /^bounce\@listen\.example\.org$/ sympabounce:sympa@listen.example.org /^bounce\+.*\@listen\.example\.org$/ sympabounce:sympa@listen.example.org /^listmaster\@listen\.example\.org$/ sympa: /^sympa\@listen\.example\.org$/ sympa: |
transport_maps = hash:/etc/postfix/sympa_transport_misc, pcre:/etc/postfix/sympa_transport}}} * Die Map für Aliasnamen wird festgelegt. Die Umschreibung von {{{-owner}}} ist notwendig, da ansonsten die Mail nicht korrekt verarbeitet wird. - {{{/etc/postfix/sympa_virtual_alias}}}:{{{ /^sympa-(owner|request)@listen\.example\.org$/ postmaster@example.org /^(.*)-owner@listen\.example\.org$/ $1+owner@listen.example.org}}} * Damit die Mailverarbeitung von Sympa mit dem beschriebenen {{{-owner}}}-Mapping korrekt funktioniert, muss der {{{return_path_suffix}}} in der [[https://www.sympa.community/gpldoc/man/sympa_config.5.html|Standardeinstellung]] ({{{-owner}}}) belassen werden. * Die definierte Transport-Map-Tabelle wird nun gefüllt - {{{/etc/postfix/sympa_transport}}}:{{{ /^.*\+owner@listen\.example\.org$/ sympabounce: /^(?!bounce\+)(.*)@listen\.example\.org$/ sympa: }}} * Damit die Abweisung von [[#Reject von ungültigen Empfängern|ungültigen Empfängeradressen]] korrekt funktioniert und wichtige Sympa-Adressen nicht abgelehnt werden, wird nun eine zweite Transport-Map-Tabelle angelegt - `/etc/postfix/sympa_transport_misc`:{{{ abuse-feedback-report@listen.example.org sympabounce2: bounce@listen.example.org sympabounce2: listmaster@listen.example.org sympa: sympa@listen.example.org sympa: |
Zeile 50: | Zeile 52: |
postmap /etc/postfix/sympa_transport postmap /etc/postfix/sympa_transport_misc postmap /etc/postfix/sympa_virtual_alias |
|
Zeile 54: | Zeile 53: |
* Für jede neue Maildomain werden dann nur noch die entsprechenden Eintrage in den transpart- und map-Dateien ergänzt. | * Für jede neue Maildomain werden dann nur noch die entsprechenden Eintrage in den Transport- und Map-Dateien ergänzt. |
Zeile 58: | Zeile 58: |
virtual_mailbox_maps = regexp:/etc/postfix/sympa_transport_misc, proxy:mysql:/etc/postfix/sympa_virtual_mailbox_maps.cf}}} * SQL-Abfrage definieren ({{{/etc/postfix/sympa_virtual_mailbox_maps.cf}}}):{{{ |
virtual_mailbox_maps = hash:/etc/postfix/sympa_transport_misc, proxy:mysql:/etc/postfix/sympa_virtual_mailbox_maps.cf}}} * SQL-Abfrage definieren - `/etc/postfix/sympa_virtual_mailbox_maps.cf`:{{{ |
Zeile 71: | Zeile 71: |
Apache als Webserver für Sympa scheint um einiges performanter als ein Setup mit Nginx zu sein. Zudem gibt es einen [[https://github.com/sympa-community/sympa/issues/155|Bug]], der in der folgenden Nginx-Konfiguration aufgritt, bei Apache hingegen nicht. | * Apache als Webserver für Sympa scheint um einiges performanter als ein Setup mit Nginx zu sein. Zudem gibt es einen [[https://github.com/sympa-community/sympa/issues/155|Bug]], der in der folgenden Nginx-Konfiguration aufgritt, bei Apache hingegen nicht. * Die nachfolgende Konfiguration von Nginx und Apache geht davon aus, dass Sympa unter der Root-Domain ohne Pfad erreichbar ist (also listen.example.org statt listen.example.org/sympa). == Systemd-Unis anlegen == * Für die Weboberfläche müssen zwei Systemd-Units angelegt werden, die aktuell noch nicht im Debian-Paket [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986385|enthalten]] sind. * Die Datei `/etc/systemd/system/sympa.wwsympa.service` anlegen:{{{ [Unit] Description = Sympa Web Interface FastCGI backend [Service] User = sympa Group = sympa ExecStart = /usr/lib/cgi-bin/sympa/wwsympa.fcgi StandardOutput = null StandardInput = socket StandardError = null Restart = always RestartSec = 5 [Install] WantedBy = multi-user.target}}} * Die Datei `/etc/systemd/system/sympa.wwsympa.socket` anlegen:{{{ # /etc/systemd/system/wwsympa.socket [Unit] Description = Sympa Web Interface Socket [Socket] SocketUser = www-data SocketGroup = www-data SocketMode = 0660 RuntimeDirectory = sympa ListenStream = /run/wwsympa/wwsympa.socket [Install] WantedBy = sockets.target}}} * Die neuen Services aktivieren:{{{ systemctl daemon-reload systemctl enable wwsympa.service systemctl enable wwsympa.socket}}} * Und starten:{{{ systemctl start wwsympa.service systemctl start wwsympa.socket}}} |
Zeile 74: | Zeile 117: |
[[https://www.sympa.org/manual/web-interface|WWSympa]], die Weboberfläche für Sympa, ist ein Perl-CGI-Skript. Zur Beschleunigung kann Fastcgi genutzt werden. Da Nginx lediglich Fastcgi unterstützt, wird zusätzlich DebianPackage:Fcgiwrap benötigt. | WWSympa, die Weboberfläche für Sympa, ist ein Perl-CGI-Skript. Zur Beschleunigung kann Fastcgi genutzt werden. Da Nginx lediglich Fastcgi unterstützt, wird zusätzlich DebianPackage:Fcgiwrap benötigt. |
Zeile 77: | Zeile 120: |
* Fastcgi in {{{/etc/sympa/sympa/sympa.conf}}} aktivieren:{{{ | * Fastcgi in `/etc/sympa/sympa/sympa.conf` aktivieren:{{{ |
Zeile 79: | Zeile 122: |
* Allgemeine Fastcgi-Konfiguration unter {{{/etc/nginx/snippets/sympa_fcgi.conf}}} anlegen:{{{ gzip off; fastcgi_pass unix:/run/fcgiwrap.socket; fastcgi_split_path_info ^(/sympa)(.+)$; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; # According to RFC3875 (https://tools.ietf.org/html/rfc3875#section-4.1.14) in SERVER_NAME # we should put an actual hostname user came to. For nginx it is in $host # This will allow to run sympa multihost instances fastcgi_param SERVER_NAME $host; fastcgi_param REMOTE_USER $remote_user; fastcgi_param SCRIPT_FILENAME $document_root/wwsympa-wrapper.fcgi; fastcgi_param HTTP_HOST $http_host; fastcgi_intercept_errors on; }}} * Seiten-Konfiguration unter {{{/etc/nginx/sites-available/sympa}}} anlegen:{{{ |
* Seiten-Konfiguration unter `/etc/nginx/sites-available/sympa` anlegen:{{{ |
Zeile 112: | Zeile 125: |
root /usr/lib/cgi-bin/sympa; | root /usr/share/sympa; |
Zeile 127: | Zeile 140: |
location ^~ /css-sympa { alias /var/lib/sympa/css; access_log off; } location ^~ /pictures-sympa { alias /var/lib/sympa/pictures; access_log off; } |
|
Zeile 137: | Zeile 158: |
include /etc/nginx/snippets/sympa_fcgi.conf; } |
include /etc/nginx/fastcgi_params; fastcgi_pass unix:/run/wwsympa.socket; } |
Zeile 144: | Zeile 166: |
Eine Konfigurationsdatei für Sympa ist im Debian-Paket bereits enthalten, so dass diese nur in der Seitenkonfiguration eingebunden werden muss. Diese könnte {{{/etc/apache2/sites-enabled/listen.example.org}}} so aussehen<<FootNote(Die SSL-Konfiguration ist in diesem Beispiel nicht aufgeführt)>>:{{{ | * Eine Konfigurationsdatei für Sympa ist im Debian-Paket bereits enthalten. Allerdings wurde diese mit der Bullseye-Aktualisierung noch [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986395|nicht]] [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987127|angepasst]]. * Eine Beispielkonfiguration könnte so aussehen {{{/etc/apache2/sites-enabled/listen.example.org.conf}}} so aussehen<<FootNote(Die SSL-Konfiguration ist in diesem Beispiel nicht aufgeführt)>>:{{{ |
Zeile 147: | Zeile 170: |
DocumentRoot /usr/lib/cgi-bin/sympa | DocumentRoot /usr/share/sympa |
Zeile 151: | Zeile 174: |
Soll Sympa unter der Domain ohne Pfad erreichbar sein (also listen.example.org statt listen.example.org/sympa) muss der !ScriptAlias in {{{/etc/apache2/conf-available/sympa.conf}}} angepasst werden. Außerdem empfiehlt es sich, den Timeout für das Ausführen der FCGI-Anwendung zu erhöhen:{{{ #ScriptAlias /sympa /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi ScriptAliasMatch ^/(.*) /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi/$1 FcgidIOTimeout 300 }}} Wird Sympa mit Apache verwendet, so muss DebianPackage:apache2-suexec-pristine mit installiert und aktiviert werden ({{{a2enmod suexec}}}), da ansonsten der Apache-Neustart [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714082|fehl schlägt]]. |
* Noch `/etc/apache2/conf-available/sympa.conf` anpassen:{{{ <IfModule mod_proxy_fcgi.c> Alias /css-sympa /var/lib/sympa/css Alias /pictures-sympa /var/lib/sympa/pictures Alias /static-sympa /usr/share/sympa/static_content <Directory /usr/share/sympa/static_content> Require all granted </Directory> <Directory /var/lib/sympa/css> Require all granted </Directory> <Directory /var/lib/sympa/pictures> Require all granted </Directory> <LocationMatch "^/(?!.*-sympa)"> SetHandler "proxy:unix:/run/wwsympa/wwsympa.socket|fcgi://" Require all granted </LocationMatch> </IfModule>}}} * Der dargestellte `LocationMatch` leitet alle Sympa-Anfrage über den Proxy weiter. Ausnahme werden für alle Anfragen gemacht, die auf `-sympa` enden. Das umfasst die oben dargestellten Aliase. Diese Anfragen werden ohne Proxy direkt vom Webserver beantwortet. |
Zeile 162: | Zeile 200: |
Sympa kann mehrere Quellen zur [[https://www.sympa.org/manual/authentication|Authentifizierung]] nutzen. Diese werden in {{{/etc/sympa/auth.conf}}} definiert. | Sympa kann mehrere Quellen zur [[https://www.sympa.community/manual/customize/authentication-web.html|Authentifizierung]] nutzen. Diese werden in {{{/etc/sympa/auth.conf}}} definiert. |
Zeile 182: | Zeile 220: |
Eine Sympa-Instanz kann beliebig viele [[https://www.sympa.org/manual/virtual-hosts|Listen-Domains]] bedienen. Für die Weboberfläche werden dann, ähnlich zu Apache, virtuelle Host (Robots genannt) eingerichtet. | Eine Sympa-Instanz kann beliebig viele Listen-Domains bedienen. Für die Weboberfläche werden dann, ähnlich zu Apache, virtuelle Host (Robots genannt) eingerichtet. |
Zeile 197: | Zeile 235: |
Ziel ist es, dass nicht nur Admins Listen erstellen können, sondern auch ausgewählte reguläre [[https://www.sympa.org/manual_6.2/list-creation#who_can_create_lists_on_the_web_interface|Nutzer*innen]]. Dazu werden alle berechtigten Nutzer*innen in einem [[https://www.sympa.org/manual/authorization-scenarios|Scenario]] aufgelistet. | Ziel ist es, dass nicht nur Admins Listen erstellen können, sondern auch ausgewählte reguläre [[https://www.sympa.community/manual/admin/list-creation|Nutzer*innen]]. Dazu werden alle berechtigten Nutzer*innen in einem [[https://www.sympa.community/manual/customize/basics-scenarios.html|Scenario]] aufgelistet. |
Zeile 216: | Zeile 254: |
Voraussetzung für die Sympa-interne Erkennung und Behandlung von Spam ist das vorgeschaltete Prüfen und Markieren von eingehenden E-Mails durch einen Spamfilter. Üblicherweise erhalten die Mails dann einen zusätzlichen X-Header, bspw. bei Spammassassin ein {{{X-Spam-Status:}}}. Sympa kann aufgrund dieses Headers die Spam-Nachricht intern auch als solche Klassifizierung und speziell behandeln. | Findet durch Sympa keine Spambehandlung statt, werden Spam-Nachrichten an alle Abonnent:innen zugestellt. Verweigern dann die finalen Mailserver die Annahme, steigt der Fehlerstatus der Liste. Dies kann dann dazu führen, dass Sympa für die jeweilige Liste überhaupt keine Nachrichten mehr annimmt. Voraussetzung für die Sympa-interne Erkennung und Behandlung von Spam ist das vorgeschaltete Prüfen und Markieren von eingehenden E-Mails durch einen Spamfilter. Üblicherweise erhalten die Mails dann einen zusätzlichen X-Spam-Header, bspw. bei Rspamd `X-Spam-Status: Yes`. Sympa kann aufgrund dieses Headers die Spam-Nachricht intern auch als solche markieren und speziell behandeln. |
Zeile 219: | Zeile 259: |
Die [[https://sympa-community.github.io/gpldoc/man/sympa.conf.5.html#tag-based-spam-filtering|Tag-basierte]] Spambehandlung wird über die {{{sympa.conf}}} konfiguriert:{{{ | Die [[https://sympa-community.github.io/gpldoc/man/sympa.conf.5.html#tag-based-spam-filtering|Tag-basierte]] Spambehandlung wird über die {{{sympa.conf}}} konfiguriert. Folgende Optionen stehen zur Verfügung{{{ |
Zeile 228: | Zeile 268: |
[[https://sympa-community.github.io/gpldoc/man/sympa.conf.5.html#spam_status|Diese]] ist standardmäßig über das Scenario {{{spam_status.x-spam-status}}} aktiviert. Über die Option {{{spam_status}}} kann in der {{{sympa.conf}}} jedoch auch ein anderes Scenario definiert werden. Im Scenario selbst kann dann die Prüfung mehrere unterschiedlicher Header definiert werden. | [[https://www.sympa.community/gpldoc/man/sympa_config.5.html#spam_status|Diese]] ist standardmäßig über das Scenario {{{spam_status.x-spam-status}}} aktiviert. Über die Option {{{spam_status}}} kann in der {{{sympa.conf}}} jedoch auch ein anderes Scenario definiert werden. Im Scenario selbst kann dann die Prüfung mehrerer unterschiedlicher Header definiert werden. |
Zeile 232: | Zeile 272: |
== Spambehandlung == Eine durch Sympa als Spam markierte Nachricht ({{{X-Sympa-Spam-Status:}}}) wird in moderierten Listen nicht an [listname]-request, [listname]-editor oder die listmaster-Adresse weiter geleitet. Soll verhindert werden, dass Spam-Nachrichten über öffentliche Listen zugestellt werden, muss das entsprechende send-Scenario angepasst werden. Hier am Beispiel von {{{send.public}}}:{{{ title.gettext public list equal([msg->spam_status],'spam') smtp,md5,dkim,smime -> editorkey,quiet true() smtp,dkim,md5,smime -> do_it}}} Spamnachrichten laden dadurch in der Moderationswarteschlange, alle anderen Nachrichten werden zugestellt. |
=== Spambehandlung === Ziel ist es, dass Sympa eine als Spam markierte Nachricht (`X-Sympa-Spam-Status: Yes`) in die Moderationswarteschlange leitet. Da passiert in zwei Schritte: Über das Scenario `/usr/share/sympa/default/scenari/spam_status.x-spam-status` wird definiert, wann eine Mail als Spam gilt. Für eigene Anpassungen kann die Datei nach `/etc/sympa/scenari` kopiert werden. Wir verwenden Rspamd für die Spammarkierung. Entsprechend wird die Datei angepasst<<FootNote(Rspamd befüllt den X-Spam-Header mit `Yes` statt mit `yes` wie Spamassassin)>>:{{{ title.gettext test x-spam-status header match([header->X-Spam-Status][-1],/^\s*(?i)yes/) smtp,dkim,smime,md5 -> spam true() smtp,dkim,md5,smime -> ham}}} Anschießend muss ein `send`-Scenario definiert werden, das die Mail in die Moderationswarteschlage verschiebt. Praktischerweise lässt sich ein [[https://sympa-community.github.io/manual/customize/basics-scenarios.html#scenario-implicit-inclusion|gemeinsames]] Scenario definieren, dass für alle Listentypen genutzt wird. Es wird als `/etc/sympa/scenari/include.send.header` angelegt:{{{ match([msg->spam_status], /spam/) smtp,dkim,md5,smime -> editorkey,quiet}}} |
Zeile 242: | Zeile 283: |
Zeile 243: | Zeile 285: |
* https://www.sympa.org/manual/dmarc * https://www.sympa.org/manualtest/conf-parameters/part3#loop_prevention --> stille Verweigerung von Listenmails (bspw. leiche Message-ID) |
* https://www.sympa.community/manual/customize/basics-acceptance.html#loop-prevention --> stille Verweigerung von Listenmails (bspw. gleiche Message-ID) |
Diese Seite beschreibt die Installation und Einrichtung von Sympa, Postfix und Nginx oder Apache unter Debian Bullseye.
Inhaltsverzeichnis
Installation von Sympa
Sympa mit apt installieren:
apt install sympa
Bei der Installation wird gleich die Datenbank mit eingerichtet. Dies kann auch manuell durchgeführt werden.
Postfix einrichten
Prinzipiell gibt es zwei Möglichkeiten, wie Sympa mit Postfix zusammen arbeiten kann:
- Alias-Maps: für jede Liste werden eigene Alias-Einträge konfiguriert
- Transport-Maps: allgemein gültige Konfiguration der Listendomain
Die Alias-Maps-Variante ist in der offiziellen Sympa-Dokumentation beschrieben. Die Nutzung der Transport-Map vereinfacht die Konfiguration jedoch erheblich. Diese wird im Folgenden auch beschrieben.
Anpassen der /etc/postfix/master.cf:
sympa unix - n n - - pipe flags=hqRu null_sender= user=sympa argv=/usr/lib/sympa/lib/sympa/queue ${recipient} sympabounce unix - n n - - pipe flags=hqRu null_sender= user=sympa argv=/usr/lib/sympa/lib/sympa/bouncequeue ${user}@${domain} sympabounce2 unix - n n - - pipe flags=hqRu null_sender= user=sympa argv=/usr/lib/sympa/lib/sympa/bouncequeue sympa@${domain}
In /etc/sympa/sympa/sympa.conf wird der Pfad zum MTA festgelegt - wichtig ist hier, das "Postfix to Sendmail compatibility interface" zu nutzen und nicht /usr/sbin/postfix:
sendmail /usr/sbin/sendmail
Zur Nutzung der Transport-Maps wird die Alias-Funktionalität von Sympa unter /etc/sympa/sympa/sympa.conf deaktiviert:
sendmail_aliases none
Folgende Einstellungen gehören nun in die /etc/postfix/main.cf:
sympa_destination_recipient_limit = 1 sympabounce_destination_recipient_limit = 1 recipient_delimiter = + virtual_mailbox_domains = listen.example.org virtual_alias_maps = regexp:/etc/postfix/sympa_virtual_alias transport_maps = hash:/etc/postfix/sympa_transport_misc, pcre:/etc/postfix/sympa_transport
Die Map für Aliasnamen wird festgelegt. Die Umschreibung von -owner ist notwendig, da ansonsten die Mail nicht korrekt verarbeitet wird. - /etc/postfix/sympa_virtual_alias:
/^sympa-(owner|request)@listen\.example\.org$/ postmaster@example.org /^(.*)-owner@listen\.example\.org$/ $1+owner@listen.example.org
Damit die Mailverarbeitung von Sympa mit dem beschriebenen -owner-Mapping korrekt funktioniert, muss der return_path_suffix in der Standardeinstellung (-owner) belassen werden.
Die definierte Transport-Map-Tabelle wird nun gefüllt - /etc/postfix/sympa_transport:
/^.*\+owner@listen\.example\.org$/ sympabounce: /^(?!bounce\+)(.*)@listen\.example\.org$/ sympa:
Damit die Abweisung von ungültigen Empfängeradressen korrekt funktioniert und wichtige Sympa-Adressen nicht abgelehnt werden, wird nun eine zweite Transport-Map-Tabelle angelegt - /etc/postfix/sympa_transport_misc:
abuse-feedback-report@listen.example.org sympabounce2: bounce@listen.example.org sympabounce2: listmaster@listen.example.org sympa: sympa@listen.example.org sympa:
Anschließend:
postfix reload
- Für jede neue Maildomain werden dann nur noch die entsprechenden Eintrage in den Transport- und Map-Dateien ergänzt.
Reject von ungültigen Empfängern
Mit der aufgeführten Postfix-Konfiguration werden alle Anfragen an die definierte virtual_mailbox_domains angenommen und an Sympa weiter geleitet, auch solche, die einen ungültigen, nicht existierenden Listennamen enthalten. Dies kann insbesondere zu Backscatter-Problemen führen. Wünschenswert wäre, dass Postfix prüft, ob eine Liste existiert und bei einem ungültigen Listennamen die Annahme der Mail verweigert. Dies lässt sich mit einer einfachen sql-Abfrage1 machen.
Map definieren (/etc/postfix/main.cf):
virtual_mailbox_maps = hash:/etc/postfix/sympa_transport_misc, proxy:mysql:/etc/postfix/sympa_virtual_mailbox_maps.cf
SQL-Abfrage definieren - /etc/postfix/sympa_virtual_mailbox_maps.cf:
user = sympa password = strenggeheim hosts = localhost dbname = sympa query = SELECT 'present' FROM list_table WHERE name_list='%u' or name_list = replace('%u', '-request', '') or name_list = replace('%u', '-editor', '') or name_list = replace('%u', '-subscribe', '') or name_list = replace('%u', '-unsubscribe', '')
Webserver einrichten
Apache als Webserver für Sympa scheint um einiges performanter als ein Setup mit Nginx zu sein. Zudem gibt es einen Bug, der in der folgenden Nginx-Konfiguration aufgritt, bei Apache hingegen nicht.
- Die nachfolgende Konfiguration von Nginx und Apache geht davon aus, dass Sympa unter der Root-Domain ohne Pfad erreichbar ist (also listen.example.org statt listen.example.org/sympa).
Systemd-Unis anlegen
Für die Weboberfläche müssen zwei Systemd-Units angelegt werden, die aktuell noch nicht im Debian-Paket enthalten sind.
Die Datei /etc/systemd/system/sympa.wwsympa.service anlegen:
[Unit] Description = Sympa Web Interface FastCGI backend [Service] User = sympa Group = sympa ExecStart = /usr/lib/cgi-bin/sympa/wwsympa.fcgi StandardOutput = null StandardInput = socket StandardError = null Restart = always RestartSec = 5 [Install] WantedBy = multi-user.target
Die Datei /etc/systemd/system/sympa.wwsympa.socket anlegen:
# /etc/systemd/system/wwsympa.socket [Unit] Description = Sympa Web Interface Socket [Socket] SocketUser = www-data SocketGroup = www-data SocketMode = 0660 RuntimeDirectory = sympa ListenStream = /run/wwsympa/wwsympa.socket [Install] WantedBy = sockets.target
Die neuen Services aktivieren:
systemctl daemon-reload systemctl enable wwsympa.service systemctl enable wwsympa.socket
Und starten:
systemctl start wwsympa.service systemctl start wwsympa.socket
Nginx
WWSympa, die Weboberfläche für Sympa, ist ein Perl-CGI-Skript. Zur Beschleunigung kann Fastcgi genutzt werden. Da Nginx lediglich Fastcgi unterstützt, wird zusätzlich Fcgiwrap benötigt.
Installation der Pakete:
apt install nginx-light fcgiwrap
Fastcgi in /etc/sympa/sympa/sympa.conf aktivieren:
use_fast_cgi 1
Seiten-Konfiguration unter /etc/nginx/sites-available/sympa anlegen:
server { server_name listen.example.org; root /usr/share/sympa; access_log /var/log/nginx/sympa.access.log; error_log /var/log/nginx/sympa.error.log; error_page 403 500 502 503 504 /50x.html; # While configuring sympa, you should specify wwsympa_url for each robot. # if you do not do so, sympa will generate wwsympa_url as ${robot_name}/sympa. # So to prevent non-active urls for robots without wwsympa_url, we do this redirect: rewrite ^/sympa/(.*)$ /$1 permanent; location ^~ /static-sympa/ { alias /var/lib/sympa/static_content/; access_log off; } location ^~ /css-sympa { alias /var/lib/sympa/css; access_log off; } location ^~ /pictures-sympa { alias /var/lib/sympa/pictures; access_log off; } location /50x.html { root /usr/share/nginx/html; } location ~* \.(php|pl|py|jsp|asp|sh|cgi|bin|csh|ksh|out|run|o)$ { deny all; } location ~ /\.ht { deny all; } location / { include /etc/nginx/fastcgi_params; fastcgi_pass unix:/run/wwsympa.socket; } }
- Anschließend Seitenkonfiguration aktivieren und Nginx neu laden.
Apache
Eine Konfigurationsdatei für Sympa ist im Debian-Paket bereits enthalten. Allerdings wurde diese mit der Bullseye-Aktualisierung noch nicht angepasst.
Eine Beispielkonfiguration könnte so aussehen /etc/apache2/sites-enabled/listen.example.org.conf so aussehen2:
<VirtualHost *:80> ServerName listen.example.org DocumentRoot /usr/share/sympa ErrorLog /var/log/apache2/listen.example.org.log include /etc/apache2/conf-available/sympa.conf </VirtualHost>
Noch /etc/apache2/conf-available/sympa.conf anpassen:
<IfModule mod_proxy_fcgi.c> Alias /css-sympa /var/lib/sympa/css Alias /pictures-sympa /var/lib/sympa/pictures Alias /static-sympa /usr/share/sympa/static_content <Directory /usr/share/sympa/static_content> Require all granted </Directory> <Directory /var/lib/sympa/css> Require all granted </Directory> <Directory /var/lib/sympa/pictures> Require all granted </Directory> <LocationMatch "^/(?!.*-sympa)"> SetHandler "proxy:unix:/run/wwsympa/wwsympa.socket|fcgi://" Require all granted </LocationMatch> </IfModule>
Der dargestellte LocationMatch leitet alle Sympa-Anfrage über den Proxy weiter. Ausnahme werden für alle Anfragen gemacht, die auf -sympa enden. Das umfasst die oben dargestellten Aliase. Diese Anfragen werden ohne Proxy direkt vom Webserver beantwortet.
Authentifizierung in der Weboberfläche
Sympa kann mehrere Quellen zur Authentifizierung nutzen. Diese werden in /etc/sympa/auth.conf definiert.
Im folgenden Beispiel erfolgt die Authentifizierung bei Nutzer mit einer example.org-Mailadresse per LDAP, alle anderen Nutzer werden über die interne Datenbank authentifiziert:
# LDAP authentication ldap regexp example\.org host ldap.example.org timeout 20 suffix sc=mailAccount,ou=People,o=ldap,dc=example,dc=org get_dn_by_uid_filter (cn=[sender]) get_dn_by_email_filter (mail=[sender]) email_attribute mail # Internal authentication by email and password user_table negative_regexp example\.org
Anmeldungen mit einem LDAP-Account sind sowohl nur mit Nutzername (get_dn_by_uid_filter), als auch mit der vollständigen Mailadresse (get_dn_by_email_filter) möglich.
Volle Administrationsrechte für die Weboberfläche erhalten alle Accounts, die unter listmasters in /etc/sympa/sympa/sympa.conf geführt werden. Listmaster haben auf alle Robots volle Rechte.
Multidomain-Unterstützung
Eine Sympa-Instanz kann beliebig viele Listen-Domains bedienen. Für die Weboberfläche werden dann, ähnlich zu Apache, virtuelle Host (Robots genannt) eingerichtet.
- MX-Einträge und CNAME einrichten
Listenverzeichnis erstellen und Besitzer (sympa:sympa) ändern:
mkdir /var/lib/sympa/list_data/ml.example.org
Konfigurationsverzeichnis erstellen und Besitzer ändern:
mkdir /etc/sympa/ml.example.org
Konfigurationsdatei für den neuen Robot anlegen - /ect/sympa/ml.example.org/robot.conf und Besitzer ändern:
http_host ml.example.org wwsympa_url ml.example.org email ml.example.org title Listenverwaltung 2
Damit die Nutzeranmeldung funktioniert, muss die auth.conf nach /ect/sympa/ml.example.org kopiert werden
- Eigene Webserver-Seitenkonfiguration anlegen
Nutzern die Listenerstellung erlauben
Ziel ist es, dass nicht nur Admins Listen erstellen können, sondern auch ausgewählte reguläre Nutzer*innen. Dazu werden alle berechtigten Nutzer*innen in einem Scenario aufgelistet.
Zuerst wird in der sympa.conf festgelegt, welches Scenario die Rechte für die Listenerstellung definiert:
create_list list_creators
Nun wird ein entsprechendes Scenario angelegt. Bei nur einem Robot liegt sie unter /etc/sympa/scenari. Bei verschiedenen Robots unter /ect/sympa/$ROBOT/scenari. Der Dateiname muss eine Kombination aus value.wert entsprechend der sympa.conf sein - in diesem Fall also create_list.list_creators:
title Users that can create lists equal([sender], 'foo@example.org') md5 -> do_it
Das Scenario definiert also, dass eine bestimmte Nutzerin (equal([sender], 'foo@example.org') nach der Anmeldung im Webinterface (md5) entsprechende Rechte (--> listmaster) erhält.
- Nach dem selben Schema können nun weitere Nutzer*innen definiert werden
Mit der Definition von create_list verlieren die listmaster die Möglichkeit, Listen anzulegen - deshalb kann das ursprüngliche Scenario am Ende des neuen Scenarios eingebunden werden3:
title Users that can create lists equal([sender], 'foo@example.org') md5 -> do_it include create_list.listmaster
Da der erwartete Dateiname nun include.create_list.listmaster ist, muss noch ein Symlink erstellt werden:
ln -s /usr/share/sympa/default/scenari/create_list.listmaster /etc/sympa/scenari/include.create_list.listmaster
- Abschließend muss Sympa neu gestartet werden
Umgang mit Spam
Findet durch Sympa keine Spambehandlung statt, werden Spam-Nachrichten an alle Abonnent:innen zugestellt. Verweigern dann die finalen Mailserver die Annahme, steigt der Fehlerstatus der Liste. Dies kann dann dazu führen, dass Sympa für die jeweilige Liste überhaupt keine Nachrichten mehr annimmt.
Voraussetzung für die Sympa-interne Erkennung und Behandlung von Spam ist das vorgeschaltete Prüfen und Markieren von eingehenden E-Mails durch einen Spamfilter. Üblicherweise erhalten die Mails dann einen zusätzlichen X-Spam-Header, bspw. bei Rspamd X-Spam-Status: Yes. Sympa kann aufgrund dieses Headers die Spam-Nachricht intern auch als solche markieren und speziell behandeln.
Tag-basierte Spamerkennung
Die Tag-basierte Spambehandlung wird über die sympa.conf konfiguriert. Folgende Optionen stehen zur Verfügung
antispam_feature on antispam_tag_header_name X-Spam-Status antispam_tag_header_spam_regexp ^\s*Yes antispam_tag_header_ham_regexp ^\s*No
Wobei die Option antispam_feature on die Spamassassin-Defaults für die anderen antispam-Optionen aktiviert. Zudem sorgt diese Option dafür, dass Spam-Nachrichten im Webinterface speziell markiert werden.
Scenario-basierte Spamerkennung
Diese ist standardmäßig über das Scenario spam_status.x-spam-status aktiviert. Über die Option spam_status kann in der sympa.conf jedoch auch ein anderes Scenario definiert werden. Im Scenario selbst kann dann die Prüfung mehrerer unterschiedlicher Header definiert werden.
Damit Spam-Nachrichten auch als solche im Webinterface angezeigt werden, sollte ebenfalls die Option antispam_feature on aktiviert werden.
Spambehandlung
Ziel ist es, dass Sympa eine als Spam markierte Nachricht (X-Sympa-Spam-Status: Yes) in die Moderationswarteschlange leitet. Da passiert in zwei Schritte: Über das Scenario /usr/share/sympa/default/scenari/spam_status.x-spam-status wird definiert, wann eine Mail als Spam gilt. Für eigene Anpassungen kann die Datei nach /etc/sympa/scenari kopiert werden. Wir verwenden Rspamd für die Spammarkierung. Entsprechend wird die Datei angepasst4:
title.gettext test x-spam-status header match([header->X-Spam-Status][-1],/^\s*(?i)yes/) smtp,dkim,smime,md5 -> spam true() smtp,dkim,md5,smime -> ham
Anschießend muss ein send-Scenario definiert werden, das die Mail in die Moderationswarteschlage verschiebt. Praktischerweise lässt sich ein gemeinsames Scenario definieren, dass für alle Listentypen genutzt wird. Es wird als /etc/sympa/scenari/include.send.header angelegt:
match([msg->spam_status], /spam/) smtp,dkim,md5,smime -> editorkey,quiet
Fussnoten und Hinweise
https://www.sympa.community/manual/customize/basics-acceptance.html#loop-prevention --> stille Verweigerung von Listenmails (bspw. gleiche Message-ID)
- Topics anpassen: /etc/sympa/topics.conf