Unterschiede zwischen den Revisionen 45 und 47 (über 2 Versionen hinweg)
Revision 45 vom 2019-01-19 00:52:15
Größe: 14649
Autor: anonym
Kommentar: format
Revision 47 vom 2019-08-15 19:53:23
Größe: 16925
Autor: anonym
Kommentar: Spambehandlung
Gelöschter Text ist auf diese Art markiert. Hinzugefügter Text ist auf diese Art markiert.
Zeile 38: Zeile 38:
^sympa-(owner|request)\@listen\.example\.org$/ postmaster@example.org /^sympa-(owner|request)\@listen\.example\.org$/ postmaster@example.org
Zeile 217: Zeile 217:
= Fussnoten und Hinweise = = Umgang mit Spam =
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.

== Tag-basierte Spamerkennung ==
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:{{{
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 ==
[[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.

Damit Spam-Nachrichten auch als solche im Webinterface angezeigt werden, sollte ebenfalls die Option {{{antispam_feature on}}} aktiviert werden.

== 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.

----
'''Fussnoten und Hinweise'''

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

Installation von Sympa

Ab 6.1.22 bringt Sympa DMARC-Funktionalität mit - diese Version ist erst in Buster enthalten. Gleich welche Version es ist:

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 konfiguiert
  • Transport maps: lediglich allgemeine Konfiguration der Listendomain

Die alias-maps-Variante ist in der offiziellen Sympa-Dokumentation beschrieben. Die Nutzung der transport map vereinfacht die Konfiguration also erheblich. Diese wird im Folgenden auch beschrieben.

  • Anpassen der master.cf:

    sympa      unix  -       n       n       -       -       pipe
      flags=hqRu user=sympa argv=/usr/lib/sympa/lib/sympa/queue ${recipient}
    sympabounce unix -       n       n       -       -       pipe
      flags=hqRu user=sympa argv=/usr/lib/sympa/lib/sympa/bouncequeue ${user}@${domain}
    sympabounce2 unix -       n       n       -       -       pipe
      flags=hqRu user=sympa argv=/usr/lib/sympa/lib/sympa/bouncequeue sympa@${domain}
  • In der 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 deaktiviert - sympa.conf:

    sendmail_aliases  none
  • Folgende Einstellungen gehören nun in die 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 = regexp:/etc/postfix/sympa_transport_misc, regexp:/etc/postfix/sympa_transport
  • Die Map für Aliasnamen wird festgelegt1 - /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:
    /^.*\@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:
    /^bounce\+.*\@listen\.example\.org$/            sympabounce2:
    /^sympa\@listen\.example\.org$/                 sympa:
  • Anschließend:

    postmap /etc/postfix/sympa_transport
    postmap /etc/postfix/sympa_transport_misc
    postmap /etc/postfix/sympa_virtual_alias
    postfix reload
  • Für jede neue Maildomain werden dann nur noch die entsprechenden Eintrage in den transpart- 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-Abfrage2 machen.

  • Map definieren (/etc/postfix/main.cf):

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

    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.

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

    server {
        server_name  listen.example.org;
        root         /usr/lib/cgi-bin/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 /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/snippets/sympa_fcgi.conf;
        }
    }
  • Anschließend Seitenkonfiguration aktivieren und Nginx neu laden.

Apache

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

<VirtualHost *:80>
        ServerName      listen.example.org
        DocumentRoot    /usr/lib/cgi-bin/sympa
        ErrorLog        /var/log/apache2/listen.example.org.log 
        include         /etc/apache2/conf-available/sympa.conf
</VirtualHost>

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 apache2-suexec-pristine mit installiert und aktiviert werden (a2enmod suexec), da ansonsten der Apache-Neustart fehl schlägt.

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

    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

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.

Tag-basierte Spamerkennung

Die Tag-basierte Spambehandlung wird über die sympa.conf konfiguriert:

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 mehrere unterschiedlicher Header definiert werden.

Damit Spam-Nachrichten auch als solche im Webinterface angezeigt werden, sollte ebenfalls die Option antispam_feature on aktiviert werden.

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.


Fussnoten und Hinweise

  1. Hintergrund zum Mapping für sympa-request 7 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)


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