Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- centos:mail_c7:spam_10 [22.07.2019 14:47. ] – django
+++ centos:mail_c7:spam_10 [27.11.2022 20:56. ] (aktuell) – django
@@ Zeile 1: / Zeile 1: @@
-====== SPF - Sender Policy Framework unter CentOS 7.x ======
+====== SPF - Sender Policy Framework (unter CentOS 7.x) ======
 {{:centos:mail_c6:spf-logo-medium.png?nolink |SPF Logo}}
-Mit Hilfe von SPF((**S**ender **P**olicy **F**rameworks)) kann definiert werden, welche Mailserver für welche Domains eMails verschickt werden (können), oder nicht, oder anders ausgedrückt, soll das Fälschen von Absender-Angaben mit Hilfe von SPF erschwert werden. Genauer gesagt schreibt das SPF fest, welcher MTA((**M**ail **T**ransport **A**gent)) abgehend für den Versandt von e-Mails einer Domain zugelassen ist. Wichtige Hinweise zu SPF findet man bei Bedarf in der überarbeiteten Version **[[https://www.ietf.org/rfc/rfc6652.txt|RFC 6652]]**((RFC 6652 aktualisiert [[https://www.ietf.org/rfc/rfc4408.txt|RFC 4408]])) oder auch auf der Webseite von **[[http://www.openspf.org|openspf.org]]**.
+Mit Hilfe von SPF((**S**ender **P**olicy **F**rameworks)) kann definiert werden, welche Mailserver für welche Domains eMails verschickt werden (können), oder nicht, oder anders ausgedrückt, soll das Fälschen von Absender-Angaben mit Hilfe von SPF erschwert werden. Genauer gesagt schreibt das SPF fest, welcher MTA((**M**ail **T**ransport **A**gent)) abgehend für den Versandt von e-Mails einer Domain zugelassen ist. Wichtige Hinweise zu SPF findet man bei Bedarf in der überarbeiteten Version **[[https://www.ietf.org/rfc/rfc7208.txt|RFC 7208]]** oder auch auf der Webseite von **[[http://www.openspf.org|openspf.org]]**.
-Mit SPF soll hauptsächlich Absenderadressfälschungen verhindert werden, nicht jedoch direkt Spam zu bekämpfen. Dieses here Ziel wirft bei genauerer Betrachtung viele Fragen auf und erzeugt bei manchen Mailserver-Betreibern nicht gerade viel Begeisterungsstürme. Probleme tauchen mit unter bei Mailumleitungen, Mailinglisten und/oder WebFormularen auf. Auch wird bei sehr konservativen SPF-Definition die Möglichkeit verhindert, eMails mit eigener Absender-eMail-Adresse über einen dritten Rechner zu versenden. Es wäre also nur möglich eMails auch über den Mail-Server zu versenden, auf dem auch das Postfach liegt! Speziell auch Beim Versand über ein z.B. WebFormular, oder eine Web-Grußkarte über einen Drittanbieter wäre dann **kein Versand** mehr möglich!
+Dieses here Ziel wirft bei genauerer Betrachtung viele Fragen auf und erzeugt bei manchen Mailserver-Betreibern nicht gerade viel Begeisterungsstürme. Probleme tauchen mit unter bei Mailumleitungen, Mailinglisten und/oder WebFormularen auf. Auch wird bei sehr konservativen SPF-Definition die Möglichkeit verhindert, eMails mit eigener Absender-eMail-Adresse über einen dritten Rechner zu versenden. Es wäre also nur möglich eMails auch über den Mail-Server zu versenden, auf dem auch das Postfach liegt! Speziell auch Beim Versand über ein z.B. WebFormular, oder eine Web-Grusskarte über einen Drittanbieter wäre dann **kein Versand** mehr möglich!
-Beim **SPF** wird ein TXT-Record in der Zonendatei der betreffenden (Mail)Domain eingetragen. Dort wird definiert, welche SMTP-Server berechtigt sind, Nachrichten der (Mail)Domain zu verschicken. Mailserver können dann bei der Annahme der eMails abfragen, ob der sendende Mailserver überhaupt berechtigt ist, diese Nachricht zu verschicken.
+Beim **SPF** wird ein TXT-Record in der Zonendatei im DNS der betreffenden (Mail)Domain eingetragen. Dort wird definiert, welche SMTP-Server berechtigt sind, Nachrichten der (Mail)Domain zu verschicken. Mailserver können dann bei der Annahme der eMails abfragen, ob der sendende Mailserver überhaupt berechtigt ist, diese Nachricht zu verschicken. So soll bzw. kann mit Hilfe von SPF versucht werden, Absenderadressfälschungen - eine Form des eMail-Identitätsbetrugs - zu verhindern. SPAM kann aber mit Hilfe des Sender Policy Framework nicht direkt bekämpft werden!
-<uml w=800>
+Nachfolgende Skizze zeigt exemplarisch auf, wo genau SPF beim Verarbeiten einer eMail beim Kommunikationsaufbau und -ablauf zweier **MTA**((**M**ail **T**ransport **A**gent)) das **SPF** zum Tragen kommt. Sobald eine eMail von einem Mailserver empfangen wird, benutzt dieses das SPF um festzustellen, ob das sendende System (MTA) dazu berechtigt ist. Besteht der Absender die SPF-Prüfung nicht, wird die Annahme der Nachricht je nach Konfiguration abgelehnt, zugestellt und|oder ggf. als Spam bzw. Betrug gekennzeichnet.
+<uml>
 title Mailversand einer eMail\n
-skin BlueModern
 participant "\n       Mail-Server mx01.nausch.org        \n         217.91.103.190       \n" as links
 participant "\n       Mail-Server mx1.tachtler.net       \n         88.217.171.167       \n" as mitte
@@ Zeile 37: / Zeile 38: @@
 </uml>
-Weitere Informationen rund um SPF findet man im übrigen auf der [[http://de.wikipedia.org/wiki/Sender_Policy_Framework|Wikipedia Seite]] oder im besagten **[[https://www.ietf.org/rfc/rfc6652.txt|RFC 6652]]**.
+Weitere Informationen rund um SPF findet man im übrigen auf der [[http://de.wikipedia.org/wiki/Sender_Policy_Framework|Wikipedia Seite]] oder im besagten **[[https://www.rfc-editor.org/rfc/rfc7208.html|RFC 7208]]**.
 ===== Definition unseres SPF-Records =====
 Aus den eingangs genannten Gründen sollte eine Sender Policy Framework Definition so gewählt werden, das auch weiterhin Nachrichten umgeleitet, Mailinglisten oder bei Bedarf Webformulare genutzt werden können.
-Ein SPF-Record beinhaltet mehrere Angaben, die jeweils von links nach rechts ausgewertet werden. Der erste Wert gibt an, welche SPF-Version genutzt wird, aktuell SPF-Version "**v=spf1**". Anschließend können mehrere IPv4- und/oder IPv6-Adressen angegeben werden, die entweder berechtigt oder vom Mailversand ausgeschlossen sein sollen. Diese Berechtigung wird dabei über einen //**Qualifier**// definiert. Es stehen folgende Werte zur Verfügung:
+==== Format der SPF-Richtlinie ====
-  * **+** : **positiv** Die nachfolgende IP-Adresse ist als legitimer Sender definiert. Wird kein Qualifer angegeben, wird automatisch der Wert **+** herangezogen (Defaulteinstellung).
+Ein SPF-Record beinhaltet mehrere durch Leerzeichen getrennte Angaben, die jeweils der Reihe nach von links nach rechts ausgewertet werden. Eine solche Angabe kann ein Modifikator wie z.B. **''v''** oder **''redirect''**, ein Typ wie **''a''** bzw. **''mx''** oder auch eine Include-Anweisung **''include''** sein. Der erste Wert gibt an, welche SPF-Version genutzt wird, aktuell SPF-Version "**v=spf1**". Anschliessend können mehrere IPv4- und/oder IPv6-Adressen, auf den MX-Record verweisen werden oder auch weitere SPF-Definitionen inkludiert werden, die entweder berechtigt oder vom Mailversand ausgeschlossen sein sollen. Diese Berechtigung wird dabei über einen //**Qualifier**// definiert.
-  * **-** : **negativ** Die nachfolgende IP-Adresse definiert ein nicht autorisiertes Sendesystem 	Fail 	die Direktive definiert nicht autorisierte Sender
-  * **?** : **neutral** Über die Rechtmäßigkeit des Sendesystems kann nichts ausgesagt werden; Der Sender muß daher akzeptiert werden.
-  * **~** : **soft-fail** Die nachfolgende IP-Adresse definiert ein nicht autorisiertes Sendesystem. Das Empfangssystem soll jedoch die Annahme der Nachricht dennoch annehmen (Test-Qualifier).
-Neben der IP-Adressangabe mittels **ip4** bzw.**ip6**, gibt es noch vier weitere Parameter, die im SPF-Record Anwendung finden.
+Jede SPF-Definition im Zonenfile unseres DNS beginnt mit der sogenannten Versions-Section und wird auf die derzeit aktuelle SPF-Version **''v=spf1''** gesetzt.
-  * **a** definiert einen A-Record der Domäne
+=== Präfix ===
-  * **mx** definiert eine IP-Adresse, die im MX-Record der Domäne definiert wurde.
+Das Präfix bestimmt das SPF-Validierungsergebnis, welches der Empfänger auf die Nachricht anwenden soll, sofern der Absender mit der Angabe/Begriff übereinstimmt. Es stehen folgende Werte zur Verfügung:
-  * **all** Alle anderen IP-Adressen, also den Rest der weiten Welt.
+  * **''+''** : **positiv** Die nachfolgende IP-Adresse ist als legitimer Sender definiert. Wird jeweils __kein__ Qualifer angegeben, wird automatisch der Wert **+** herangezogen (Defaulteinstellung).
-  * **include** Einbinden einer weiteren SPF-Abfrage.
+  * **''-''** : **negativ** Die nachfolgende IP-Adresse definiert ein nicht autorisiertes Sendesystem. Die Direktive Fail definiert nicht autorisierte Sender.
+  * **''?''** : **neutral** Über die Rechtmässigkeit des Sendesystems kann nichts ausgesagt werden; Der Sender muss daher akzeptiert werden.
+  * **''~''** : **soft-fail** Die nachfolgende IP-Adresse definiert ein nicht autorisiertes Sendesystem. Das Empfangssystem soll jedoch die Annahme der Nachricht dennoch annehmen (Test-Qualifier).
+ === Mechanismus ===
+ Der [[https://www.rfc-editor.org/rfc/rfc7208.html#section-5|Mechanismus]] bestimmt, wie eine IP-Adresse mit dem Begriff abgeglichen werden soll. Unterstützte Werte sind hier:
+  * **''a''**       : definiert einen A-Record der Domäne, wird keine Domäne angegeben, wird standardmässig die aktuelle Domäne verwendet.
+  * **''ipv4''**    : Angabe einer IPv4-Adresse
+  * **''ipv6''**    : Angabe einer IPv6-Adresse
+  * **''mx''**      : definiert eine IP-Adresse, die im MX-Record der Domäne definiert wurde.
+  * **''ptr''**     : Dieser Mechanismus prüft, ob das DNS-Reverse-Mapping für <ip> existiert und korrekt auf einen Domänennamen innerhalb einer bestimmten Domäne verweist. Im aktuellen **[[https://www.rfc-editor.org/rfc/rfc7208.html#section-5.5|SPF RFC]]** wird von der Nutzung dringend abgeraten und sollte daher aufgrund verschiedener Sicherheits- und Zuverlässigkeitsprobleme nicht verwendet werden!
+  * **''include''** : Einbinden einer weiteren SPF-Abfrage.
+  * **''exists''**  : Dieser Mechanismus wird verwendet, um einen beliebigen Domänennamen zu konstruieren, der für eine DNS-A-Eintragsabfrage verwendet wird. Er erlaubt komplizierte Schemata die beliebige Teile des mail envelops einbeziehen, um zu bestimmen, was erlaubt ist.
+  * **''all''**     : Alle anderen IP-Adressen, die explizit nicht bis jetzt genannt wurden, also der Rest der weiten Welt.
-In der Regel wird man bei der Definition folgenden Festlegung treffen: //**eMails werden normalerweise immer von den IP-Adressen des zuständigen Mailserver versandt, können aber auch von anderen Servern verschickt werden.**// Als SPF-Record ergibt das dann "//**v=spf1 mx ?all**//" im Falle des Mailservers **mx01.nausch.org**.
+=== Modifikator ===
+[[https://www.rfc-editor.org/rfc/rfc7208#section-6|Modifikatoren]] sind Name/Wert-Paare, mit denen zusätzliche Informationen im SPF-Record geliefert werden können. Die Modifikatoren **sollen** nach allen Mechanismen am Ende eines Datensatzes erscheinen, obwohl diese syntaktisch theoretisch an jeder beliebigen Stelle des Datensatzes stehen können.
+  * **''redirect''** : verweist auf weitere SPF-Definitionen z.B. einer anderen Domain.
+  * **''exp''**      : Sofern ein SMTP-Empfänger eine Nachricht ablehnt, kann dieser optional eine [[https://www.rfc-editor.org/rfc/rfc7208#section-6.2|Erklärung]]  hinzufügen. Welche Erklärungszeichenfolge ein Absender sieht kann der Absender im SPF-Record angeben. Auf diese Weise kann ein Mail-Anbieter nicht konforme Sender Hinweise und Anweisungen zu SPF und zur Konfiguration von SPF geben. Der Modifikator **''exp''** darf __nur __ druckbare ASCII-Zeichen enthalten!
+==== Beispiele ====
+=== einfach "mx"-Definition ===
+Im ersten Konfigurationsbeispiel, welches vermutlich einen Großteil von vielen MTA abdecken wird, treffen wir folgende Definition: //**eMails werden normalerweise immer von den IP-Adressen des zuständigen Mailserver versandt, können aber auch von anderen Servern verschickt werden. Ein empfangendes System soll auf jeden Fall die Nachricht annehmen, diese aber entsprechend kennzeichnen.**// Als resultierender SPF-Record ergibt das dann z.B. **''v=spf1 mx ~all''** im Falle des Mailservers **mx01.nausch.org**. Den Präfix **''+''** beim Mechanismus **''mx''** können wir weglassen, da dies die Defaulteinstellung ist.
-Wir tragen also bei unserem zuständigen DNS entsprechend die richtigen Daten ein.
+Wir tragen also bei unserem zuständigen DNS im Zonenfile entsprechend die richtigen Daten ein.
-   nausch.org                              IN      TXT     "v=spf1 mx ?all"
+<code>nausch.org               IN      TXT     "v=spf1 mx ~all"</code>
-Über die URL [[http://www.kitterman.com/spf/validate.html|SPF Record Testing Tools]] kann man online bei Bedarf testen, ob der SPF-Eintrag soweit richtig ist.
+Ändert sich die Anzahl der MX-Records bei unserer Domäne werden automatisch die zutreffenden Hosts bei einer SPF-Anfage honoriert, ohne dass wir extra den SPF-TXT-Record anfassen müssen. Sehr wohl ist jedoch anzumerken, dass für die vollständige Ermittlung der sendeberechtigten Systeme zusätzliche DNS-Abfragen notwendig werden, was mit unter zu Problemen führen kann, sofern die max. Anzahl von **10 DNS-Abfragen** überschritten werden wird. Wie wir damit besser umgehen und diese Herausforderung meistern können, betrachten wir im Abschnitt **[[#dns_lookup_limitierung|DNS Lookup Limitierung]]** dann noch extra genauer!
+=== Erweiterungen um weitere Mechanismen ===
+Im zweiten Beispiel nehmen wir an, dass neben dem MX der Domäne auch noch eine Webanwendung **''cloud.nausch.org''** direkt Nachrichten versenden wird. Wir ergänzen also unseren Standard-mx-Eintrag um den Mechanismus **''a''**.
+<code>nausch.org     IN      TXT     "v=spf1 mx a:cloud.nausch.org ~all"</code>
+Da wir statt der IP-Adresse den Namen **cloud.nausch.org** angegeben haben, wird auch hier eine weitere DNS-Abfrage notwendig werden, wenn der vollständige SPF-Definition ermittelt werden soll. Alternativ kann man hier natürlich mit den **''ipv4''** und **''ipv6''** Mechanismen arbeiten.
+<code>nausch.org     IN      TXT     "v=spf1 mx a:cloud.nausch.org ip4:24.134.171.249/32 ip6:2001:678:e68:102:566e:2177:15b3:57fe/128 ~all"</code>
+<WRAP center round important 80%>
+Zu beachten ist hier natürlich, dass die maximale Länge von **255 Zeichen** eines TXT-Records __keinenfalls__ überschritten werden darf!
+</WRAP>
+Hat man viele versendende Systeme und/oder viele IPv6-Adressen, wird man sehr schnell an diese Grenze stossen. Hier greifen wir nun auf den Mechanismus **''include''** zurück.
+<code>nausch.org                      IN      TXT     "v=spf1 mx a:cloud.nausch.org  include:_spf.blk1.nausch.org include:_spf.blk2.nausch.org include:_spf.blk3.nausch.org ~all"
+_spf.blk1.nausch.org    3600    IN      TXT     "v=spf1 ip6:2001:678:e68:102:1ae8:29ff:fec6:c8dd/128 ip6:2001:678:ed0:102:1ae8:29ff:fec6:c8dd/128 ip6:2001:678:e68:102:dea6:32ff:fe22:f0f2/128 ip6:2001:678:ed0:102:dea6:32ff:fe22:f0f2/128"
+_spf.blk2.nausch.org    3600    IN      TXT     "v=spf1 ip6:2001:678:e68:102:1ae8:29ff:fea9:22ed/128 ip6:2001:678:ed0:102:1ae8:29ff:fea9:22ed/128 ip6:2001:678:e68:102:1ae8:29ff:fec6:c8eb/128 ip6:2001:678:ed0:102:1ae8:29ff:fec6:c8eb/128"
+_spf.blk3.nausch.org    3600    IN      TXT     "v=spf1 ip4:81.169.212.137/32 ip4:24.134.171.249/32"
+</code>
+<WRAP center round important 80%>
+Wichtig ist hierbei, dass bei Nutzung des Mechanismus **''mx''** dieser im führenden SPF-Record aufgeführt wird und nicht in einem der inkludierten zusätzlichen ergänzenden Records! Weiterhin ist zu beachten, dass pro MX-Eintrag im DNS dann zusätzliche DNS-Anfragen nach sich ziehen, siehe [[#dns_lookup_limitierung|Abschnitt DNS Lookup Limitierung]].
+</WRAP>
-<WRAP center round tip 100%>
+==== zusätzliche Hinweise ====
+<WRAP center round tip 80%>
 **Hinweise:** \\
 Will man neben dem **SPF**-Record in Form eines TXT-Records auch noch einem **google-site-verification** TXT-Record anlegen, dann kann man nicht zwei TXT-Records für die Domain im DNS hinterlegen. Um dennoch beide Funktionenn nutzen zu können, trägt man beide Werte in einem TXT-Record ein. So z.B. <code>@ 300 IN TXT "v=spf1 ip4:217.92.13.131/32 mx ?all " "google-site-verification=oghnZ6HahxTGKkknsap_i-iX8nMi9iz0n6ArEvxuLFA"</code>
 </WRAP>
+==== DNS Lookup Limitierung ====
+Abhängig von den verwendeten **[[#mechanismus|Mechanismen]]** oder auch **[[#modifikator|Modifikatoren]]** müssen in aller Regel zur Evaluierung der Bewertung der IP-Adresee des einliefernden SMTP-Clients weitere DNS-Anfragen durchgeführt werden. Im [[https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4|RFC 7208]] finden sich ausführliche Hinweise zu den Limitierungen beim DNS-Lookup im Bezug auf unsere SPF-Definitionen.
+Haben wir wie [[#erweiterungen_um_weitere_mechanismen|in diesem Beispiel]] den Mechanismus **''a''** verwendet, muss bei einer Prüfung der verwendete Daemon nicht nur einen TXT-Record im DNS erfragen, sondern zusätzlich noch eine A- (oder AAAA-) DNS-Abfrage für die Domäne durchführen. Beim Mechanismus **''mx''** können das, ja nach Anzahl der im MX-Record hinterlegten MX-Einträge dann einen oder auch mehrere zusätzliche A- (oder AAAA-) DNS-Abfrage nach sich ziehen. Im Falle z.B. von mailbox.org mit den hinterlegten 4 Mailservern wären das dann vier zusätzliche DNS-Anfragen.
+Doch wie viele DNS-Anfragen werden nun im Zweifelsfall zusätzlich benötigt? Eine Antwort auf diese Frage bietet nachfolgende Tabelle.
+|< 30% 10% 5% 10% 5% >|
+^ [[#mechanismus|Mechanismus]]    ^  lookups  ^ [[#modifikator|Modifikator]]   ^  lookups  ^
+| **''a''**                      |     1     | **''v''**                      |     0     |
+| **''all''**                    |     0     | **''exp''**                    |     0     |
+| **''exists''**                 |     1     | **''redirect''**               |     1     |
+| **''include''**                |    ≥ 1    |                                |           |
+| **''ip4''**                    |     0     |                                |           |
+| **''ip6''**                    |     0     |                                |           |
+| **''include''**                |    ≥ 1    |                                |           |
+| **''mx''**                     |    ≥ 1    |                                |           |
+| **''ptr''**                    |    ≥ 1    |                                |           |
+Sehen wir uns nun den SPF-Record **''lists.nausch.org''** genauer an und gehen detailliert auf die einzelnen Werte ein.
+   $ dig TXT lists.nausch.org +short
+<code>v=spf1 mx include:_spf.blk1.nausch.org include:_spf.blk2.nausch.org -all exp=explain._spf.%{d}</code>
+   $ dig TXT _spf.blk1.nausch.org +short
+<code>"v=spf1 ip6:2001:678:e68:102:1ae8:29ff:fec6:c8dd/128 ip6:2001:678:ed0:102:1ae8:29ff:fec6:c8dd/128 ip6:2001:678:e68:102:dea6:32ff:fe22:f0f2/128 ip6:2001:678:ed0:102:dea6:32ff:fe22:f0f2/128"</code>
+   $ dig TXT _spf.blk2.nausch.org +short
+<code>"v=spf1 ip6:2001:678:e68:102:1ae8:29ff:fea9:22ed/128 ip6:2001:678:ed0:102:1ae8:29ff:fea9:22ed/128 ip6:2001:678:e68:102:1ae8:29ff:fec6:c8eb/128 ip6:2001:678:ed0:102:1ae8:29ff:fec6:c8eb/128"</code>
+   $ dig TXT explain._spf.nausch.org +short
+<code>"Emails from lists.nausch.org may only be sent from your own authorized mail servers. Further instructions and explanations can be found here: https://dokuwiki.nausch.org/doku.php/centos:mail_c7:spam_10"</code>
+Zur vollständigen Bewertung eines anliefernden SMTP-Clients (IP-Adresse) sind also noch weitere DNS-Anfragen notwendig...
+  - einen MX-Lookup je Host im MX-Record einen Lookup (in unserem Fall **1** für den Host **''mx1.nausch.org''**)
+  - zwei TXT-Lookups für die inkludierten Blöcke **''_spf.blk1''** und **''_spf.blk2''**
+... in Summe also **drei** DNS-Anfagen. Hätte der MX-Record hingegen **vier** eingetragene Mailserver, wären dies schon in Summe **sechs** DNS-Anfragen!
+<WRAP center round important 80%>
+Aus diesem Grund ist es ratsam, statt dem **mx**-Mechanismus die betreffenden Mailserver einzeln in einem **''include''**-Abschnitt aufzuführen! Natürlich müssen bei Änderungen am MX-Record dann zusätzlich auch die IP-Adressen im **''include''** Abschnitt gepflegt werden, so dass in einem SPF-Record nur aktuell verwendete Systeme gelistet werden sollen, versteht sich von selbst und sollte so erst gar nicht einer Erwähnung benötigen.
+Der SPF-Standard **[[https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4|RFC7208]]** schreibt vor, dass eine SPF-Richtlinie nicht mehr als 10 zusätzliche DNS-Lookups zur vollständigen Auswertung benötigen darf. Wenn ein Empfänger mehr als 10 Suchvorgänge durchführen muss, um die SPF-Richtlinie zu bewerten, schlägt beim Zustellversuch der eMail-Nachricht die SPF-Validierung mit einem Permerror-Status fehl, was die Zustellung der E-Mail-Nachricht verhindern kann.
+</WRAP>
+==== Testing-Tools ====
+Zum Testen auf Validität unseres SPF-Records stehen uns im WEB unter anderem folgende Dienste (**[[#tests_und_logging|SPF Record Testing Tools]]**) zur Verfügung. Die Ergebnisse können helfen auf Mängel in den Records hinzuweisen, so dass wir zur besseren Reputation bei der Mailannahmen bei den Empfängern doch auch entscheidend Einfluss nehmen können.
+  * **[[http://spf.myisp.ch/|SPF Record Checker]]** \\ {{ :centos:mail_c7:spf_checker_1.png?nolink&750 |Bild: Bildschirmhardcopy SPF Record Checker}}
+  * **[[https://www.spf-record.de/spf-lookup/|spfrecord by nicmanager]]** \\ {{ :centos:mail_c7:spf_checker_3.png?nolink&750 |Bild: Bildschirmhardcopy SPF Record Testing Tools}}
+  * **[[https://dmarcian.com/spf-survey/|SPF Surveyer - dmarcian]]** \\ {{ :centos:mail_c7:spf_checker_4.png?nolink&750 |Bild: Bildschirmhardcopy demarcian SPF Surveyer}}
+  * **[[https://www.kitterman.com/spf/validate.html|SPF Record Testing Tools]]** \\ {{ :centos:mail_c7:spf_checker_2.png?nolink&750 |Bild: Bildschirmhardcopy SPF Record Testing Tools}}
+  * **[[https://mxtoolbox.com/SuperTool.aspx|MX Toolbox]]** \\ {{ :centos:mail_c7:spf_checker_5.png?nolink&750 |Bild: Bildschirmhardcopy MX Toolbox - SPF Record Lookup}}
+  * **[[https://mxtoolbox.com/emailhealth/|MX Toolbox: Email Health Report]]** \\ {{ :centos:mail_c7:spf_checker_6.png?nolink&750 |Bild: Bildschirmhardcopy MX Toolbox - Email Health Repor}}
 ===== SPF-Bewertung bei der Mailannahme =====
 Neben der Befragung von [[centos:mail_c6:mta_3?&#access-dateien|Black-/White-Listen]], dem Nutzen von  [[centos:mail_c7:spam_3|Postscreen]] oder [[centos:mail_c7:spam_1|greylisting]] und [[centos:mail_c7:spam_2|policyd-weight]], können wir auch **SPF** bei der Bewertung von eingehenden Sendungen heranziehen.
@@ Zeile 122: / Zeile 214: @@
 ==== Konfiguration ====
-Die Konfiguration des **smf-spf**-Daemons gestaltet sich vergleichsweise einfach und erfolgt lediglich mit Hilfe Der Datei //**/etc/mail/smfs/smf-spf.conf**//. In der Default-Konfiguration wird der Daemon über einen UNIX-Datei-Socket angesprochen. Diesen Parameter **Socket** weisen wir einem localen Port zu, über den wir später von Postfix aus, den SPF-Milter ansprechen wollen.
+Die Konfiguration des **smf-spf**-Daemons gestaltet sich vergleichsweise einfach und erfolgt lediglich mit Hilfe Der Datei //**/etc/mail/smfs/smf-spf.conf**//. In der Default-Konfiguration wird der Daemon über einen UNIX-Datei-Socket angesprochen. Diesen Parameter **Socket** weisen wir einem lokalen Port zu, über den wir später von Postfix aus, den SPF-Milter ansprechen wollen.
 Mit unserem Editor der Wahl, z.B. **vim** bearbeiten wir diese Konfigurationsdatei.
@@ Zeile 240: / Zeile 332: @@
 </file>
-In der Konfigurationsdatei **main.cf** unseres Postfix-Mailserver definieren wir uns nun eine eigene Variable, die wir dann in der Datei //**/etc/postfix/master.cf**// dann verwenden wollen. Wir tragen also nun in der Section **MILTER**e nachfolgende Zeilen ein.
+In der Konfigurationsdatei **main.cf** unseres Postfix-Mailserver definieren wir uns nun eine eigene Variable, die wir dann in der Datei //**/etc/postfix/master.cf**// dann verwenden wollen. Wir tragen also nun in der Section **MILTER** nachfolgende Zeilen ein.
    # vim /etc/postfix/main.cf
 <file bash /etc/postfix/main.cf>...
@@ Zeile 275: / Zeile 367: @@
    # systemctl status smf-spf
-<code>smf-spf.service - Sender Policy Framework milter
+<html><pre class="code">
+<font style="color: rgb(0, 255, 0)"><b>● </b></font>smf-spf.service - Sender Policy Framework milter
    Loaded: loaded (/usr/lib/systemd/system/smf-spf.service; disabled)
-   Active: active (running) since Wed 2014-12-17 14:05:12 CET; 40min ago
+   Active: <font style="color: rgb(0, 255, 0)"><b>active (running)</b></font>since Wed 2014-12-17 14:05:12 CET; 40min ago
   Process: 19140 ExecStart=/usr/sbin/smf-spf (code=exited, status=0/SUCCESS)
  Main PID: 19141 (smf-spf)
@@ Zeile 283: / Zeile 376: @@
            └─19141 /usr/sbin/smf-spf
-Dec 17 14:05:12 vml000087.dmz.nausch.org systemd[1]: Started Sender Policy Framework milter
+Dec 17 14:05:12 vml000087.dmz.nausch.org systemd[1]: Started Sender Policy Framework milter</font>
-</code>
+</pre>
+</html>
 Im Maillog wird der Start des Daemon entsprechend dokumentiert.
@@ Zeile 292: / Zeile 385: @@
    Dec 17 14:05:12 vml000087 smf-spf[19140]: starting smf-spf 2.0.2 listening on inet:8890@127.0.0.1
    Dec 17 14:05:12 vml000087 smf-spf[19140]: running as uid: 993, gid: 99
 Mit Hilfe von **netstat** können wir überprüfen, ob der Port **8890** geöffnet wurde.
@@ Zeile 337: / Zeile 429: @@
    Authentication-Results: mx01.nausch.org; spf=fail smtp.mailfrom=<newsletter@aktuell.erwinmueller.de> smtp.helo=mx1.tachtler.net
-Zum Testen des SPF-Records kann man auch auf Dienste im WWW zurückgreifen. So kann man seinen SPF-Record z.B. über den **[[http://spf.myisp.ch/|SPF Record Checker]]** überprüfen lassen.
+Zum **[[#testing-tools|Testen des SPF-Records]]** kann man auch auf Dienste im WWW zurückgreifen.
-{{ :centos:mail_c7:spf.myisp.ch.png?800 |Bild: Ergebnisseite eines SPF-Scans auf der Seite http://spf.myisp.ch/}}
-Alternativ dazu bietet sich auch kitterman's **[[http://www.kitterman.com/spf/validate.html|SPF Record Testing Tools - SPF Query Tool]]** an.
 ===== SRS - Sender Rewriting Scheme =====
-Zu Beginn dieses Artikels wurde bereits darauf hingewiesen, dass mit unter Probleme bei Mailumleitungen und/oder WebFormularen auftauchen können. Mit **SRS**((**S**ender **R**ewriting **S**cheme)) kann ein Mailserver die eMail-Adresse im Envelop umschreiben und anpassen. Eine genauere Beschreibung zu SRS ist im Kapitel **[[centos:mail_c7:spam_11|SRS - Sender Rewriting Scheme]]** zu finden.
+Zu Beginn dieses Artikels wurde bereits darauf hingewiesen, dass mit unter Probleme bei Mailumleitungen und/oder Web-Formularen auftauchen können. Mit **SRS**((**S**ender **R**ewriting **S**cheme)) kann ein Mailserver die eMail-Adresse im Envelop umschreiben und anpassen. Eine genauere Beschreibung zu SRS ist im Kapitel **[[centos:mail_c7:spam_11|SRS - Sender Rewriting Scheme]]** zu finden.
 ====== Links ======
@@ Zeile 351: / Zeile 439: @@
   * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**
   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**