16680
Kommentar: Regexp-Zusammenfassung
|
← Revision 67 vom 2022-11-25 21:23:18 ⇥
0
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 1: | Zeile 1: |
## page was renamed from Sympa Diese Seite beschreibt die Installation und Einrichtung von [[https://sympa.org|Sympa]], Postfix und Nginx/Apache unter [[https://debian.or|Debian]] Stretch. <<TableOfContents>> = Installation von Sympa = 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:{{{ apt install sympa}}} Bei der Installation wird gleich die Datenbank mit eingerichtet. Dies kann auch [[https://www.sympa.org/manual/database|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 [[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}}}:{{{ 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 ${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}}}:{{{ 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 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|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 [[https://de.wikipedia.org/wiki/Backscatter_(E-Mail)|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-Abfrage<<FootNote(Die Abfrage prüft nur den user-Teil der Mailadresse.)>> 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 [[https://github.com/sympa-community/sympa/issues/155|Bug]], der in der folgenden Nginx-Konfiguration aufgritt, bei Apache hingegen nicht. == Nginx == [[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. * 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 aussehen<<FootNote(Die SSL-Konfiguration ist in diesem Beispiel nicht aufgeführt)>>:{{{ <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 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]]. = Authentifizierung in der Weboberfläche = Sympa kann mehrere Quellen zur [[https://www.sympa.org/manual/authentication|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 [[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. * 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 [[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. * 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 werden<<FootNote(Für das Scenario gilt: First match wins)>>:{{{ 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 [[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''' * 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://kradalby.no/sympa.html|Nginx-Konfiguration]] * [[https://wiki.debian.org/Sympa/Nginx|Nginx-Konfiguration im Debian-Wiki]] * Topics anpassen: /etc/sympa/topics.conf |