Diese Seite beschreibt die Installation und Einrichtung von Sympa, Postfix und Nginx oder Apache unter Debian Bullseye.

Installation von Sympa

Postfix einrichten

Prinzipiell gibt es zwei Möglichkeiten, wie Sympa mit Postfix zusammen arbeiten kann:

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.

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-Abfrage2 machen.

Webserver einrichten

Systemd-Unis anlegen

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.

Apache

Authentifizierung in der Weboberfläche

Sympa kann mehrere Quellen zur Authentifizierung nutzen. Diese werden in /etc/sympa/auth.conf definiert.

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.

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.

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 angepasst5:

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

  1. Hintergrund zum Mapping für sympa-request. Die Umschreibung von -owner ist notwendig, da ansonsten die Mail nicht korrekt verarbeitet wird (1)

  2. Die Abfrage prüft nur den user-Teil der Mailadresse. (2)

  3. Die SSL-Konfiguration ist in diesem Beispiel nicht aufgeführt (3)

  4. Für das Scenario gilt: First match wins (4)

  5. Rspamd befüllt den X-Spam-Header mit Yes statt mit yes wie Spamassassin (5)


Creative Commons Lizenzvertrag
This page is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.