centos:mail_c7:spam_3

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_3 [10.11.2014 19:53. ] – [main.cf] djangocentos:mail_c7:spam_3 [22.07.2019 15:02. ] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 4: Zeile 4:
 Damit der erwünschte MTA zu MTA Verkehr bestmöglichst nicht eingeschränkt wird, pflegt der postscreen Daemon eine eigene temporäre Whitelist, in die er alle Clients einträgt, die die postscreen Prüfungen bereits bestanden haben. Damit der erwünschte MTA zu MTA Verkehr bestmöglichst nicht eingeschränkt wird, pflegt der postscreen Daemon eine eigene temporäre Whitelist, in die er alle Clients einträgt, die die postscreen Prüfungen bereits bestanden haben.
  
-Die Hauptaufgabe, bzw. wie Wietse es sagt "..die größte Herausforderung" von postscreen ist es mit nur einer Bewertung herauszufinden, ob es sich um einen SPAMer handelt oder nicht. Dies ist vorallem dadurch notwendig, da viele Zombiesysteme versuchen, möglichst unerkannt SPAM zu versenden und dadurch vermeiden große Mengen an einem Host einzuliefern. Bewertet postscreen den Zustellversuch als HAM, also als erwünschten Verkehr, so merkt er sich diesen Host in seiner temporären Whitelist und vermeidet so weitere Verzögerungen bei legitimen Verkehr. Eine weitere Herausforderung von SPAM versendenden Systemen ist die begrenzte Zeit, bevor die betroffenen IP-Adressen auf Blacklisten erscheinen, die zur Verfügung steht um SPAM zu verschicken. Daher sind viele SPAM-clients daruaf getrimmt, möglichst schnell ihre Post loszuwerden. Sie ignorieren daher sehr oft richtige SMTP-Implementierungen, legen mit der Übertragung sofort nach dem Connect los oder ignorieren Rückmeldungen des Empfangssystems. All dies macht sich postscreen zu nutze!+Die Hauptaufgabe, bzw. wie Wietse es sagt "..die größte Herausforderung" von postscreen ist es mit nur einer Bewertung herauszufinden, ob es sich um einen SPAMer handelt oder nicht. Dies ist vor allem dadurch notwendig, da viele Zombie-Systeme versuchen, möglichst unerkannt SPAM zu versenden und dadurch vermeiden große Mengen an einem Host einzuliefern. Bewertet postscreen den Zustellversuch als HAM, also als erwünschten Verkehr, so merkt er sich diesen Host in seiner temporären Whitelist und vermeidet so weitere Verzögerungen bei legitimen Verkehr. Eine weitere Herausforderung von SPAM versendenden Systemen ist die begrenzte Zeit, bevor die betroffenen IP-Adressen auf Blacklisten erscheinen, die zur Verfügung steht um SPAM zu verschicken. Daher sind viele SPAM-Clients darauf getrimmt, möglichst schnell ihre Post loszuwerden. Sie ignorieren daher sehr oft richtige SMTP-Implementierungen, legen mit der Übertragung sofort nach dem Connect los oder ignorieren Rückmeldungen des Empfangssystems. All dies macht sich postscreen zu nutze!
  
-Zur Erkennung von Zombies nutzt der Postscreen Daemon verschiedene Techniken. So prüft der Daemon erst mal, ob der Client auf einer Blacklist gelistet ist. Dabei kann er verschiedene Listen befragen und entsprechend deren Gewichtung eine Entscheidung treffen. Desweiteren prüft postscreen, ob der Client RFC-konform arbeitet, oder ob der Client ungefragt loslegt bevor der SMTP-Daemon sich richtig gemeldet hat. Bereits diese beiden Prüfungen reichen aus, um eine erste Entscheidung auf HAM oder SPAM zu treffen.+Zur Erkennung von Zombies nutzt der Postscreen Daemon verschiedene Techniken. So prüft der Daemon erst mal, ob der Client auf einer Blacklist gelistet ist. Dabei kann er verschiedene Listen befragen und entsprechend deren Gewichtung eine Entscheidung treffen. Des weiteren prüft postscreen, ob der Client RFC-konform arbeitet, oder ob der Client ungefragt loslegt bevor der SMTP-Daemon sich richtig gemeldet hat. Bereits diese beiden Prüfungen reichen aus, um eine erste Entscheidung auf HAM oder SPAM zu treffen.
  
 ===== manpage ===== ===== manpage =====
Zeile 437: Zeile 437:
 ==== erste Schnelltests ==== ==== erste Schnelltests ====
 === black- & whitelist === === black- & whitelist ===
-Einen der ersten tests, die **postscreen** anstellt ist die Prüfung der Clien-IP-Adresse auf Eintrag eines Eintrags in der Black-/White-Liste. Der Konfigurationsparameter hierzu lautet **postscreen_access_list**.+Einen der ersten Tests, die **postscreen** anstellt ist die Prüfung der Clien-IP-Adresse auf Eintrag eines Eintrags in der Black-/White-Liste. Der Konfigurationsparameter hierzu lautet **postscreen_access_list**.
  
 Wir tragen also einen Eintrag in unserer neuen Section **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** hierzu ein. Wir tragen also einen Eintrag in unserer neuen Section **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** hierzu ein.
Zeile 448: Zeile 448:
 </code> </code>
  
-Wir haben hier also alle Hosts aus **mynetworks** und eine zusätzliche Cidr-Tabelle **/etc/postfix/postscreen_whitelist** definiert.+Wir haben hier also alle Hosts aus **mynetworks** und eine zusätzliche cidr-Tabelle **/etc/postfix/postscreen_whitelist** definiert.
  
 Diese Datei legen wir gleich mal als nächstes an. Diese Datei legen wir gleich mal als nächstes an.
Zeile 455: Zeile 455:
 # access-Tabelle: Wer wird von postscreen ausgenommen und wer nicht? # access-Tabelle: Wer wird von postscreen ausgenommen und wer nicht?
 # Tabelle zum black- und whitelisten einzelner Hosts auf Basis ihrer  # Tabelle zum black- und whitelisten einzelner Hosts auf Basis ihrer 
-# IP-Adressen. In der rechten Tabellenspalte können die AKtionen +# IP-Adressen. In der rechten Tabellenspalte können die Aktionen 
 # "permit", "reject" und "dunno" gesetzt werden. # "permit", "reject" und "dunno" gesetzt werden.
-# Nach dem Ändern und/oder Erweitern der Tabelle, muß ein+# Nach dem Ändern und/oder Erweitern der Tabelle, muss ein
 # laufender Postfix über die Änderungen mit einem reload informiert  # laufender Postfix über die Änderungen mit einem reload informiert 
 # werden:  # werden: 
