Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
centos:mail_c7:spam_11 [03.12.2014 13:47. ] – [SRS-Deamon] djangocentos:mail_c7:spam_11 [25.11.2022 16:35. ] (aktuell) – [erster manueller Start] django
Zeile 1: Zeile 1:
-<WRAP center round info 60%> 
-Artikel befindet sich gerade in der Bearbeitung! 
-</WRAP> 
 ====== 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_c6:mta_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**.
  
-<uml w=900> +<uml>
 title Mailversand einer eMail bei Weiterleitung (alias)\n title Mailversand einer eMail bei Weiterleitung (alias)\n
-skin BlueModern+
 participant "\n Mail-Server mx1.example.org \n 88.217.127.21 \n" as links participant "\n Mail-Server mx1.example.org \n 88.217.127.21 \n" as links
 participant "\n Mail-Server mx01.nausch.org \n 217.91.103.190 \n" as mitte participant "\n Mail-Server mx01.nausch.org \n 217.91.103.190 \n" as mitte
Zeile 51: Zeile 47:
 </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 57: Zeile 53:
 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 152: Zeile 148:
                                                                   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 406: Zeile 402:
  
 Den erfolgreichen Start bzw. den Status des **postsrsd**-Daemon können wir bei Bedarf mit folgendem Aufruf abfragen. Den erfolgreichen Start bzw. den Status des **postsrsd**-Daemon können wir bei Bedarf mit folgendem Aufruf abfragen.
