Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- centos:mail_c7:spam_3 [25.02.2019 08:00. ] – ["Bare Newline" Tests] django
+++ centos:mail_c7:spam_3 [22.07.2019 15:02. ] (aktuell) – Externe Bearbeitung 127.0.0.1
@@ Zeile 485: / Zeile 485: @@
 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** abschließen. 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 571: / Zeile 571: @@
 mx01.nausch.org ESMTP Postfix
 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** abschließen. 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 Clientverbindung mit der gleichen IP ebenso verfahren.
@@ Zeile 621: / 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:
-  * ''**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 638: / Zeile 638: @@
 <WRAP center round important 80%>
-Stellt man auf produktiv im Einsatz befindlichen Mailservern den zusätzlichen Gewinn bei der SPAM-Abwehr 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!
+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>
@@ Zeile 651: / Zeile 653: @@
 === "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.
@@ Zeile 755: / Zeile 757: @@
 #
 # default: postscreen_pipelining_enable = no
-postscreen_pipelining_enable = yes
 #
 # default: postscreen_pipelining_action = enforce
 #
 # default: postscreen_non_smtp_command_enable = no
-postscreen_non_smtp_command_enable = yes
+#
 # default: postscreen_non_smtp_command_action = drop
 #
 # default: postscreen_bare_newline_enable = no
-postscreen_bare_newline_enable = yes
 #
 # default: postscreen_bare_newline_action = ignore
-postscreen_bare_newline_action = drop
 #
 </code>
@@ Zeile 804: / Zeile 803: @@
 Den Serverstatus können wir uns nun mit Hilfe des folgenden Aufrufes anzeigen lassen.
    # systemctl status postfix
-<code>postfix.service - Postfix Mail Transport Agent
-   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled)
+<html><pre class="code">
-   Active: active (running) since Mon 2014-11-10 20:57:24 CET; 18s ago
+<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)
@@ Zeile 820: / Zeile 821: @@
 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.
-</code>
+</font>
+</pre>
+</html>
@@ Zeile 826: / Zeile 829: @@
 ==== Pass New ====
 Folgender Auszug aus einem Maillog zeigt einen **neuen Client** der **alle Tests bestanden** hat.
-<code><code>Nov  8 06:39:36 vml000080 postfix/postscreen[12580]: CONNECT from [66.220.144.178]:27747 to [10.0.0.80]:25
+<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
@@ Zeile 883: / Zeile 886: @@
 ===== postwhite =====
-<WRAP center round important 100%>
+<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.
+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 100%>
+<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 Kontakformular hier im Wiki einen Verbesserungsvorschlag zur vorliegenden Seite einreichte!)) vorzuziehen! </WRAP>
+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>
@@ Zeile 1219: / Zeile 1228: @@
   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
-/* ~~AUTOTWEET:~~ */