Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
centos:mail_c7:spam_11 [20.04.2018 10:32. ]
127.0.0.1 Externe Bearbeitung
centos:mail_c7:spam_11 [28.01.2019 11:17. ] (aktuell)
django SRS - Sender Rewriting Scheme unter CentOS 7.x #SRS #Postfix #MTA #CentOS7
Zeile 1: Zeile 1:
 ====== SRS - Sender Rewriting Scheme unter CentOS 7.x ====== ====== SRS - Sender Rewriting Scheme unter CentOS 7.x ======
 {{:​centos:​mail_c6:​spf-logo-medium.png?​nolink |SPF Logo}} {{:​centos:​mail_c6:​spf-logo-medium.png?​nolink |SPF Logo}}
-Im Kapitel [[centos:​mail_c7:​spam_10|SPF - Sender Policy Framework]] sind wir bereits darauf eingegangen,​ dass mit unter Probleme bei Mailumleitungen und/oder WebFormularen auftauchen können. Mit **[[http://​www.openspf.org/​SRS|SRS]]**((**S**ender **R**ewriting **S**cheme)) kann ein Mailserver die eMail-Adresse im Envelop ​umschreiben und anpassen.+Im Kapitel [[centos:​mail_c7:​spam_10|SPF - Sender Policy Framework]] sind wir bereits darauf eingegangen,​ dass mit unter Probleme bei Mailumleitungen und/oder WebFormularen auftauchen können. Mit **[[http://​www.openspf.org/​SRS|SRS]]**((**S**ender **R**ewriting **S**cheme)) kann ein Mailserver die eMail-Adresse im Envelope ​umschreiben und anpassen.
  
 Das nachfolgende Schaubild verdeutlicht,​ warum bei zu strenger Wahl des SPF-Records der Versand bei einer Weiterleitung (alias) fehlschlägt. Der empfangende Mailserver überprüft die Angaben **HELO** und **MAIL FROM** im **Envelop** der eMail. Hierzu frägt der Mailserver den SPF-Record des sendenden Systems ab und vergleicht die IP-Adresse/​Namen des einliefernden Empfängers mit den legitimen Sendern des SMF-Records. Ist der einliefernde Mailserver berechtigt, kann mit der weiteren Annahme und Prüfung fortgefahren werden. Ist der einliefernde Mailserver aber __**nicht**__ berechtigt, quittiert das System den Zustellversuch mit einem Fehler-(code) **550**. Das nachfolgende Schaubild verdeutlicht,​ warum bei zu strenger Wahl des SPF-Records der Versand bei einer Weiterleitung (alias) fehlschlägt. Der empfangende Mailserver überprüft die Angaben **HELO** und **MAIL FROM** im **Envelop** der eMail. Hierzu frägt der Mailserver den SPF-Record des sendenden Systems ab und vergleicht die IP-Adresse/​Namen des einliefernden Empfängers mit den legitimen Sendern des SMF-Records. Ist der einliefernde Mailserver berechtigt, kann mit der weiteren Annahme und Prüfung fortgefahren werden. Ist der einliefernde Mailserver aber __**nicht**__ berechtigt, quittiert das System den Zustellversuch mit einem Fehler-(code) **550**.
Zeile 48: Zeile 48:
 </​uml>​ </​uml>​
  
-Da in dem fiktiven ​ Beispiel der Mailserver mx01.nausch.org __**nicht berechtigt**__ ist Nachrichten der Domain example.org zu verschicken,​ schlägt die Zustellung an das Zielsystemfehl und der Mailserver wird die zuvor angenommene eMail zurück an den Absender bouncen!+Da in dem fiktiven Beispiel der Mailserver mx01.nausch.org __**nicht berechtigt**__ ist Nachrichten der Domain example.org zu verschicken,​ schlägt die Zustellung an das Zielsystemfehl und der Mailserver wird die zuvor angenommene eMail zurück an den Absender bouncen!
  
 Damit die Nachricht nun beim eigentlichen Zielsystem ankommt, müssen wir dafür Sorge tragen, dass das relayende System, also unser Mailserver, beim **MAIL FROM** im **Envelope** unsere Domain als Absender setzt. Dann kann das eigentliche Zielsystem, unsere eMail annehmen, da wir für unseren Mailserver einen entsprechend gültigen SPF-Record vorweisen können. Für den Fall, dass die Nachricht aber vom Zielsystem nicht zugestellt werden kann, oder eben von diesem später gebounced werden könnte, müssen wir uns nun die Absender-Adresse des ursprünglichen Mailservers merken. Nur so haben wir die Möglichkeit,​ den ursprünglichen Absender über den Zustellfehlversuch zu informieren. ​ Damit die Nachricht nun beim eigentlichen Zielsystem ankommt, müssen wir dafür Sorge tragen, dass das relayende System, also unser Mailserver, beim **MAIL FROM** im **Envelope** unsere Domain als Absender setzt. Dann kann das eigentliche Zielsystem, unsere eMail annehmen, da wir für unseren Mailserver einen entsprechend gültigen SPF-Record vorweisen können. Für den Fall, dass die Nachricht aber vom Zielsystem nicht zugestellt werden kann, oder eben von diesem später gebounced werden könnte, müssen wir uns nun die Absender-Adresse des ursprünglichen Mailservers merken. Nur so haben wir die Möglichkeit,​ den ursprünglichen Absender über den Zustellfehlversuch zu informieren. ​
Zeile 54: Zeile 54:
 Und an dieser Stelle setzt nun Sender Rewriting Scheme (kurz **SRS**) an! Wird eine eMail weitergeleitet,​ so setzt der SRS-Deamon die Envelop-Adresse **MAIL FROM** nach folgendem Schema: //​**SRS0+xxxx=yy=example.com=alice@yourdomain.org**//,​ den wird dann auch als **Return-Path** im Mailheader unserer eMail beim entsprechenden Zielsystem vorfinden. Und an dieser Stelle setzt nun Sender Rewriting Scheme (kurz **SRS**) an! Wird eine eMail weitergeleitet,​ so setzt der SRS-Deamon die Envelop-Adresse **MAIL FROM** nach folgendem Schema: //​**SRS0+xxxx=yy=example.com=alice@yourdomain.org**//,​ den wird dann auch als **Return-Path** im Mailheader unserer eMail beim entsprechenden Zielsystem vorfinden.
   Return-Path:​ <​SRS0+bCEv=YT=web.de=honeypot_for_spam@nausch.org>​   Return-Path:​ <​SRS0+bCEv=YT=web.de=honeypot_for_spam@nausch.org>​
-Sollte die eMail zu uns zurück-bouncen,​ so kann unser Mailserver mit den Angaben dann, den ursprünglichen Absender, in dem Beispiel also //​honeypot_for_spam@web.de//​ rekonstruieren und den Bounce an den richtigen Absender zurück schicken. Damit nun der //**revers-SRS**// nicht als open-relay-Adresse missbraucht werden kann, werden bei der Envelop-Adresse die beiden Feder **xxx** und **yy** eingesetzt, die zum einen eine kryptografische Signatur und einen Zeitstempel repräsentieren. Sollten bei einem Bounce diese Angaben nicht stimmen, wird die Annahme der Nachricht verweigert, also verworfen.+Sollte die eMail zu uns zurück-bouncen,​ so kann unser Mailserver mit den Angaben dann, den ursprünglichen Absender, in dem Beispiel also //​honeypot_for_spam@web.de//​ rekonstruieren und den Bounce an den richtigen Absender zurück schicken. Damit nun der //**reverse-SRS**// nicht als open-relay-Adresse missbraucht werden kann, werden bei der Envelope-Adresse die beiden Feder **xxx** und **yy** eingesetzt, die zum einen eine kryptografische Signatur und einen Zeitstempel repräsentieren. Sollten bei einem Bounce diese Angaben nicht stimmen, wird die Annahme der Nachricht verweigert, also verworfen.
  
 ===== Postfix Voraussetzungen ===== ===== Postfix Voraussetzungen =====
Zeile 149: Zeile 149:
                                                                   TCP_TABLE(5)                                                                   TCP_TABLE(5)
 </​code>​ </​code>​
-Ob der im Einsatz befindliche Postfix diese Tabellen unterstützt,​ können wir wie folgt abfragen.+Ob der im Einsatz befindliche Postfix diese //​**TCP**//​-Lookup-Tabellen unterstützt,​ können wir wie folgt abfragen.
    # postconf -d | grep mail_version && postconf -m    # postconf -d | grep mail_version && postconf -m
  
Zeile 405: Zeile 405:
    # systemctl status postsrsd    # systemctl status postsrsd
  
-<​code>​postsrsd.service - PostSRSd Daemon +<html><​pre class="​code">​ 
-   ​Loaded: ​loaded ​(/​usr/​lib/​systemd/​system/​postsrsd.service;​ enabled) +<font style="​color:​ rgb(0, 255, 0)"><​b>​● </​b></​font>​postsrsd.service - PostSRSd Daemon 
-   ​Active:​ active (running) since Wed 2014-12-03 14:39:49 CET; 2s ago+   ​Loaded: ​oaded (/​usr/​lib/​systemd/​system/​postsrsd.service;​ enabled) 
 +   ​Active: ​<font style="​color:​ rgb(0, 255, 0)"><​b>​active (running)</​b></​font>​since Wed 2014-12-03 14:39:49 CET; 2s ago
  Main PID: 29588 (postsrsd)  Main PID: 29588 (postsrsd)
    ​CGroup:​ /​system.slice/​postsrsd.service    ​CGroup:​ /​system.slice/​postsrsd.service
Zeile 413: Zeile 414:
  
 Dec 03 14:39:49 vml000087.dmz.nausch.org systemd[1]: Starting PostSRSd Daemon... Dec 03 14:39:49 vml000087.dmz.nausch.org systemd[1]: Starting PostSRSd Daemon...
-Dec 03 14:39:49 vml000087.dmz.nausch.org systemd[1]: Started PostSRSd Daemon. +Dec 03 14:39:49 vml000087.dmz.nausch.org systemd[1]: Started PostSRSd Daemon.</​font>​ 
-</code>+</​pre>​ 
 +</html>
  
 In der Prozessliste finden wir mindestens einen neuen Prozess, der gestartet wurde. In der Prozessliste finden wir mindestens einen neuen Prozess, der gestartet wurde.
Zeile 421: Zeile 423:
    ​nobody ​  ​29588 ​ 0.0  0.0   ​6420 ​  740 ?        Ss   ​14:​39 ​  0:00 /​usr/​sbin/​postsrsd -f10001 -r10002 -dnausch.org -s/​etc/​postsrsd.secret -unobody -c/​var/​lib/​postsrsd -Xpgp.guru    ​nobody ​  ​29588 ​ 0.0  0.0   ​6420 ​  740 ?        Ss   ​14:​39 ​  0:00 /​usr/​sbin/​postsrsd -f10001 -r10002 -dnausch.org -s/​etc/​postsrsd.secret -unobody -c/​var/​lib/​postsrsd -Xpgp.guru
  
-Mittels **netstat** können wir überpfüfen, ob die beiden Ports 10001 und 10002 geöffnet wurden. ​+Mittels **netstat** können wir überprüfen, ob die beiden Ports 10001 und 10002 geöffnet wurden. ​
    # netstat -tulpen | grep 1000    # netstat -tulpen | grep 1000
  
Zeile 427: Zeile 429:
    ​tcp ​       0      0 127.0.0.1:​10002 ​        ​0.0.0.0:​* ​              ​LISTEN ​     0          290003 ​    ​29588/​postsrsd    ​tcp ​       0      0 127.0.0.1:​10002 ​        ​0.0.0.0:​* ​              ​LISTEN ​     0          290003 ​    ​29588/​postsrsd
  
-Läuft unser Daemon kann mit Hilfe von **lsof** sehen wir nicht nur den geöffneten ​port, sondern auch die Verbindungen die dort anliegen.+Läuft unser Daemon kann mit Hilfe von **lsof** sehen wir nicht nur den geöffneten ​Port, sondern auch die Verbindungen die dort anliegen.
    # lsof -i :10001    # lsof -i :10001
  
  • centos/mail_c7/spam_11.txt
  • Zuletzt geändert: 28.01.2019 11:17.
  • von django