Zeile 473: Zeile 473:
 </file> </file>
 In der rechten Tabellenspalte können folgende drei Aktionen gesetzt werden: In der rechten Tabellenspalte können folgende drei Aktionen gesetzt werden:
-  * **permit** Es werden keine weiteren postscreen-Test durchgeführt. Die Verbindung wird sofort an einen SMTP-Daemon weitergereicht. +  * ''**permit**'' Es werden keine weiteren postscreen-Test durchgeführt. Die Verbindung wird sofort an einen SMTP-Daemon weitergereicht. 
-  * **dunno** Nichts weiter unternehmen und Client zum nächsten Test weiterreichen. +  * ''**dunno**'' Nichts weiter unternehmen und Client zum nächsten Test weiterreichen. 
-  * **reject** Client blacklisten und weitere Suche in der Tabelle beenden. Abhängig vom Parameter **postscreen_blacklist_action** mit der weiteren Bearbeitung der Clientverbindung verfahren.+  * ''**reject**'' Client blacklisten und weitere Suche in der Tabelle beenden. Abhängig vom Parameter **postscreen_blacklist_action** mit der weiteren Bearbeitung der Clientverbindung verfahren.
  
 Den Parameter **postscreen_blacklist_action** definieren wir nun als nächsten. Den Parameter **postscreen_blacklist_action** definieren wir nun als nächsten.
Zeile 485: Zeile 485:
  
 Hier stehen uns drei Aktionen zur Verfügung: Hier stehen uns drei Aktionen zur Verfügung:
