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 [25.02.2019 08:08. ] – [postwhite] djangocentos:mail_c7:spam_3 [22.07.2019 15:02. ] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 638: Zeile 638:
  
 <WRAP center round important 80%> <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> </WRAP>
  
Zeile 651: 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 884: Zeile 886:
  
 ===== postwhite ===== ===== 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, insbesondere dann wenn man die [[#post_220_smtp_server_greeting_tests|Post 220 SMTP Server Greeting Tests]] nutzen möchte.  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> </WRAP>
Zeile 1220: Zeile 1228:
   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
  
-/* ~~AUTOTWEET:~~ */ 
  
  • centos/mail_c7/spam_3.1551082088.txt.gz
  • Zuletzt geändert: 25.02.2019 08:08.
  • von django