Skip to navigation
How to setup dkim
30.05.19
DomainKeys Identified Mail (DKIM) ist ein Verfahren zur automatischen Signatur von Mails bzw. zur Überprüfung der Signatur. DKIM-signierte E-Mails können zweifelsfrei ihrem Absender zugeordnet werden. Obwohl DKIM kein Kriterium zur Spam-Erkennung ist, betrachten manche Mail-Provider DKIM-signierte Mails als vertrauenswürdiger. Die Konfiguration von DKIM kann somit (manchmal) vermeiden, dass eigene Mails vom Empfänger als Spam betrachtet werden. Dieser Artikel erläutert die Hintergründe von DKIM und zeigt, wie der eigene Mail-Server konfiguriert werden kann, um ausgehende Mails DKIM-konform zu signieren. Ich gehe davon aus, dass bereits ein funktionierender Mail-Server mit Postfix eingerichtet wurde und dass das ganze System unter Ubuntu läuft. Bei anderen Distributionen wird es vermutlich kleinere Abweichungen geben, das Prinzip bleibt aber natürlich unverändert. DKIM-Konzept DKIM-Konzept Funktionsweise Die Idee von DomainKeys Identified Mail (DKIM, Wikipedia) sieht so aus: Wenn ein DKIM-konfigurierter Mail-Server eine Mail versendet, verwendet er einen auf dem Mail-Server gespeicherten privaten Schlüssel und fügt der Mail eine Signatur hinzu. Der Empfänger-Mail-Server kann nun zur Kontrolle den DNS-TXT-Eintrag des Senders auslesen. Dieser enthält den öffentlichen Teil des Schlüssels. Damit kann überprüft werden, ob die Mail und die Signatur zusammenpassen. Mit DKIM kann also überprüft werden, ob die Mail tatsächlich von der in der Mail angegebenen Adresse stammt — und das ist schon viel wert. (Nur der legitime Mail Server verfügt über den privaten Schlüssel und kann damit eine korrekte Signatur durchführen.) DKIM und SPF: DKIM wird oft zusammen mit SPF beschrieben. Das Sender Policy Framework (SPF, Wikipedia) ist ein wesentlich einfacheres Verfahren, das das Fälschen der Absenderadresse vermeiden soll. Die Gemeinsamkeit zu DKIM besteht darin, dass auch SPF einen DNS-Eintrag nutzt. Anders als bei DKIM enthält dieser Eintrag aber nur die IP-Adressen der Mail-Server, die für einen bestimmten Domainnamen Mails versenden dürfen. Beim Generieren eines geeigneten DNS-Eintrags hilft z.B. die Seite http://www.spf-record.de/generator. Außer dem Einrichten des korrekten DNS-TXT-Eintrags ist keine weitere Konfigurationsarbeit notwendig. Ähnlich minimal ist aber auch der Nutzen: Besonders ungnädig ist der Postfix-Experte Peer Heinlein, der SPF als Bullshit und Broken by Design bezeichnet (Quelle). DKIM/SPF als Spam-Schutz? Niemand kann Spammer daran hindern, ebenfalls DKIM und SPF zu nutzen. Insofern sind DKIM und SPF kein eindeutiges Kriterium zur Spam-Erkennung. Welchen Grund gibt es dann, sich überhaupt damit auseinanderzusetzen? Die Hauptmotivation besteht normalerweise darin, dass man als kleiner Mail-Server-Betreiber ständig das Problem hat, dass große Mail-Provider vom eigenen Mail-Server versandte Mails als Spam betrachten. Anders formuliert: Zum Ärger darüber, selbst ständig mit Spam überschüttet zu werden, kommt das Problem hinzu, dass Google, GMX, Microsoft, Yahoo etc. eigene Mails fälschlich als Spams identifizieren. Immer wieder muss man Kunden, Geschäftspartner etc. darauf hinweisen: »Werfen Sie bitte auch einen Blick in Ihren Spam-Ordner!« oder »Fügen Sie kofler.info zur Liste der vertrauenswürdigen Empfänger (= Whitelist) hinzu.« Um die Schmach zu vermeiden, dass die Mails der eigenen Firma als unseriös betrachtet werden, versucht man seinen Mail-Server so regelkonform wie möglich zu betreiben und implementiert selbst Verfahren, von deren Wertlosigkeit man eigentlich überzeugt ist. (Wobei hinzuzufügen ist: DKIM ist an sich keine schlechte Idee. Es ermöglicht die Authentizität der Absenderadresse zu verifizieren. Das ist durchaus lobenswert, aber es ändert eben nichts daran, dass auch Spammer DKIM verwenden können.) OpenDKIM installieren und einrichten OpenDKIM ist eine Open-Source-Implementierung von DKIM. Das Programm kann gleichermaßen ausgehende Mails mit einem eigenen Schlüssel signieren als auch die Signatur eintreffender Mails überprüfen. OpenDKIM ist mit diversen MTAs kompatibel. Diese Anleitung zeigt das Zusammenspiel von DKIM mit Postfix, wobei das Hauptaugenmerk des Artikels beim korrekten Signieren liegt. Das Ziel ist es also, Postfix so zu konfigurieren, dass es ausgehende Mails DKIM-konform signiert und so die Wahrscheinlichkeit mindert, dass die Mail vom Empfänger als Spam betrachtet wird. Zuerst installieren Sie OpenDKIM: apt-get install opendkim opendkim-tools Dann richten Sie ein Verzeichnis für die DKIM-Schlüssel ein: mkdir /etc/opendkim mkdir /etc/opendkim/keys chown -R opendkim:opendkim /etc/opendkim chmod go-rw /etc/opendkim/keys Konfigurationsdatei opendkim.conf Die zentrale Konfigurationsdatei von OpenDKIM ist /etc/opendkim.conf. Erstellen Sie eine Sicherheitskopie der ursprünglichen Datei und modifizieren Sie opendkim.conf dann wie das folgende Muster. Details zu den Dateien trusted, key.table und signing.table, auf die die Konfiguration verweist, folgen gleich. Einzelheiten zu den diversen opendkim.conf-Optionen können Sie mit man opendkim.conf nachlesen. # Datei /etc/opendkim.conf # OpenDKIM agiert als Mail Filter (= Milter) in den # Modi signer (s) und verifier (v) und verwendet eine # Socket-Datei zur Kommunikation (alternativ: lokaler Port) Mode sv # Socket local:/var/run/opendkim/opendkim.sock Socket inet:12345@localhost # OpenDKIM verwendet diesen Benutzer bzw. # diese Gruppe UserID opendkim:opendkim UMask 002 PidFile /var/run/opendkim/opendkim.pid # OpenDKIM bei Problemen neustarten, # aber max. 10 mal pro Stunde AutoRestart yes AutoRestartRate 10/1h # Logging (wenn alles funktioniert eventuell reduzieren) Syslog yes SyslogSuccess yes LogWhy yes # Verfahren, wie Header und Body durch # OpenDKIM verarbeitet werden sollen. Canonicalization relaxed/simple # interne Mails nicht mit OpenDKIM verarbeiten ExternalIgnoreList refile:/etc/opendkim/trusted InternalHosts refile:/etc/opendkim/trusted # welche Verschlüsselungs-Keys sollen für welche # Domains verwendet werden # (refile: für Dateien mit regulären Ausdrücke) SigningTable refile:/etc/opendkim/signing.table KeyTable /etc/opendkim/key.table # diesen Signatur-Algorithmus verwenden SignatureAlgorithm rsa-sha256 # Always oversign From (sign using actual From and a null From to prevent # malicious signatures header fields (From and/or others) between the signer # and the verifier. From is oversigned by default in the Debian pacakge # because it is often the identity key used by reputation systems and thus # somewhat security sensitive. OversignHeaders From /etc/default/opendkim: Bitte beachten Sie, dass unter Debian und Ubuntu beim Start von OpenDKIM auch die Datei /etc/default/opendkim ausgewertet wird. Dort durchgeführte Einstellungen haben Vorrang gegenüber opendkim.conf. Standardmäßig enthält /etc/default/opendkim nur Kommentare, und ich gehe in dieser Anleitung davon aus, dass Sie es dabei belassen. Keine Signatur für interne Mails Die Datei trusted gibt an, welchen Hosts der Mail-Server vertraut, d.h., für welche Hosts auf die DKIM-Signatur verzichtet wird. Ersetzen Sie die drei kofler.info-Einträge durch entsprechende Einträge mit dem Hostnamen Ihres Mail-Servers! # Datei /etc/opendkim/trusted 127.0.0.1 ::1 localhost kofler kofler.info host1.kofler.info Welcher Schlüssel für welchen Hostnamen? Als nächstes richten Sie mit einem Editor die Dateien signing.table und key.table gemäß dem folgenden Muster ein. signing.table gibt an, für welche From-Adressen welcher Schlüssel verwendet werden soll. Die zweite Spalte in signing.table bezieht sich dabei auf die erste Spalte in key.table. Natürlich müssen Sie kofler.info und kofler durch eigene Namen ersetzen! # Datei /etc/opendkim/signing.table # für E-Mails von xxx@kofler.info den Schlüssel 'kofler' # zum Signieren verwenden *@kofler.info kofler key.table gibt dann den tatsächlichen Ort der Schlüsseldateien an. Die zweite Spalte besteht dabei aus drei Teilen: Dem Hostnamen (hier kofler.info), dem Selektor (hier 201611) und dem eigentlichen Dateinamen. Die Verwendung einer Zeitangabe für den Selektor hilft dabei einen Überblick zu behalten, wann die Schlüssel erzeugt wurden — hier also im Nov. 2016. # Datei /etc/opendkim/key.table # der Schlüssel 'kofler' befindet sich in # des Datei /etc/opendkim/keys/kofler.private kofler kofler.info:201611:/etc/opendkim/keys/kofler.private Wenn Ihr Mail-Server für mehrere Hosts zuständig ist, ergänzen Sie key.table und signing.table um entsprechende Einträge für alle weiteren Hosts. Schlüssel generieren Das Kommando opendkim-genkey erzeugt einen privaten Schlüssel (name.private) und einen öffentlichen Schlüssel (name.txt). Der private Schlüssel verbleibt am Server und darf nicht in falsche Hände geraten! Der öffentliche Schlüssel wird später im DNS-TXT-Record des Mail-Servers gespeichert. Die wichtigsten Optionen des Kommandos lauten: -d domain gibt an, für welche Domain die Schlüssel gelten sollen. Die Option wird aktuell nur dazu verwendet, um einen Kommentar in name.txt einzubauen. Ohne die Option verwendet opendkim-genkey die Zeichenkette example.com. -b 2048 gibt an, dass ein Schlüssel in der Länge von 2048 Bits generiert werden soll. Größere Schlüssel sind momentan mit der gängigen Mail-Server-Infrastruktur inkompatibel. Standardmäßig verwendet opendkim-genkey 1024 Bits, was aber vielfach als nicht mehr als ausreichend sicher erachtet wird. -r gibt an, dass der Schlüssel ausschließlich zur Signatur von E-Mails verwendet werden darf (restricted). -s selector gibt eine Selektor-Zeichenkette an, um das Schlüsselpaar zu identifizieren (standardmäßig: default). Die Selektor-Zeichenkette bestimmt die Namen der Schlüsseldateien. -s 201611 bewirkt also, dass die Dateien 201611.txt und „201611.private` erzeugt werden. Vorsicht. Eventuell schon vorhandene Schlüsseldateien werden ohne Rückfrage überschrieben. Um also Schlüssel zu erzeugen, die zum obigen Beispiel passen, führen Sie das folgende Kommando aus: cd /etc/opendkim opendkim-genkey -d kofler.info -b 2048 -r -s 201611 Die resultierenden Dateien sehen so aus: cat 201611.private -----BEGIN RSA PRIVATE KEY----- totalGeheimBlaBla123 ... -----END RSA PRIVATE KEY----- cat 201611.txt 201611._domainkey IN TXT ( "v=DKIM1; k=rsa; s=email; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCA...73Qzl5Czna79" "7955/zX7Bp10e/lATZbVtP6Qu6eC2TMpWx06bEDRZ...oAtNNuhQIDAQAB" ) ; ----- DKIM key 201611 for kofler.info Die Dateien müssen nun noch entsprechend der Angaben in key.table platziert werden. Zuletzt stellen Sie sicher, dass nur der Benutzer opendkim auf die Dateien und Verzeichnisse zugreifen darf: cd /etc/opendkim mv 201611.private keys/kofler.private mv 201611.txt keys/kofler.txt chown -R opendkim:opendkim /etc/opendkim chmod -R go-rwx /etc/opendkim/keys DNS-TXT-Eintrag hinzufügen Der nächste Schritt besteht darin, den öffentlichen Teil der DKIM-Schlüssels, also in der Logik dieses Beispiels den Inhalt von kofler.txt in einem TXT-Eintrag in der DNS-Konfiguration Ihres Hostnamens zu speichern. Dabei verwenden Sie die Zeichenkette vor dem Schlüsselwort IN für das Feld Hostname des DNS-Eintrags und den gesamten Text zwischen den runden Klammern für das Feld Destination. In der Weboberfläche meines Hosters sieht der Dialog zum Einrichten eines neuen DNS-Eintrags vom Typ TXT so aus: Ein neuer DNS-Eintrag vom Typ »TXT« enthält den öffentlichen Teil des DKIM-Schlüssels Ein neuer DNS-Eintrag vom Typ »TXT« enthält den öffentlichen Teil des DKIM-Schlüssels Bis die Änderung der DNS-Daten im Internet allgemein verfügbar ist, dauert es möglicherweise mehrere Stunden. Die TXT-Einträge eines Hosts können Sie mit dem Kommando host -t TXT auslesen, wobei Sie Ihrem Domainnamen die Bezeichnung <selector>._domainkey voranstellen müssen, hier also 201611._domainkey. host -t TXT 201611._domainkey.kofler.info 201611._domainkey.kofler.info descriptive text "v=DKIM1\; k=rsa\; s=email\; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2iAMG1lvjfnXmJKFsfLDCt+PYFc16Q4aQz/dKnpQXSuSvejqb9qGidz0XXItRHXvnzsD7yOly3iconl+kCfY1JbONPKXaObWep7GIXNPIW4tL/jbd886oUd/wTonK50ScCuejelWAQTHs25Q6zH6/ZWWy1vCVIet/+dsqkeJpZ1NFoQrk2uEcx8Yz7NAHcvSt/73Qzl5Czna79" "7955/zX7Bp10e/lATZbVtP6Qu6eC2TMpWx06bEDRZwE4mK0T1iCSHb0wnjLurvKouSnbXAoT+q/dLApTAohIqsmhK0O6z/2Gmo+f8g9JH+PVtyzY4zfvjxsXgWn6kmhdoAtNNuhQIDAQAB" OpenDKIM testen Die geänderten Einstellungen erfordern einen Neustart von OpenDKIM: service opendkim restart Sobald der auf dem Nameserver gespeicherte öffentliche Schlüssel verfügbar ist (das testen Sie mit dem Kommando host -t TXT, siehe oben), können Sie mit dem Kommando opendkim-testkey lokal überprüfen, ob alles korrekt eingerichtet ist. Sofern das Kommando keine Fehlermeldungen liefert, ist alles OK. Die Option -vvv bewirkt, dass das Kommando zumindest einige Debugging-Daten liefert. opendkim-testkey -d kofler.info -s 201611 -vvv opendkim-testkey: using default configfile /etc/opendkim.conf opendkim-testkey: checking key '201611._domainkey.kofler.info' opendkim-testkey: key not secure opendkim-testkey: key OK Key not secure weist darauf hin, dass kein DNSSEC verwendet wird. Das hat aber nichts mit DKIM zu tun. Sollte hingegen die Meldung record not found erscheinen, kann OpenDKIM den erforderlichen Schlüssel nicht finden — dann liegt wirklich ein Konfigurationsproblem vor. Bevor Sie die Postfix-Konfiguration ändern Ich gehe hier davon aus, dass Postfix schon läuft und als MTA aktiv ist. Änderungen im laufenden Betrieb sind natürlich immer heikel. Wenn Sie etwas falsch machen, kann es passieren, dass eintreffende E-Mails abgewiesen werden. Diese sind dann endgültig verloren sind. Deswegen ist es besser, vor Beginn der Umbauten soft_bounce=yes in main.cf einzubauen (und natürlich ständig ein scharfes Auge auf die Logging-Dateien zu werfen). Mit soft_bounce=yes wandelt Postfix alle 5xx-Fehlern (Permanent Failure) in 4xx-Fehler (Persistent Transient Failure) um. Der Sender wird daher nach einiger Zeit einen neuerlichen Zustellversuch unternehmen, die E-Mail ist nicht verloren. Vergessen Sie nicht, nach Fertigstellung und Test der geänderten Konfiguration wieder soft_bounce=no einzustellen! Postfix-Konfiguration für OpenDKIM erweitern Damit Postfix ausgehende E-Mails mit OpenDKIM signiert, muss OpenDKIM als Mail Filter (= Milter) eingerichtet werden. Dazu sind in der Postfix-Konfiguration die Parameter smtpd_milters und non_smtpd_milters vorgesehen. Wenn OpenDKIM der einzige Milter ist, sieht die korrekte Konfiguration so aus: # in /etc/postfix/main.cf milter_default_action = accept milter_protocol = 6 smtpd_milters = inet:localhost:12345 non_smtpd_milters = inet:localhost:12345 Vielleicht gab es bisher schon Milter — dann kommt der OpenDKIM-Milter (getrennt durch ein Komma) eben dazu. Bei meinem Mail-Server ist z.B. zusätzlich auch SpamAssasin aktiv: # in /etc/postfix/main.cf milter_default_action = accept milter_protocol = 6 smtpd_milters = unix:spamass/spamass.sock, inet:localhost:12345 non_smtpd_milters = inet:localhost:12345 Einige Anmerkungen zu den Parametern: milter_default_action = accept bedeutet, dass Postfix auch dann Mails akzeptieren soll, wenn ein Milter defekt ist, nicht reagiert, falsch konfiguriert ist etc. In vielen Anleitungen ist von milter_protocol = 2 die Rede. Das gilt aber nur für alte Postfix-Versionen (älter als 2.6). Bei aktuellen Postfix-Versionen gilt standardmäßig milter_protocol = 6. Die Konfiguration funktioniert also auch, wenn Sie die Einstellung ganz weglassen. Vielleicht fragen Sie sich, was der Unterschied zwischen smtpd_milters und non_smtpd_milters ist: Die smtpd_milters gelten für E-Mails, die über das SMTP-Protokoll geliefert werden. non_smtpd_milters gilt dagegen für lokale E-Mails, die z.B. durch sendmail oder durch ein PHP-Script erzeugt und versendet werden. In der obigen Konfiguration wird für solche Mails auf den Spam-Test verzichtet. DKIM im Zusammenspiel Postfix/OpenDKIM testen Als erstes senden Sie sich selbst eine Mail und werfen dann einen Blick in den Header. Dieser sollte eine Zeile enthalten, die mit DKIM-Signatur beginnt, z.B. wie im folgenden Beispiel: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kofler.info; s=201611; t=1479644038; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; h=To:From:Subject:Date:From; b=VI6TIDLrzG8nAUYWwt5QasKJkkgU+Sv8sPGC1fynSEGo0GSULGgCjVN6KXPfx1rgm 1uX2sWET/oMCpxjBFBVUbM7yHGdllhbADa2SarzYhkoEuNhmo+yxGpXkuh0ttn4z7n OmkLwjrdLafMOaqSBrXcTMg/593b/EQXtouEvHqOG59d0fubIGCJBF6DG5gcITS9CP q9tiVwIDVuQqynL9Crodl+2IObcvl15MeK2ej322qrjrTij6vZOru9SeVno4LNTkQ7 tOT4s14BGLx8aRe5YXZj38AWsR6DxkT6OzM+3TnOhIfX3ZdkufMz8AUnTNuLhViZ1M betE0x1iOi/HQ== Senden Sie nun eine E-Mail von Ihrem eigenen Mail-Server an einen Mail-Server, von dem Sie wissen, dass er DKIM unterstützt und verwendet. Eine gute Wahl ist Google (also Gmail). In der Gmail-Weboberfläche öffnen Sie die E-Mail und führen Original anzeigen aus. Das Ergebnis sollte analog wie beim folgenden Screenshot aussehen: Gmail hat die DKIM-Signatur erfolgreich überprüft Gmail hat die DKIM-Signatur erfolgreich überprüft Key Rotation Aus Sicherheitsgründen wird empfohlen, die DKIM-Schlüssel zumindest vierteljährlich zu wechseln. Das ist allerdings mit hohem Aufwand verbunden: neue Schlüssel generieren, Konfigurationsdateien anpassen, DNS-TXT-Einträge anpassen etc. Zudem müssen bei jedem Wechsel für einige Tage beide Schlüssel in der DNS-Konfiguration bleiben, einerseits, weil sich DNS-Änderungen nur relativ langsam im Internet verbreiten, andererseits, weil E-Mails mitunter erst nach Tagen zugestellt werden (z.B. wenn ein Empfänger-Server vorübergehend nicht erreichbar ist) . Für große Mail-Provider lässt sich der regelmäßige DKIM-Schlüsselwechsel sicher gut automatisieren. Entsprechende Scripts für den Schlüsselwechsel lassen sich natürlich auch für den privaten Mail-Server zusammenbasteln, aber solche Scripts stoßen bei den DNS-Daten an ihre Grenzen: Wer keinen eigenen Nameserver betreibt, wird die DNS-Konfiguration für die eigene Domain zumeist über die Weboberfläche seines Hosters ändern (und da man muss schon dankbar sein, wenn dort überhaupt die Möglichkeit besteht, TXT-Einträge zu verwalten). Das automatisierte Verändern der DNS-TXT-Einträge wird aber kaum möglich sein. Ganz so zwingend wie von manchen Autoren angegeben scheint die Key Rotation nicht zu sein. Wenn Sie eine E-Mail via Gmail versenden, fügt Google die folgenden Zeilen in den Mail-Header ein: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=wPz35cXFAjOtHhgvJJVlP3LVP7on2SV5azh+UjTRZMM=; b=FGSZV2FXjjed0+ByOySbvQMcDM4v+MWXtLDBNU8pgnV6I2k2V0vd6dOpINS+F2e9fl k1sH/EJFeqhit5l8MxhhfCCkP0BNZi3PCQ22i75CPh3ghLz8sjk1W4N03ls/+k3kcPrI VcRoCN5LYlgxSGn4wCSfGFI+ctYiDMw3gGLJoRgTCGA9wLzNEZCSo1Y2agaDDpkgSr3P 4BmcGBE/PzTD8TCWgLw+cRiLDkfA9YvK2A/kR7aQ6292wHkO1S2z6V4jYOir+YWJHQZh fPxWAZLeazJ7DvWoQXpI1W+nMgU84xgdAEGPHOXzEzJ33l8Hgq5jNrw6+M0aXhLrVj5k 8Y9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wPz35cXFAjOtHhgvJJVlP3LVP7on2SV5azh+UjTRZMM=; b=X8pFM/V1hDFQL6oBOoDaYHl9xxUgCZvUmEa4AUjcWe7I9ZTX27wuTH6U926gHVUyY3 fS4K9Iji+K9xFvcSVSU2wY8SDFcy1VlabECONlKX78nhZdWUFuX33C8uiI/Az+ATku9A SDo6yy8xi6jGxPuBQhbQ9lir6jlpakWUV52bnk6GDBvumVfn4rC+N/UMUn4SJo69wTV1 6/Y436G01VkTMoec+yGpm4XFqksWSsoipLfBHQAiVFnGa1l7yDdbpuvnbNZxGvGj2u6G YjU2p3S9P3HcyclvWzDpS7KEU7NjRWXoWzUuGs/yJpOUyS9eXBwn39mzUsiXb2Ds/JTa wHYw== Werfen Sie einen Blick auf die Selektoren der beiden DKIM-Signaturen: Der eine wurde offensichtlich 2012 eingerichtet, der andere 2013 :-)
https://kofler.info/dkim-konfiguration-fuer-postfix/#comments
Reply
Anonymous
Information Epoch 1560640106
Worse is better.
Home
Notebook
Search Engine
Contact us