-  * **ignore** Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**ignore**'' Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **enforce** Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschliessen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**enforce**'' Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschließen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **drop** Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.+  * ''**drop**'' Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
 + 
 +\\  
 +<WRAP center round important 100%> 
 +Natürlich kann die Pflege von einzelnen Systemen zu einer sehr zeitaufwändigen Arbeit ausarten, vor allem dann wenn Versendende Systeme großer Mailprovider oder besonderer geclusteter Mailserver zum Einsatz kommen. Werden Mails von Servern unterschiedlicher abwechselnd von unterschiedlichen Mailrelays mit unterschiedlichen IP-Adresssen verschickt, wird die Nutzung von Postscreen so ad absurdum geführt, insbesondere dann wenn man die [[#post_220_smtp_server_greeting_tests|Post 220 SMTP Server Greeting Tests]] nutzen möchte.  
 + 
 +<WRAP center round tip 100%> 
 +Eine manuelle Pflege der **postscreen_access_list** ist hier nicht mehr praxisgerecht. Statt nun auf die Nutzung der Funktion **postscreen_access_list** zu verzichten, ist die Nutzung einer automatisch gepflegten Access-Liste mit Hilfe von **[[centos:mail_c7:spam_3|postwhite]]** vorzuziehen! 
 +</WRAP> 
 + 
 +</WRAP> 
 + 
 + 
  
 === temporäre whitelist === === temporäre whitelist ===
Zeile 517: Zeile 530:
 Mit der Option **postscreen_whitelist_interfaces** kann man definieren, auf welchen Interfaces/IP-Adressen das automatische Setzen der Whitelist aktiviert und eben deaktiviert werden soll. Die eben angesprochene Standardoption zeigt auf **//static:all//**, also auf alle zur verfügung stehenden IP-Adressen. Mit der Option **postscreen_whitelist_interfaces** kann man definieren, auf welchen Interfaces/IP-Adressen das automatische Setzen der Whitelist aktiviert und eben deaktiviert werden soll. Die eben angesprochene Standardoption zeigt auf **//static:all//**, also auf alle zur verfügung stehenden IP-Adressen.
  
-Wenn wir nun eine weitere IP-Adresse auf unserem Mailserver binden und im DNS als Backup-MX definieren, können wir quasi einen Pseudo-Backup-MX mimen. Schlägt dann ein Client immer nur bzw. zuerst auf der IP-Adresse des definierten Backup-MX auf, dann ist dies höchstwahrscheinlich ein SPAM-Bot. Solch einen Client wollen wir __definitiv nicht__ bertrauen, sondern diesen immer durch alle Postscreen-Test schicken. Dies erreichen wir mit folgender Konfigurationsoptiom, die wir nun in der Sektion **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** anfügen.+Wenn wir nun eine weitere IP-Adresse auf unserem Mailserver binden und im DNS als Backup-MX definieren, können wir quasi einen Pseudo-Backup-MX mimen. Schlägt dann ein Client immer nur bzw. zuerst auf der IP-Adresse des definierten Backup-MX auf, dann ist dies höchstwahrscheinlich ein SPAM-Bot. Solch einen Client wollen wir __definitiv nicht__ vertrauen, sondern diesen immer durch alle Postscreen-Test schicken. Dies erreichen wir mit folgender Konfigurationsoptiom, die wir nun in der Sektion **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** anfügen.
    # vim /etc/postfix/main.cf    # vim /etc/postfix/main.cf
  
Zeile 528: Zeile 541:
 </code> </code>
  
-Der Eintrag definiert nun, dass das Eintragen in die automatische temporäre Whitelist af allen IP-Adressen/Interfaces erfolgen soll, aber **__nicht__** auf der IP-Adresse **88.217.171.167**!+Der Eintrag definiert nun, dass das Eintragen in die automatische temporäre Whitelist auf allen IP-Adressen/Interfaces erfolgen soll, aber **__nicht__** auf der IP-Adresse **88.217.171.167**!
  
 <WRAP center round important> <WRAP center round important>
Zeile 536: Zeile 549:
 Konfigurationsbeispiel Konfigurationsbeispiel
   - **memcached** installieren, konfigurieren und starten. <code> # yum install memcached -y</code> <code> # vim /etc/sysconfig/memcached</code> <code> # systemctl start memcached</code>   - **memcached** installieren, konfigurieren und starten. <code> # yum install memcached -y</code> <code> # vim /etc/sysconfig/memcached</code> <code> # systemctl start memcached</code>
-  - Auf jeden MX-Host in der //**/etc/postfix.main.cf**// eintragen unter der Section **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** :<code>postscreen_cache_map = memcache:/etc/postfix/postscreen_cache +  - Auf jeden MX-Host in der **// /etc/postfix/main.cf //** eintragen unter der Section **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** :<code>postscreen_cache_map = memcache:/etc/postfix/postscreen_cache 
-proxy_write_maps = proxy:btree:/var/lib/postfix/postscreen_cache </code> Ferner legen wir die zusätzliche Konfigurationsdatei //**/etc/postfix/postscreen_cache**// an.<code># Django : 2014-11-07 postscreen-cache Konfigurationsdatei+proxy_write_maps = proxy:btree:/var/lib/postfix/postscreen_cache </code> Ferner legen wir die zusätzliche Konfigurationsdatei **// /etc/postfix/postscreen_cache //** an.<code># Django : 2014-11-07 postscreen-cache Konfigurationsdatei
 # #
 memcache = inet:217.91.103.190:11211 memcache = inet:217.91.103.190:11211
Zeile 546: Zeile 559:
 Nach diesen ersten Schnelltests für der Postscreen-Daemon noch weitere Tests aus, die man in zwei Gruppen einteilen kann, die wir uns nun noch ansehen und konfigurieren werden. Nach diesen ersten Schnelltests für der Postscreen-Daemon noch weitere Tests aus, die man in zwei Gruppen einteilen kann, die wir uns nun noch ansehen und konfigurieren werden.
  
-==== Vor "220 SMTP Server Greeting" Tests ====+==== "Pre 220 SMTP Server Greeting" Tests ====
 Die zweite Gruppe an Tests führt Postscreen aus, noch bevor der SMTP-Daemon die initiale Begrüßung **"220 ... ESMTP Postfix"** an den Client sendet. Die kurze Verzögerung, meist im Bereich von Sekunden, wird über den Parameter **postscreen_greet_wait** gesteuert. Besteht der Client diese //Vor "220 SMTP Server Greeting" Tests//, erhält der Client einen Eintrag in der **temp. whitelisting Tabelle** und die aktuelle Verbindung wird vom postscreen-Daemon sofort an einen SMTP-Daemon weitergereicht, der mit der weiteren Annahme und Bewertung der Sendung  fortfahren kann.  Die zweite Gruppe an Tests führt Postscreen aus, noch bevor der SMTP-Daemon die initiale Begrüßung **"220 ... ESMTP Postfix"** an den Client sendet. Die kurze Verzögerung, meist im Bereich von Sekunden, wird über den Parameter **postscreen_greet_wait** gesteuert. Besteht der Client diese //Vor "220 SMTP Server Greeting" Tests//, erhält der Client einen Eintrag in der **temp. whitelisting Tabelle** und die aktuelle Verbindung wird vom postscreen-Daemon sofort an einen SMTP-Daemon weitergereicht, der mit der weiteren Annahme und Bewertung der Sendung  fortfahren kann. 
 <WRAP center round tip 90%> \\  <WRAP center round tip 90%> \\ 
Zeile 557: Zeile 570:
 Dann wartet der Server die mit Paramater **postscreen_greet_wait** definierte Zeit ab und sendet dann erst den richtigen greeter. Dann wartet der Server die mit Paramater **postscreen_greet_wait** definierte Zeit ab und sendet dann erst den richtigen greeter.
    220 mx01.nausch.org ESMTP Postfix    220 mx01.nausch.org ESMTP Postfix
-Erst hier beginnt ein orgnungsgemäßer konfigurierter Mailserver/Client mit dem Dialog. SPAM-Bots/-Zombies hingegen legen meist sofort los und senden nach der ersten Zeile bereits ihren **HELO/EHLO**, schließlich wollen diese ja in der kurzen Zeit bist die IP-Adresse auf einer Blocklist landet, möglichst viel SPAM versenden. Der postscreen Daemon erkennt dies und führt abhängig vom Parameter **postscreen_greet_action** die gewählte Aktion aus: +Erst hier beginnt ein ordnungsgemäßer konfigurierter Mailserver/Client mit dem Dialog. SPAM-Bots/-Zombies hingegen legen meist sofort los und senden nach der ersten Zeile bereits ihren **HELO/EHLO**, schließlich wollen diese ja in der kurzen Zeit bist die IP-Adresse auf einer Blocklist landet, möglichst viel SPAM versenden. Der postscreen Daemon erkennt dies und führt abhängig vom Parameter **postscreen_greet_action** die gewählte Aktion aus: 
-  * **ignore** Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**ignore**'' Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **enforce** Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschliessen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**enforce**'' Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschließen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **drop** Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.+  * ''**drop**'' Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
  
 === DNSBL-Abfragen und DNSWL-Abfragen === === DNSBL-Abfragen und DNSWL-Abfragen ===
Zeile 608: Zeile 621:
  
 Der Parameter **postscreen_dnsbl_threshold** legt fest, ab welcher Punktezahl, in unserem Konfigurationsbeispiel also beim Erreichen des Wertes **2**, der postscreen-Daemon tätig werden soll. Dabei stehen uns folgende Aktionen zur Verfügung: Der Parameter **postscreen_dnsbl_threshold** legt fest, ab welcher Punktezahl, in unserem Konfigurationsbeispiel also beim Erreichen des Wertes **2**, der postscreen-Daemon tätig werden soll. Dabei stehen uns folgende Aktionen zur Verfügung:
-  * **ignore** Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**ignore**'' Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **enforce** Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschliessen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**enforce**'' Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschliessen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **drop** Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.+  * ''**drop**'' Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
  
  
 ==== "Post 220 SMTP Server Greeting" Tests ==== ==== "Post 220 SMTP Server Greeting" Tests ====
-In der dritten und letzten Phase kann postscreen mit seiner internen SMTP-Engine sog. **deep protocol Tests** anstellen. Diese Tests sind weitaus tiefergehender im SMTP-Protokoll und unterscheiden sich damit wesentlich von den **//"Pre 220 SMTP Server Greeting-"//** und den **//DNSBL-Tests//**. Eine wesentliche Einschränkung gibt es bei den **//"Post 220 SMTP Server Greeting"//** Tests, der nicht verschwiegen werden sollte. Ein bisher unbekannter Client muss nach dem erfolgreichen Bestehen der Tests erneut mit dem MX verbinden, da der postscreen-Daemon den bestehenden und bereits begonnenen SMTP-Dialog nicht an einen "richtige" SMTP-Daemon weiterreichen kann. Postscreen ist kein SMTP-Proxy! Daher muss sich der Client, erneut und hoffentlich mit der gleichen IP-Adresse erneut melden. +In der dritten und letzten Phase kann postscreen mit seiner internen SMTP-Engine sog. **deep protocol Tests** anstellen. Diese Tests sind weitaus tiefer gehender im SMTP-Protokoll und unterscheiden sich damit wesentlich von den **//"Pre 220 SMTP Server Greeting-"//** und den **//DNSBL-Tests//**. Eine wesentliche Einschränkung gibt es bei den **//"Post 220 SMTP Server Greeting"//** Tests, der nicht verschwiegen werden sollte. Ein bisher unbekannter Client muss nach dem erfolgreichen Bestehen der Tests erneut mit dem MX verbinden, da der postscreen-Daemon den bestehenden und bereits begonnenen SMTP-Dialog nicht an einen "richtige" SMTP-Daemon weiterreichen kann. Postscreen ist kein SMTP-Proxy! Daher muss sich der Client, erneut und hoffentlich mit der gleichen IP-Adresse erneut melden, was natürlich zu einer gewissen Verzögerung bei der Mailannahme führen kann und wird. 
  
 <WRAP center round info> <WRAP center round info>
Zeile 622: Zeile 635:
   * **cache-sharing**: Bei größeren Installationen mit Hilfe von **memcached** unbedingt die caching-Daten mit einer groß bemessenen **[[http://www.postfix.org/memcache_table.5.html|memcache_table]]** teilen! Deteils hierzu sind bereits beim Punkt **[[centos:mail_c7:spam_3?&#mx_policy_test|MX Policy Test]]** beschrieben.   * **cache-sharing**: Bei größeren Installationen mit Hilfe von **memcached** unbedingt die caching-Daten mit einer groß bemessenen **[[http://www.postfix.org/memcache_table.5.html|memcache_table]]** teilen! Deteils hierzu sind bereits beim Punkt **[[centos:mail_c7:spam_3?&#mx_policy_test|MX Policy Test]]** beschrieben.
   * **25**: die SMTP-Engine von Postscreen unterstützt weder AUTH, XCLIENT noch XFORWARD Funktionen! Werden diese Funktionen auf Port **25** benötigt, dann scheidet der Einsatz der **//"Post 220 SMTP Server Greeting"//**-Tests leider aus.   * **25**: die SMTP-Engine von Postscreen unterstützt weder AUTH, XCLIENT noch XFORWARD Funktionen! Werden diese Funktionen auf Port **25** benötigt, dann scheidet der Einsatz der **//"Post 220 SMTP Server Greeting"//**-Tests leider aus.
-  * **Submission**: MUAs wird ausschließlich der Submisssion-port **587** zum Einliefern der Nachrichten angeboten. So können diese gezielt die postscreen-tests umgehen.+  * **Submission**: MUAs wird ausschließlich der Submisssion-port **587** zum Einliefern der Nachrichten angeboten. So können diese gezielt die postscreen Tests umgehen. 
 + 
 +<WRAP center round important 80%> 
 +Stellt man auf produktiv im Einsatz befindlichen Mailservern den zusätzlichen Gewinn bei der SPAM-Abwehr durch Nutzung der **[[#post_220_smtp_server_greeting_tests|"Post 220 SMTP Server Greeting" Tests]]** ins Verhältnis zu auftretenden Mailverzögerungen, muss man sich natürlich die Frage stellen, ob hier noch der Aufwand lohnt.  
 + 
 +In den __seltensten Fällen__ wird man daher wirklich diese Funktion nutzen wollen! 
 +</WRAP> 
 </WRAP> </WRAP>
  
Zeile 633: Zeile 653:
  
 === "Command Pipelining" Tests === === "Command Pipelining" Tests ===
-Standardmäßig ist ein SMTP-Halbduplex-Protokoll, d.h. der Sender wie auch der Empfänger sendet immer einen Befehl ein Befehl bzw. eine Antwort und wartet dann auf eine Bestätigung/Antwort von der Gegenseite. Die Postscreen interne SMTP-Engine unterdrückt das ESMTP-Kommando **Pipelining**; d.h. Pipelining wird nicht angeboten. Setzt man nun die Option **postscreen_pipelining_enable = //yes//**, so erkenmnt postscreen Mail-Zombies, die Protokollwidrig trotzdem versuchen mehrere befehle auf einmal zu senden.+Standardmäßig ist ein SMTP-Halbduplex-Protokoll, d.h. der Sender wie auch der Empfänger sendet immer einen Befehl ein Befehl bzw. eine Antwort und wartet dann auf eine Bestätigung/Antwort von der Gegenseite. Die Postscreen interne SMTP-Engine unterdrückt das ESMTP-Kommando **Pipelining**; d.h. Pipelining wird nicht angeboten. Setzt man nun die Option **postscreen_pipelining_enable = //yes//**, so erkennt postscreen Mail-Zombies, die Protokollwidrig trotzdem versuchen mehrere befehle auf einmal zu senden.
  
 Wir tragen also einen Eintrag in unserer neuen Section **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** hierzu ein. Wir tragen also einen Eintrag in unserer neuen Section **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** hierzu ein.
Zeile 643: Zeile 663:
  
 Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung: Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung:
-  * **ignore** Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**ignore**'' Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **enforce** Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschliessen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**enforce**'' Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschließen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **drop** Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.+  * ''**drop**'' Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
  
  
Zeile 661: Zeile 681:
  
 Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung: Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung:
-  * **ignore** Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**ignore**'' Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **enforce** Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschliessen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**enforce**'' Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschließen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **drop** Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.+  * ''**drop**'' Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
  
 === "Bare Newline" Tests === === "Bare Newline" Tests ===
-SMTP ist eine zeilenorientierte Protokoll, d.h. jede gesendete Zeile hat eine begrenzte Länge und wirden mit **<CR> <LF>** abgeschlossen. Zeile, die nur mit einem **<LF>**, also einem fehlenden **<CR>**, abgeschlossen sind, sind laut dem SMTP-Protokoll nicht erlaubt. Viele SPAM-Bots machen aber gerade diese Protokollverstöße. Somit kann Postscreen diese Protokollanomalie erkennen und ja nach Konfiguration eine Entscheidung treffen.+SMTP ist eine zeilenorientierte Protokoll, d.h. jede gesendete Zeile hat eine begrenzte Länge und wird mit **<CR> <LF>** abgeschlossen. Zeile, die nur mit einem **<LF>**, also einem fehlenden **<CR>**, abgeschlossen sind, sind laut dem SMTP-Protokoll nicht erlaubt. Viele SPAM-Bots machen aber gerade diese Protokollverstöße. Somit kann Postscreen diese Protokollanomalie erkennen und ja nach Konfiguration eine Entscheidung treffen.
  
 Wir tragen also einen Eintrag in unserer neuen Section **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** hierzu ein. Wir tragen also einen Eintrag in unserer neuen Section **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** hierzu ein.
Zeile 678: Zeile 698:
  
 Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung: Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung:
-  * **ignore** Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**ignore**'' Nichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **enforce** Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschliessen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren. +  * ''**enforce**'' Weitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode **550** abschliessen. Die Informationen //HELO//, //SENDER// und //EMPFÄNGER// werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren. 
-  * **drop** Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbinung mit der gleichen IP ebenso verfahren.+  * ''**drop**'' Die Verbindung sofort mit einem SMTP-Fehlercode **521** beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
  
  
Zeile 690: Zeile 710:
  
 ==== main.cf ==== ==== main.cf ====
 +Im Gesamten ergibt sich nun folgende Section **POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN** in unserer Konfigurationsdatei //**/etc/postfix/main.cf**//
 <code bash>... <code bash>...
  
Zeile 736: Zeile 757:
 # #
 # default: postscreen_pipelining_enable = no # default: postscreen_pipelining_enable = no
-postscreen_pipelining_enable = yes 
 # #
 # default: postscreen_pipelining_action = enforce # default: postscreen_pipelining_action = enforce
 # #
 # default: postscreen_non_smtp_command_enable = no # default: postscreen_non_smtp_command_enable = no
-postscreen_non_smtp_command_enable = yes+#
 # default: postscreen_non_smtp_command_action = drop # default: postscreen_non_smtp_command_action = drop
 # #
 # default: postscreen_bare_newline_enable = no # default: postscreen_bare_newline_enable = no
-postscreen_bare_newline_enable = yes 
 # #
 # default: postscreen_bare_newline_action = ignore # default: postscreen_bare_newline_action = ignore
-postscreen_bare_newline_action = drop 
 # #
 </code> </code>
  
 ==== master.cf ==== ==== master.cf ====
 +Zum Aktivieren unseres Postscreen-Daemon aktivieren wir nun den bereits vorgesehenen Eintrag zu Postscreen bzw. tragen diese nach:
  
    # vim /etc/postfix/master.cf    # vim /etc/postfix/master.cf
Zeile 771: Zeile 790:
 smtp      inet  n       -       n       -       1       postscreen smtp      inet  n       -       n       -       1       postscreen
 smtpd     pass  -       -       n       -       -       smtpd smtpd     pass  -       -       n       -       -       smtpd
 +  -o smtpd_sasl_auth_enable=no
 dnsblog   unix  -       -       n       -       0       dnsblog dnsblog   unix  -       -       n       -       0       dnsblog
 tlsproxy  unix  -       -       n       -       0       tlsproxy tlsproxy  unix  -       -       n       -       0       tlsproxy
Zeile 778: Zeile 798:
  
 ===== Aktivierung ===== ===== Aktivierung =====
 +Zur Aktivierung unserer Konfigurationsänderungen führen wir nun noch einen Restart des Postfix-Master DAemon durch.
 +   # systemctl restart postfix
 +
 +Den Serverstatus können wir uns nun mit Hilfe des folgenden Aufrufes anzeigen lassen.
 +   # systemctl status postfix
 +
 +<html><pre class="code">
 +<font style="color: rgb(0, 255, 0)"><b>● </b></font>postfix.service - Postfix Mail Transport Agent
 +   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
 +   Active: <font style="color: rgb(0, 255, 0)"><b>active (running)</b></font> since Mon 2014-11-10 20:57:24 CET; 18s ago
 +  Process: 15133 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
 +  Process: 15148 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
 +  Process: 15146 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
 +  Process: 15143 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
 + Main PID: 15221 (master)
 +   CGroup: /system.slice/postfix.service
 +           ├─15221 /usr/libexec/postfix/master -w
 +           ├─15222 pickup -l -t unix -u
 +           └─15223 qmgr -l -t unix -u
 +
 +Nov 10 20:57:23 vml000087.dmz.nausch.org systemd[1]: Starting Postfix Mail Transport Agent...
 +Nov 10 20:57:24 vml000087.dmz.nausch.org postfix/master[15221]: daemon started -- version 2.11.3, configuration /etc/postfix
 +Nov 10 20:57:24 vml000087.dmz.nausch.org systemd[1]: Started Postfix Mail Transport Agent.
 +</font>
 +</pre>
 +</html>
  
  
 ===== Bewertungsbeispiele ===== ===== Bewertungsbeispiele =====
 +==== Pass New ====
 +Folgender Auszug aus einem Maillog zeigt einen **neuen Client** der **alle Tests bestanden** hat.
 +<code>Nov  8 06:39:36 vml000080 postfix/postscreen[12580]: CONNECT from [66.220.144.178]:27747 to [10.0.0.80]:25
 +Nov  8 06:39:42 vml000080 postfix/postscreen[12580]: [66.220.144.178]27747: discarding EHLO keywords: DSN
 +Nov  8 06:39:43 vml000080 postfix/postscreen[12580]: [66.220.144.178]27747: discarding EHLO keywords: DSN
 +Nov  8 06:39:44 vml000080 postfix/postscreen[12580]: NOQUEUE: reject: RCPT from [66.220.144.178]:27747: 450 4.3.2 Service currently unavailable; from=<postmaster@facebookmail.com>, to=<dmarc-reports@nausch.org>, proto=ESMTP, helo=<mx-out.facebook.com>
 +Nov  8 06:39:49 vml000080 postfix/postscreen[12580]: PASS NEW [66.220.144.178]:27747
 +Nov  8 06:39:49 vml000080 postfix/postscreen[12580]: DISCONNECT [66.220.144.178]:27747
 +</code>
  
 +==== Reconnect ====
 +Folgender Auszug aus einem Maillog zeigt einen Reconnect eines bereits **bekannten Client**.
 +<code>Nov  8 16:24:29 vml000080 postfix/postscreen[23895]: CONNECT from [88.198.212.215]:49376 to [10.0.0.80]:25
 +Nov  8 16:24:29 vml000080 postfix/postscreen[23895]: PASS OLD [88.198.212.215]:49376
 +</code>
 +
 +==== Pregreet und DNSBL ====
 +Im folgendem Beispiel sehen wir gleich zwei Ergebnisse. Zum Einen hat der Client nicht abgewartet bis zum vollständigen Begrüßungscode und zum anderen wurde der Schwellwert für die gewichtete **DNSBL** von **2** erreicht.
 +<code>Nov  8 16:21:50 vml000080 postfix/postscreen[23895]: CONNECT from [36.224.135.17]:1900 to [10.0.0.80]:25
 +Nov  8 16:21:50 vml000080 postfix/postscreen[23895]: PREGREET 21 after 0.35 from [36.224.135.17]:1900: HELO 217.91.103.190\r\n
 +Nov  8 16:21:50 vml000080 postfix/postscreen[23895]: DNSBL rank 2 for [36.224.135.17]:1900
 +Nov  8 16:21:51 vml000080 postfix/postscreen[23895]: NOQUEUE: reject: RCPT from [36.224.135.17]:1900: 550 5.7.1 Service unavailable; client [36.224.135.17] blocked using zen.spamhaus.org; from=<z2007tw@yahoo.com.tw>, to=<vkihwpdh@yahoo.com.tw>, proto=SMTP, helo=<217.91.103.190>
 +Nov  8 16:21:51 vml000080 postfix/postscreen[23895]: HANGUP after 1 from [36.224.135.17]:1900 in tests after SMTP handshake
 +Nov  8 16:21:51 vml000080 postfix/postscreen[23895]: DISCONNECT [36.224.135.17]:1900
 +</code>
 +
 +==== Pregreet und COMMAND COUNT LIMIT ====
 +Bei folgendem Beispiel sehen wir wiederum einen Preegreet-Verstoß. Weiterhin sehen wir eine Überschreitung beim eingestellten **postscreen_command_count_limit** von **20**.
 +
 +<code>Nov  3 17:20:10 vml000080 postfix/postscreen[7924]: CONNECT from [50.31.146.101]:46294 to [10.0.0.80]:25
 +Nov  3 17:20:10 vml000080 postfix/postscreen[7924]: PREGREET 21 after 0.14 from [50.31.146.101]:46294: HELO vps.w21099.com\r\n
 +Nov  3 17:20:11 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@yahoo.com>, proto=SMTP, helo=<vps.w21099.com>
 +Nov  3 17:20:11 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@yahoo.com>, proto=SMTP, helo=<vps.w21099.com>
 +Nov  3 17:20:12 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@hotmail.com>, proto=SMTP, helo=<vps.w21099.com>
 +Nov  3 17:20:12 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@hotmail.com>, proto=SMTP, helo=<vps.w21099.com>
 +Nov  3 17:20:13 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<goomabox@gmail.com>, proto=SMTP, helo=<vps.w21099.com>
 +Nov  3 17:20:13 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<goomabox@gmail.com>, proto=SMTP, helo=<vps.w21099.com>
 +Nov  3 17:20:13 vml000080 postfix/postscreen[7924]: COMMAND COUNT LIMIT from [50.31.146.101]:46294 after MAIL
 +Nov  3 17:20:13 vml000080 postfix/postscreen[7924]: DISCONNECT [50.31.146.101]:46294
 +</code>
 +
 +==== BARE NEWLINE ====
 +Beim letzten Logging-Beispiel sehen wir, dass der Postscreen-Daemon bei einer bestehenden TLS-Session einen Bare Newline Verstoß entdeckt hatte.
 +
 +<code>Nov  9 17:59:25 vml000080 postfix/tlsproxy[1654]: CONNECT from [85.199.49.140]:40225
 +Nov  9 17:59:26 vml000080 postfix/tlsproxy[1654]: Anonymous TLS connection established from [85.199.49.140]:40225: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
 +Nov  9 17:59:58 vml000080 postfix/postscreen[1144]: BARE NEWLINE from [85.199.49.140]:40225 after quit
 +Nov  9 17:59:58 vml000080 postfix/postscreen[1144]: DISCONNECT [85.199.49.140]:40225
 +Nov  9 17:59:58 vml000080 postfix/tlsproxy[1654]: DISCONNECT [85.199.49.140]:40225
 +</code>
 +
 +==== weitere Beispiele ====
 +Weitere Beispiele zu **Postscreen** und dessen Loggingfunktionalitäten findet man auf der **[[http://www.postfix.org/POSTSCREEN_README.html|Seite]]** von Wietse Venema.
 +===== graphische Statistiken Postscreen  =====
 +Will man sich einen generellen Überblick über die Postscreen-Auswirkungen beim Mailverkehr informieren, greift man am besten auf [[centos:mail_c7:mta_13#mailgraph_nextgeneration|Mailgraph-NG]] zurück.
 +
 +{{ :centos:mail_c7:mailgraph-ng_06.png?direct&778 |BILD: Postscreen Statistik von Mailgraph-NG}}
 +
 +===== postwhite =====
 +<WRAP center round important 95%>
 +Natürlich kann die Pflege von einzelnen Systemen zu einer sehr zeitaufwändigen Arbeit ausarten, vor allem dann wenn versendende Systeme großer Mailprovider oder besonderer geclusteter Mailserver zum Einsatz kommen. Werden Mails von Servern unterschiedlicher abwechselnd von unterschiedlichen Mailrelays mit unterschiedlichen IP-Adresssen verschickt, wird die Nutzung der **[[spam_3#black-_whitelist|black- & whitelist Tests]]** von Postscreen so ad absurdum geführt, insbesondere dann wenn man die [[#post_220_smtp_server_greeting_tests|Post 220 SMTP Server Greeting Tests]] nutzen möchte. 
 +
 +<WRAP center round tip 80%>
 +Eine manuelle Pflege der **postscreen_access_list** ist hier nicht mehr praxisgerecht. Statt nun auf die Nutzung der Funktion **postscreen_access_list** gänzlich zu verzichten, ist die Nutzung einer automatisch gepflegten Access-Liste mit Hilfe von **[[centos:mail_c7:spam_3|postwhite]]**((Vielen Dank für den guten Hinweis zu __[[https://github.com/stevejenkins/postwhite|postwhite]]__ geht hier an //**Claas Langbehn**//, der über das Kontaktformular hier im Wiki einen Verbesserungsvorschlag zur vorliegenden Seite einreichte!)) vorzuziehen! </WRAP>
 +
 +<WRAP center round alert 80%>
 +Stellt man auf produktiv im Einsatz befindlichen Mailservern den zusätzlichen Gewinn bei der SPAM-Abwehr durch Nutzung der **[[#post_220_smtp_server_greeting_tests|"Post 220 SMTP Server Greeting" Tests]]** ins Verhältnis zu auftretenden Mailverzögerungen, muss man sich natürlich die Frage stellen, ob hier noch der Aufwand lohnt. 
 +
 +In den __seltensten Fällen__ wird man daher wirklich diese Funktion nutzen wollen!
 +</WRAP>
 +
 +</WRAP>
 +
 +==== Installation ====
 +Mit Hilfe des Projekts **[[https://github.com/stevejenkins/postwhite|Postwhite - Automatic Postcreen Whitelist & Blacklist Generator]]** von [[https://github.com/stevejenkins/|Steve Jenkins]] ist es möglich automatisiert eine Whitelist-Tabelle erstellen und aktualisieren zu lassen. 
 +
 +Postwhite selbst greift wiederum auf **[[https://github.com/spf-tools/spf-tools|SPF-tools]]** zurück. Wir werden also zunächst SPF-tools auf unseren Server holen. Wir wechseln dazu erst einmal in unser locales SRC-Verzeichnis.
 +   # cd /usr/local/src
 +
 +Nun clonen wir das Projekt direkt von GITHUB-Server.
 +   # git clone https://github.com/spf-tools/spf-tools.git
 +
 +Anschließend clonen wir das Projekt Postwhite.
 +   # git clone https://github.com/stevejenkins/postwhite.git
 +
 +Damit wir später postwhite einfach starten können verlinken wir das zugehörige binary nach //**/usr/local/bin/**//.
 +   # ln -s /usr/local/src/postwhite/postwhite /usr/local/bin/postwhite
 +   # ln -s /usr/local/src/postwhite/scrape_yahoo /usr/local/bin/scrape_yahoo
 +
 +==== Konfiguration ====
 +=== Postwhite ===
 +Für die Konfiguration von postwhite finden wir in dem geclonten Projektordner eine vorgefertigte Konfigurationsdatei, die wir in das Verzeichnis //**/etc**// kopieren.
 +   # cp /usr/local/src/postwhite/postwhite.conf /etc/
 +
 +Diese Konfigurationsdatei passen wir nun unseren Gegebenheiten an. Wir passen also dort die beiden Pfade ''**spftoolspath**'' und ''**yahoo_static_hosts**''.
 +
 +   # vim /etc/postwhite.conf>
 +<file bash /etc/postwhite.conf># CONFIGURATION OPTIONS FOR POSTWHITE
 +# https://github.com/stevejenkins/postwhite
 +# POSTWHITE WILL LOOK FOR THIS FILE IN /etc/postwhite.conf
 +
 +# FILE PATHS
 +# Django : 2019-01-28
 +# default: spftoolspath=/usr/local/bin/spf-tools 
 +spftoolspath=/usr/local/src/spf-tools
 +postfixpath=/etc/postfix
 +postfixbinarypath=/usr/sbin
 +whitelist=postscreen_spf_whitelist.cidr
 +blacklist=postscreen_spf_blacklist.cidr 
 +# Django : 2019-01-28
 +# default: yahoo_static_hosts=/usr/local/bin/postwhite/yahoo_static_hosts.txt
 +yahoo_static_hosts=/usr/local/src/postwhite/yahoo_static_hosts.txt
 +
 +# CUSTOM HOSTS
 +# Enter custom hosts separated by a space, ex: "example.com example2.com example3.com"
 +custom_hosts=""
 +
 +# Include list of Yahoo Outbound IPs from https://help.yahoo.com/kb/SLN23997.html?
 +include_yahoo="yes"
 +
 +# Do you also want to build a blacklist?
 +enable_blacklist=no
 +blacklist_hosts=""
 +
 +# Do what to invalid IPv4 addresses and CIDRs?
 +# Valid settings are 'remove' 'fix' or 'keep'
 +invalid_ip4=remove
 + 
 +# Simplify (remove) IP addresses from the whitelist that are already covered by CIDRs?
 +# WARNING: Enabling this option can dramatically increase the time Postwhite takes to
 +# run if you have many mailers selected. Try it once, then come back and turn it off. :)
 +simplify=no
 +
 +# Reload Postfix Automatically when done?
 +reload_postfix=yes
 +</file>
 +
 +=== Postscreen/Postfix ===
 +Postwhite wird uns eine Whitelist generieren und bei Bedarf auch eine Blacklist. Wir müssen nun unsere Postscreen-Konfiguration entsprechend anpassen, so dass die generierte(n) CIDR-Liste(n) entsprechend eingebunden werden.
 +   # vim /etc/postfix/main.cf
 +<code bash>...
 +
 +################################################################################
 +## POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN
 +#
 +# Django : 2019-01-27 - PERMANENT WHITE/BLACKLIST TEST
 +# default: postscreen_access_list = permit_mynetworks
 +postscreen_access_list = permit_mynetworks
 +                         cidr:/etc/postfix/postscreen_spf_whitelist.cidr
 +                         #cidr:/etc/postfix/postscreen_spf_blacklist.cidr
 +
 +
 +...</code>
 +
 +==== Programmstart ====
 +=== manueller Start ===
 +Nun können wir postwhite das erste mal starten.
 +   # postwhite
 +
 +<code>Starting Postwhite v3.4 (14 April 2018)
 +
 +Reading options from /etc/postwhite.conf...
 +
 +Creating temporary files...
 +
 +Recursively querying SPF records of selected whitelist mailers...
 +
 +Querying webmail hosts...
 +Getting spf.constantcontact.com
 +Getting aspmx.sailthru.com
 +Getting mail.zendesk.com
 +Getting _ipspf.yahoo.com
 +Getting _spf1.yahoo.com
 +Getting _spf2.yahoo.com
 +Getting _spf3.yahoo.com
 +Getting spf.messagingengine.com
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting spf.protection.outlook.com
 +Getting spfa.protection.outlook.com
 +Getting spfb.protection.outlook.com
 +Getting spf-a.outlook.com
 +Getting spf-b.outlook.com
 +Getting spf-a.hotmail.com
 +Getting _spf-ssg-b.microsoft.com
 +Getting _spf-ssg-c.microsoft.com
 +Getting emsd1.com
 +Getting acemdns.com
 +Getting _spf-a.microsoft.com
 +Getting spf.protection.outlook.com
 +Getting spfa.protection.outlook.com
 +Getting spfb.protection.outlook.com
 +Getting _spf-b.microsoft.com
 +Getting _spf-mdm.microsoft.com
 +Getting _spf-c.microsoft.com
 +Getting _spf-ssg-a.microsoft.com
 +Getting _spf-ssg-a.msft.net
 +Getting spf-a.hotmail.com
 +Getting spf-a.outlook.com
 +Getting spf-b.outlook.com
 +Getting spf.protection.outlook.com
 +Getting spfa.protection.outlook.com
 +Getting spfb.protection.outlook.com
 +Getting spf-a.hotmail.com
 +Getting _spf-ssg-b.microsoft.com
 +Getting _spf-ssg-c.microsoft.com
 +Getting spf.zoho.com
 +
 +Querying social network hosts...
 +Getting _spf.facebook.com
 +Getting spf.mtasv.net
 +Getting facebookmail.com
 +Getting amazonses.com
 +Getting spf-00082601.pphosted.com
 +Getting _spf.pinterest.com
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting _spf.greenhouse.io
 +Getting mailgun.org
 +Getting spf1.mailgun.org
 +Getting spf2.mailgun.org
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting mailgun.org
 +Getting spf1.mailgun.org
 +Getting spf2.mailgun.org
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting sendgrid.net
 +Getting mail.zendesk.com
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting _thirdparty.twitter.com
 +Getting spf.mandrillapp.com
 +
 +Querying ecommerce hosts...
 +Getting spf1.amazon.com
 +Getting spf2.amazon.com
 +Getting amazonses.com
 +Getting c._spf.ebay.com
 +Getting ces._spf.ebay.com
 +Getting p._spf.ebay.com
 +Getting emarsys.net
 +Getting _spf.salesforce.com
 +Getting p2._spf.ebay.com
 +Getting pp._spf.paypal.com
 +Getting ppcorp._spf.paypal.com
 +Getting 3ph1._spf.paypal.com
 +Getting 3ph2._spf.paypal.com
 +Getting 3ph3._spf.paypal.com
 +Getting 3ph4._spf.paypal.com
 +Getting 3ph5._spf.paypal.com
 +
 +Querying bulk mail hosts...
 +Getting spf-a.authsmtp.com
 +Getting spf-b.authsmtp.com
 +Getting support.zendesk.com
 +Getting mail.zendesk.com
 +Getting _spf.salesforce.com
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting spf0.exacttarget.com
 +Getting spf1.exacttarget.com
 +Getting spf2.exacttarget.com
 +Getting spf3.exacttarget.com
 +Getting spf4.exacttarget.com
 +Getting notifications.fishbowl.com
 +Getting _spf-dash.rmsbot.com
 +Getting spf.mtasv.net
 +Getting aspmx.pardot.com
 +Getting et._spf.pardot.com
 +Getting mktomail.com
 +Getting zuora.com
 +Getting zuora.com._nspf.vali.email
 +Skipping (has macros) %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email
 +Getting stspg-customer.com
 +Getting sparkpostmail.com
 +Getting _spf.sparkpostmail.com
 +Getting _netblocks.sparkpostmail.com
 +Getting sendgrid.net
 +Getting _spf.icontact.com
 +Getting spf.protection.outlook.com
 +Getting spfa.protection.outlook.com
 +Getting spfb.protection.outlook.com
 +Getting 4638697.spf08.hubspotemail.net
 +Getting sg08.hubspotemail.net
 +Getting spe08.hubspotemail.net
 +Getting servers.mcsv.net
 +Getting mail.zendesk.com
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting mailsenders.netsuite.com
 +Getting mailgun.org
 +Getting spf1.mailgun.org
 +Getting spf2.mailgun.org
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting 2910904.spf10.hubspotemail.net
 +Getting sg10.hubspotemail.net
 +Getting spe10.hubspotemail.net
 +Getting support.zendesk.com
 +Getting mail.zendesk.com
 +Getting spf.mailjet.com
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting spf.messagelabs.com
 +Getting nets1.spf.messagelabs.com
 +Getting nets2.spf.messagelabs.com
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting partners.sendgrid.com
 +Getting _spf.salesforce.com
 +Getting stspg-customer.com
 +Getting _labs.sendgrid.com
 +Getting messagesystems.com
 +Getting _spf.salesforce.com
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting _spf.sparkpostmail.com
 +Getting _netblocks.sparkpostmail.com
 +
 +Querying miscellaneous hosts...
 +Getting _spf.google.com
 +Getting _netblocks.google.com
 +Getting _netblocks2.google.com
 +Getting _netblocks3.google.com
 +Getting esp.github.com
 +Getting _spf.createsend.com
 +Getting servers.mcsv.net
 +Getting _spf1.zendesk.com
 +Getting _spf2.zendesk.com
 +Getting _spf3.zendesk.com
 +Getting _spf4.zendesk.com
 +Getting _spf5.zendesk.com
 +Getting _spf6.zendesk.com
 +
 +Querying custom hosts...
 +
 +Including scraped Yahoo! outbound hosts...
 +
 +Removing invalid IPv4 CIDRs from whitelist.......................................................................
 +
 +Sorting whitelist rules...
 +
 +Writing 1896 whitelist rules to /etc/postfix/postscreen_spf_whitelist.cidr...
 +
 +Reloading Postfix configuration to refresh rules...
 +postfix/postfix-script: refreshing the Postfix mail system
 +
 +Done!</code>
 +
 +Damit der laufende Postfix-Daemon die neu erstellte bzw. eine geänderte Whitelist neu einlesen kann, bedarf es eines Relaods des Daemon. Gemäß unserer Konfiguration wir dieser Relaod nach dem Erstellen der CIDR-Liste automatisch ausgeführt, was im MAillog auch entsprechend protokolliert wird.
 +
 +  Jan 27 22:10:28 vml000080 postfix/postfix-script[13598]: refreshing the Postfix mail system
 +  Jan 27 22:10:28 vml000080 postfix/master[4129]: reload -- version 3.3.2, configuration /etc/postfix
 +
 +=== automatischer zeitgesteuerter Programmstart ===
 +In regelmäßigen Abständen soll nun die CIDR-Tabelle mit den Whitelistingeinträgen generiert werden. Hierzu verschieben wir einfach den symbolischen link aus dem Verzeichnis ''**/usr/local/bin**'' in das Verzeichnis ''**/etc/cron.daily**''
 +   # mv /usr/local/bin/postwhite /etc/cron.daily/
 +Somit wird einmal am Tag die bestehende whitelist-Tabelle aktualisiert.
 +
 +Für die Aktualisierung der speziellen Yahoo-Tabelle verschieben wir den zugehörigen symbolischen link aus dem Verzeichnis ''**/usr/local/bin**'' in das Verzeichnis ''**/etc/cron.weekly**''. Hier hat sich ein wöchentlicher Update der Liste als ausreichend gezeigt.
 +   # mv /usr/local/bin/scrape_yahoo /etc/cron.weekly/
  
 ===== FAZIT ===== ===== FAZIT =====
 +<WRAP center round tip>
  
 +Alles in allem kann man festhalten. Mit Hilfe von **Postscreen** erhöht man nicht nur die Erreichbar- und Verfügbarkeit seines Mailservers, sondern man erreicht auch ähnliche wenn nicht gar bessere SPAM/UCE/Virenmail-Schutz, wie zu früheren Zeiten mit **[[centos:mail_c7:spam_1|greylisting]]** und **[[centos:mail_c7:spam_2|policyd-weight]]**. Vor allem die vielen Verzögerungen bei der Mailzustellung, die bei Greylisting bis dato von den Endusern mehr oder minder beklagt wurden, gehören mit Postscreen der Vergangenheit an!
 +
 +Somit kann man guten Gewissens den Einsatz und dem __Vorzug__ von **Postscreen** __vor__ **Greylisting** und **policyd-weight** vornehmen!
 +</WRAP>
  
 ====== Links ====== ====== Links ======
Zeile 793: Zeile 1228:
   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
  
-~~DISCUSSION~~+
  • centos/mail_c7/spam_3.1415649223.txt.gz
  • Zuletzt geändert: 10.11.2014 19:53.
  • von django