-   # +   # systemctl status postsrsd 
 + 
 +<html><pre class="code"> 
 +<font style="color: rgb(0, 255, 0)"><b>● </b></font>postsrsd.service - PostSRSd Daemon 
 +   Loaded: loaded (/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) 
 +   CGroup: /system.slice/postsrsd.service 
 +           └─29588 /usr/sbin/postsrsd -f10001 -r10002 -dnausch.org -s/etc/postsrsd.secret -unobody -c/var/lib/postsrsd -Xpgp.guru 
 + 
 +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.</font> 
 +</pre> 
 +</html> 
 + 
 +In der Prozessliste finden wir mindestens einen neuen Prozess, der gestartet wurde. 
 +   # ps aux | grep postsrsd 
 + 
 +   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 überprüfen, ob die beiden Ports 10001 und 10002 geöffnet wurden.  
 +   # netstat -tulpen | grep 1000 
 + 
 +   tcp        0      0 127.0.0.1:10001         0.0.0.0:              LISTEN      0          290001     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. 
 +   # lsof -i :10001 
 + 
 +  COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME 
 +  postsrsd 6170  nobody    5u  IPv4 574244      0t0  TCP localhost:scp-config (LISTEN) 
 +  postsrsd 7151  nobody    5u  IPv4 574244      0t0  TCP localhost:scp-config (LISTEN) 
 +  cleanup  7299 postfix   22u  IPv4 583245      0t0  TCP localhost:43341->localhost:scp-config (ESTABLISHED) 
 +  postsrsd 7300  nobody    0u  IPv4 583246      0t0  TCP localhost:scp-config->localhost:43341 (ESTABLISHED) 
 +  postsrsd 7300  nobody    5u  IPv4 574244      0t0  TCP localhost:scp-config (LISTEN) 
 +  postsrsd 7301  nobody    5u  IPv4 574244      0t0  TCP localhost:scp-config (LISTEN) 
 + 
 +   # lsof -i :10002 
 + 
 +  postsrsd 6170  nobody    6u  IPv4 574246      0t0  TCP localhost:documentum (LISTEN) 
 +  smtpd    7146 postfix   40u  IPv4 582010      0t0  TCP localhost:57592->localhost:documentum (ESTABLISHED) 
 +  postsrsd 7151  nobody    0u  IPv4 582011      0t0  TCP localhost:documentum->localhost:57592 (ESTABLISHED) 
 +  postsrsd 7151  nobody    6u  IPv4 574246      0t0  TCP localhost:documentum (LISTEN) 
 +  cleanup  7299 postfix   23u  IPv4 583248      0t0  TCP localhost:57652->localhost:documentum (ESTABLISHED) 
 +  postsrsd 7300  nobody    6u  IPv4 574246      0t0  TCP localhost:documentum (LISTEN) 
 +  postsrsd 7301  nobody    0u  IPv4 583249      0t0  TCP localhost:documentum->localhost:57652 (ESTABLISHED) 
 +  postsrsd 7301  nobody    6u  IPv4 574246      0t0  TCP localhost:documentum (LISTEN) 
 + 
 +==== automatisches Starten des Dienste beim Systemstart ==== 
 +Damit der Daemon automatisch beim Hochfahren des Servers gestartet wird, nutzen wir folgenden Aufruf.  
 +   # systemctl enable postsrsd.service 
 + 
 +   ln -s '/usr/lib/systemd/system/postsrsd.service' '/etc/systemd/system/multi-user.target.wants/postsrsd.service' 
 + 
 +Wollen wir überprüfen ob der Dienst automatisch startet, verwenden wir folgenden Aufruf.  
 +   # systemctl is-enabled postsrsd.service 
 + 
 +   enabled 
 + 
 +Die Rückmeldung **enabled** zeigt an, dass der Dienst automatisch startet; ein **disabled** zeigt entsprechend an, dass der Dienst __nicht__ automatisch startet. 
 + 
 +===== Umschreibungen / Logging ===== 
 +Im Maillog unseres Mailservers werden die Umschreibungen entsprechend dokumentiert. 
 +   # less /var/log/maillog 
 + 
 +  Dec 3 19:01:59 vml000080 postsrsd[5806]: srs_forward: <honeypot_for_spam@web.de> rewritten as <SRS0+BaCI=YT=web.de=honeypot_for_spam@nausch.org> 
 + 
 +Im Header zugestellten eMail beim Empfänger wird dies auch im **Return-Path**hinterlegt. 
 +  Return-Path: <SRS0+BaCI=YT=web.de=honeypot_for_spam@nausch.org>
  
 +Bounced das Zielsystem die Nachricht, weil dieses z.B. die Nachricht wegen einer vollen Mailbox nicht zustellen kann, kann das relayende System nun problemlos den eigentlichen Absender informieren, da der **PostSRSd** die Zieladresse wieder ermitteln und umschreiben (**srs_reverse**) kann.
  
 +  Dec 3 23:23:23 vml000080 postsrsd[6883]: srs_reverse: <SRS0+bCev=YT=web.de=honeypot_for_spam@nausch.org> rewritten as <honeypot_for_spam@web.de>
 +  ...
 +  ...
 +  Dec 8 12:42:23 vml000080 postfix/smtp[6884]: 8413383: to=<honeypot_for_spam@web.de>, orig_to=<SRS0+bCev=YT=web.de=honeypot_for_spam@nausch.org>, relay=mx-ha03.web.de[213.165.67.104]:25, delay=0.75, delays=0.06/0/0.41/0.29, dsn=2.0.0, status=sent (250 Requested mail action okay, completed: id=0LtrOf-1X9H7q3CS5-011BDN)
  
 +====== Links ======
 +  * **⇐ [[centos:mail_c7:spam_10|Zurück zum Kapitel "SPF - Sender Policy Framework unter CentOS 7.x"]]**
 +  * **⇒ [[centos:mail_c7:spam_12|Weiter zum Kapitel "DMARC - Domain-based Message Authentication, Reporting & Conformance unter CentOS 7.x"]]**
 +  * **[[centos:mail_c7:start|Zurück zum Kapitel >>Mailserverinstallation unter CentOS 7<<]]**
 +  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**
 +  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
  
  
  
  
  • centos/mail_c7/spam_11.1417614472.txt.gz
  • Zuletzt geändert: 03.12.2014 13:47.
  • von django