| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| centos:mail_c7:spam_3 [25.02.2019 07:11. ] – django | centos:mail_c7:spam_3 [22.07.2019 15:02. ] (aktuell) – Externe Bearbeitung 127.0.0.1 |
|---|
| </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. |
| # 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: |
| </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. |
| |
| 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%> | <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. | 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%> | <WRAP center round tip 100%> |
| 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 |
| |
| </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> |
| 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 === |
| |
| 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> |
| * **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> |
| |
| |
| === "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. |
| |
| 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. |
| |
| |
| |
| 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. |
| |
| 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. |
| |
| |
| # | # |
| # 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> |
| Den Serverstatus können wir uns nun mit Hilfe des folgenden Aufrufes anzeigen lassen. | Den Serverstatus können wir uns nun mit Hilfe des folgenden Aufrufes anzeigen lassen. |
| # systemctl status postfix | # 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: 15133 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS) |
| Process: 15148 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS) | Process: 15148 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS) |
| 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 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. | Nov 10 20:57:24 vml000087.dmz.nausch.org systemd[1]: Started Postfix Mail Transport Agent. |
| </code> | </font> |
| | </pre> |
| | </html> |
| |
| |
| ==== Pass New ==== | ==== Pass New ==== |
| Folgender Auszug aus einem Maillog zeigt einen **neuen Client** der **alle Tests bestanden** hat. | 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: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:43 vml000080 postfix/postscreen[12580]: [66.220.144.178]27747: discarding EHLO keywords: DSN |
| |
| ===== 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. | 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> |
| * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]** | * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]** |
| |
| /* ~~AUTOTWEET:~~ */ | |
| |
django