Zum Inhalt springen

DMARC: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied

Dirkwagner (Diskussion | Beiträge)

3 Benutzergruppen
150.038 Bearbeitungen
VisuellWikitext
Markierung: Zurückgesetzt
 
(7 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Domain-based Message Authentication, Reporting and Conformance''' ('''DMARC''') ist eine Spezifikation, die entwickelt wurde, um den Missbrauch von [[E-Mail]]s zu reduzieren, wie er etwa bei [[Mail-Spoofing]] vorkommt. DMARC versucht einige seit langem bestehende Unzulänglichkeiten im Zusammenhang mit der [[Authentifizierung]] von E-Mails zu beheben und wurde bei der [[Internet Engineering Task Force|IETF]] zur Standardisierung eingereicht.<ref>[https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ Draft Stand: 15. Juli 2013 im IETF Datatracker]</ref>
'''DMARC''' - Domain-based Message Authentication, Reporting and Conformance
 
== Beschreibung ==
[[DMARC]] ist eine Spezifikation, um den Missbrauch von [[E-Mail]]s zu reduzieren
* [[Mail-Spoofing]], ...
 
DMARC versucht, bestehende Unzulänglichkeiten im Zusammenhang mit der [[Authentifizierung]] von E-Mails zu beheben
* wurde bei der [[Internet Engineering Task Force|IETF]] zur Standardisierung eingereicht


== Überblick ==
== Überblick ==
DMARC baut auf den Techniken [[Sender Policy Framework]] (SPF) und [[DomainKeys Identified Mail]] (DKIM) auf, indem es für eine Absender-Domain festlegt, wie der Empfänger die Authentifizierung von E-Mails durchführen soll und wie im Falle eines Fehlers zu verfahren ist. Während die vorgenannten Techniken beschreiben, wer eine Mail versenden darf (SPF) bzw.&nbsp;sicherstellen, dass diese Mail in bestimmter Weise unverändert vom Absender stammt (DKIM), kann der Absender nach der DMARC-Spezifikation zusätzlich Empfehlungen geben, auf welche Art der Empfänger mit einer Mail umgeht, die in einem oder beiden Fällen nicht den Anforderungen entspricht. Sofern der Empfänger einer E-Mail die DMARC-Spezifikation anwendet, ist dadurch eine konsistente Überprüfung der Authentizität dieser E-Mail gesichert.
DMARC baut auf den Techniken [[Sender Policy Framework]] (SPF) und [[DomainKeys Identified Mail]] (DKIM) auf, indem es für eine Absender-Domain festlegt, wie der Empfänger die Authentifizierung von E-Mails durchführen soll und wie im Falle eines Fehlers zu verfahren ist.  
* Während die vorgenannten Techniken beschreiben, wer eine Mail versenden darf (SPF) bzw.&nbsp;sicherstellen, dass diese Mail in bestimmter Weise unverändert vom Absender stammt (DKIM), kann der Absender nach der DMARC-Spezifikation zusätzlich Empfehlungen geben, auf welche Art der Empfänger mit einer Mail umgeht, die in einem oder beiden Fällen nicht den Anforderungen entspricht.  
* Sofern der Empfänger einer E-Mail die DMARC-Spezifikation anwendet, ist dadurch eine konsistente Überprüfung der Authentizität dieser E-Mail gesichert.


Die DMARC-Richtlinie für eine Absender-Domain kann der Empfänger einem Eintrag im [[Domain Name System]] (DNS) entnehmen.
Die DMARC-Richtlinie für eine Absender-Domain kann der Empfänger einem Eintrag im [[Domain Name System]] (DNS) entnehmen.


Die DMARC-Spezifikation entstand unter anderem auf Initiative von [[Google Inc.|Google]], [[Yahoo]], [[Microsoft]], [[Facebook Inc.|Facebook]], [[AOL]], [[PayPal]] und [[LinkedIn]].<ref>[https://www.golem.de/1201/89399.html Golem-Artikel vom 30. Januar 2012]</ref><ref>[https://www.focus.de/digital/digital-news/anti-phishing-allianz-internet-konzerne-wollen-user-besser-schuetzen_aid_708468.html Focus-Artikel vom 30. Januar 2012]</ref>
Die DMARC-Spezifikation entstand unter anderem auf Initiative von [[Google Inc.|Google]], [[Yahoo]], [[Microsoft]], [[Facebook Inc.|Facebook]], [[AOL]], [[PayPal]] und [[LinkedIn]]


== Aufbau einer DMARC-Richtlinie ==
== Aufbau einer DMARC-Richtlinie ==
DMARC verwendet, so wie auch SPF und DKIM, [[TXT Resource Record|TXT-Records]] im DNS. Für eine Absender-Domain wird auf der Subdomain <code>_dmarc</code> ein [[Resource Record]] angelegt, der die DMARC-Richtlinie für diese Absender-Domain enthält. Folgend ist ein Beispiel dargestellt, wie DMARC im TXT-Record von <code>_dmarc.example.org</code> konfiguriert sein könnte:
DMARC verwendet, so wie auch SPF und DKIM, [[TXT Resource Record|TXT-Records]] im DNS.  
* Für eine Absender-Domain wird auf der Subdomain <code>_dmarc</code> ein [[Resource Record]] angelegt, der die DMARC-Richtlinie für diese Absender-Domain enthält.  


<pre>
Folgend ist ein Beispiel dargestellt, wie DMARC im TXT-Record von <code>_dmarc.example.org</code> konfiguriert sein könnte:
v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@example.org;ruf=mailto:forensik@example.org;adkim=s;aspf=r
v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@example.org;ruf=mailto:forensik@example.org;adkim=s;aspf=r
</pre>


{| class="wikitable"
{| class="wikitable options big"
|-
|-
!Abkürzung !! Bedeutung
!Abkürzung !! Bedeutung
|-
|-
| v || Protokollversion
| v || Protokollversion
|-
|-
| pct || Prozentualer Anteil der zu filternden Mails
| pct || Prozentualer Anteil der zu filternden Mails
|-
|-
| ruf || Forensischer Report wird versandt an:
| ruf || Forensischer Report wird versandt an:
|-
|-
| rua || Aggregierter Report wird versandt an:
| rua || Aggregierter Report wird versandt an:
|-
|-
| p || Anweisung, wie mit Mails der Hauptdomäne zu verfahren ist.
| p || Anweisung, wie mit Mails der Hauptdomäne zu verfahren ist.
|-
|-
| sp || Anweisung, wie mit Mails der Subdomäne zu verfahren ist.
| sp || Anweisung, wie mit Mails der Subdomäne zu verfahren ist.
|-
|-
| adkim || Abgleichmodus für DKIM
| adkim || Abgleichmodus für DKIM
|-
|-
| aspf || Abgleichmodus für SPF
| aspf || Abgleichmodus für SPF
|}
|}


Besondere Bedeutung haben die Abgleichmodi: Für SPF fordert die DMARC-Spezifikation, dass erstens die Überprüfung positiv ausfällt und zweitens die <code>From</code> Kopfzeile der Mail dieselbe Domäne aufweist, wie im SPF-Record hinterlegt. Für DKIM wird gefordert, dass die Signatur gültig ist und zusätzlich die dort genannte Domäne dieselbe ist, wie in der <code>From</code> Kopfzeile der Mail. Als Abgleichmodi sind <code>s</code> für 'strict' bzw.&nbsp;<code>r</code> für 'relaxed' vorgesehen. Bei 'strict' müssen die Domänen exakt übereinstimmen, bei 'relaxed' darf die <code>From</code> Kopfzeile auch eine Subdomäne enthalten. Über die Auswertung erhält der Sender einen täglichen Report an die genannte Adresse.
Besondere Bedeutung haben die Abgleichmodi: Für SPF fordert die DMARC-Spezifikation, dass erstens die Überprüfung positiv ausfällt und zweitens die <code>From</code> Kopfzeile der Mail dieselbe Domäne aufweist, wie im SPF-Record hinterlegt.  
* Für DKIM wird gefordert, dass die Signatur gültig ist und zusätzlich die dort genannte Domäne dieselbe ist, wie in der <code>From</code> Kopfzeile der Mail.  
* Als Abgleichmodi sind <code>s</code> für 'strict' bzw.&nbsp;<code>r</code> für 'relaxed' vorgesehen.  
* Bei 'strict' müssen die Domänen exakt übereinstimmen, bei 'relaxed' darf die <code>From</code> Kopfzeile auch eine Subdomäne enthalten. Über die Auswertung erhält der Sender einen täglichen Report an die genannte Adresse.


Die [[Policy]] (hier abgekürzt als 'p' bzw.&nbsp;'sp' für Subdomains) legt schließlich fest, wie der Empfänger mit der Mail verfahren soll, wenn die Überprüfung scheitert. Vorgesehene Modi hierfür sind 'none', 'quarantine' und 'reject'. 'none' (auch als Monitormodus bezeichnet) wird in der Regel zum Testen verwendet und macht dem Empfänger keine Vorschriften über die Verfahrensweise. 'quarantine' verlangt die Kennzeichnung der Mails als Spam, 'reject' verlangt, die Mail zu verwerfen.
Die [[Policy]] (hier abgekürzt als 'p' bzw.&nbsp;'sp' für Subdomains) legt schließlich fest, wie der Empfänger mit der Mail verfahren soll, wenn die Überprüfung scheitert.  
* Vorgesehene Modi hierfür sind 'none', 'quarantine' und 'reject'. 'none' (auch als Monitormodus bezeichnet) wird in der Regel zum Testen verwendet und macht dem Empfänger keine Vorschriften über die Verfahrensweise. 'quarantine' verlangt die Kennzeichnung der Mails als Spam, 'reject' verlangt, die Mail zu verwerfen.


== Kritik ==
== Kritik ==
DMARC überprüft den <code>From</code>-Header der E-Mails und stellt an diesen strenge Anforderungen (sog. "alignment"). Im Zusammenhang mit E-Mail-Weiterleitungen und [[Mailingliste]]n ist dies problematisch, da DMARC verlangt, dass die Absenderangabe im <code>From</code>-Header der E-Mail durch die Adresse der Mailingliste oder die eigene Adresse ersetzt wird.<ref>[https://sys4.de/de/blog/2013/08/11/mailman-dmarc-konform-betreiben/ Nachrichten DMARC-konform mit Mailman verteilen]</ref> Beispiel:
DMARC überprüft den <code>From</code>-Header der E-Mails und stellt an diesen strenge Anforderungen (sog. "alignment").  
* Im Zusammenhang mit E-Mail-Weiterleitungen und [[Mailingliste]]n ist dies problematisch, da DMARC verlangt, dass die Absenderangabe im <code>From</code>-Header der E-Mail durch die Adresse der Mailingliste oder die eigene Adresse ersetzt wird.<ref>[https://sys4.de/de/blog/2013/08/11/mailman-dmarc-konform-betreiben/ Nachrichten DMARC-konform mit Mailman verteilen]</ref> Beispiel:


<pre>
From: Nutzer <user@example.org>
From: Nutzer <user@example.org>
Subject: ...
Subject: ...
To: wikide-l@lists.wikimedia.org
To: wikide-l@lists.wikimedia.org
</pre>


muss entsprechend DMARC durch die Mailinglistensoftware folgendermaßen abgeändert werden:
muss entsprechend DMARC durch die Mailinglistensoftware folgendermaßen abgeändert werden:


<pre>
From: Nutzer via wikide-l <wikide-l@lists.wikimedia.org>
From: Nutzer via wikide-l <wikide-l@lists.wikimedia.org>
Subject: ...
Subject: ...
To: wikide-l@lists.wikimedia.org
To: wikide-l@lists.wikimedia.org
</pre>


Die E-Mail-Adresse des wirklichen Absenders wird bei dieser Ersetzung komplett entfernt, so dass es nicht mehr möglich ist, den tatsächlichen Absender zu ermitteln oder mit dem Absender direkt in Kontakt zu treten. Eine Option besteht darin, dass die Mailingliste den ursprünglichen Absender in alternativen Kopfdaten wie den <code>Reply-To</code>-Header einfügt, was aber ebenfalls zu Problemen führen kann. Eine Lösung für dieses Problem existiert nicht.
Die E-Mail-Adresse des wirklichen Absenders wird bei dieser Ersetzung komplett entfernt, so dass es nicht mehr möglich ist, den tatsächlichen Absender zu ermitteln oder mit dem Absender direkt in Kontakt zu treten.  
* Eine Option besteht darin, dass die Mailingliste den ursprünglichen Absender in alternativen Kopfdaten wie den <code>Reply-To</code>-Header einfügt, was aber ebenfalls zu Problemen führen kann.  
* Eine Lösung für dieses Problem existiert nicht.


DMARC fordert Änderungen an jeder Mailinglisten- und Weiterleitungssoftware. Das Konzept von DMARC hat dementsprechend auch zu Problemen bei Mailinglisten geführt.<ref>[https://www.heise.de/newsticker/meldung/DMARC-Policy-Yahoo-killt-Mailinglisten-Mitgliedschaften-2168857.html Heise Newsletter: DMARC-Policy: Yahoo killt Mailinglisten-Mitgliedschaften]</ref>
DMARC fordert Änderungen an jeder Mailinglisten- und Weiterleitungssoftware.  
* Das Konzept von DMARC hat dementsprechend auch zu Problemen bei Mailinglisten geführt


== Normen und Standards ==
== Normen und Standards ==
* RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC), 2015
* [[RFC 7489]] - Domain-based Message Authentication, Reporting, and Conformance (DMARC), 2015


== Weblinks ==
== Weblinks ==
Zeile 71: Zeile 84:
== Quellen ==
== Quellen ==
# https://de.wikipedia.org/wiki/DMARC
# https://de.wikipedia.org/wiki/DMARC
== DMARC ==
=== DMARC ===
DMARC steht für Domain-based Message Authentication, Reporting and Conformance und nutzte DNS-Einträge, die in Verbindung mit SPF und DKIM arbeiten.
Es mehren sich die Hinweise, dass Domains mit einem DMARC-Eintrag seltener zum Phising missbraucht werden, dass viele große Provider dank [http://www.msxfaq.de/spam/filter-spf.htm SPF] bzw. [http://www.msxfaq.de/spam/filter-dkim.htm DKIM] solche Fälschungen nicht nur erkennen, sondern anhand DMARC den Inhaber auch informieren und diese durchaus über den Provider dagegen vorgehen.
Der Ausgangspunkt von DMARC ist der Schutz der eigenen Domäne gegen Missbrauch von anderen Absendern, indem Sie als Inhaber die entsprechenden Vorarbeiten leisten, damit die Empfänger prüfen können, ob der Absender für diese Domäne auch senden darf. Es gibt mit [http://www.msxfaq.de/spam/filter-spf.htm SPF] oder [http://www.msxfaq.de/spam/filter-rmx.htm RMX] schon ein Verfahren, um die "Source-IP" von Systemen zu veröffentlichen, die für eine Domäne als Absenderhost agieren. Allerdings limitiert dies die Möglichkeiten Mails z.B. über Relays oder Provider zu versenden, bei denen Sie Mailserver-Adressen ändern oder erweitern. Mit [http://www.msxfaq.de/spam/filter-dkim.htm DKIM] gibt es daher einen Weg, wie eine Mail selbst signiert werden kann. Es ist keine klassische digitale Signatur mit [http://www.msxfaq.de/signcrypt/smimepgp.htm SMime oder PGP] aber sehr ähnlich. Die Integrität der Mail wird damit sichergestellt, d.h. der Inhalt gegen Veränderungen geschützt und der Absender bestätigt.
DMARC geht aber weiter und veröffentlich Informationen, wie die Empfänger Sie als Domaininhaber über missbrauch informieren sollen. Die Empfänger prüfen also nicht nur die eingehenden Mails gegen SPF und DKIM-Parameter, sondern über DMARC senden Sie auch Statusmeldungen und Zusammenfassungen an die hinterlegten Rückantwortadressen.
Als Domaininhaber mit einer passenden Verarbeitung erhalten Sie also direkt ein Feedback, wir stark ihre Domäne von fremden Personen unberechtigt genutzt wird. Es dient also primär dem Schutz ihrer Marke. Interessant wird das natürlich, wenn die großen Mailempfänger und Hoster nicht nur SFP und DKIM als Spamfilter nutzen, sondern auch die Daten aus dem DMARC-Eintrag verwenden. Es ist also kein neuer Spamfilter sondern primär addiert DMARC einen Weg, wie Missbrauch auch bekannt werden kann. Aber wenn man DMARC glauben kann, sind das zumindest in den USA schon sehr viele Postfächer.
As of early 2013 DMARC had been deployed to protect roughly 2 billion email accounts - over 60% of consumer mailboxes globally, and over 80% of consumer mailboxes in the united States. During the first 45 days of initial monitoring, Twitter saw nearly 2.5 billion messages spoofing its domains. Twitter reports ~110 million messages/day were spoofing its domains prior to deploying DMARC, redUCEd to only 1,000/day after publishing a "reject" policy. Quelle: [http://www.dmarc.org/ http://www.dmarc.org/]
; Achtung:
Ein DMARC-Eintrag auf einer Domäne gilt auch für Subdomains !. DMARC-Prüfer haben dazu eine Liste der "Root-Domains", um z.B. "<firma>.de" von "<firma.co.uk>" zu unterscheiden.
; Achtung:
Ein gesetzter DMARC Eintrag erfordert für die Domäne und alle Subdomains auch einen SPF-Eintrag. Fehlt dieser, dann lehnen viele Firmen die Mails ab, wenn die SPF-Prüfung bei gesetztem DMARC-Eintrag nicht möglich ist.
Die Zahlen sind beeindruckend, aber DMARC ist nur die Einstellung, dass die Empfänger mit DMARC-Support an die Domaininhaber auch die Zahlen melden. Der Filter solche "Phishing-Mails" basiert auf [http://www.msxfaq.de/spam/filter-spf.htm SPF] und/oder [http://www.msxfaq.de/spam/filter-dkim.htm DKIM] und gibt es schon länger.
==== Der DMARC Eintrag ====
Dazu ist ein DMARC-Eintrag erforderlich. Aus Sicht von DNS ist es einfach ein TXT-Record, der den Namen "_dmarc" trägt. Ein Eintrag für die MSXFAQ könnte also lauten: (alles ohne Umbrüche und bitte eine gültige Mailadresse verwenden):
Warnung:Dies ist ein Beispiel damit ich für meine Domäne die Reports bekomme. Bitte nutzen Sie als Mailadresse für ihre Domains bitte ihre eigene Adresse oder einen Dienstleister.
_dmarc.msxfaq.de TXT ="
v=DMARC1;
p=none;
pct=100;
rua=mailto:dmarc-aggregate@msxfaq.de.net;
ruf=mailto:dmarc-forensik@msxfaq.de.net;
adkim=s;
aspf=r
"
Die Felder können unterschiedliche Bedeutung haben:
{| class="wikitable options big"
|-
| | '''Feld'''
| | '''Bedeutung der Werte'''
|-
| | v=DMARC1
| | Kennzeichnet die Version. Aktuell ist Version 1 gültig.
|-
| | p=sp=
| | Policy oder "Subdomain Policy"Der Wer hinter "p=" kennzeichnet, wie der Empfänger mit Mails umgehen soll, die nicht korrekt mit SPF oder DKIM überprüft werden konnten. Der Eintrag "sp=" beschreibt das Vorgehen für Sub-Domains. mögliche Werte sind:* noneDer Empfänger soll die Mail trotzdem weiter senden
* quarantineDer Empfänger soll die Mail annehmen aber in Quarantäne legen
* rejectDer Empfänger soll die Mail einfach auf SMTP-Level ablehnen
|-
| | pct=
| | Prozentsatz der Mails, die entsprechend von "p" gefiltert werden sollen. Wenn jemand aber mit DMARC einen Eintrag addiert und korrekt alle Mails gemäß SPF und DKIM versendet, sollte kein Problem mit einer "100" hier haben
|-
| | rua
| | Receive or aggregated ReportDer Empfänger sendet an diese Adresse oder Adressen einen "Summenbericht". Das passiert in der Regel einmal am Tag
Achtung: Wenn der Empfänger in einer anderen SMTP-Domäne ist, dann senden die DMARC-Aggregatoren die Mail in der Regel erst dann, wenn die Empfängerdomäne ihr Einverständnis gegeben hat. DAs macht diese ebenfalls per DNS-Eintrag.msxfaq.de._report._dmarc.netatwork.de&nbsp;&nbsp; TXT "v=DMARC1"So gibt die Domäne "netatwork.de" bescheid, dass die DMARC-Report für msxfaq.de annehmen wird.
|-
| | ruf
| | receiver of forensic reportAn diese Mailadresse sendet der Empfänger einen forensischen Report über die fehlerhafte Mail. Als Betreiber können Sie dann gut erkennen, welcher angebliche Absender an das Ziel versucht hat, eine Mail mit ihrer Domain zu senden. So können Sie "vergessene" Versender erkennen und korrigieren oder versuchen gegen Missbrauch vorzugehen.
Auch für hier verwendete Adressen anderer Domänen muss der Empfänger seine Bereitschaft signalisieren.
|-
| | adkim
| | Abgleicheinstellung für DKIM.Hiermit können Sie vorgeben, wie streng die Prüfung bezüglich DKIM sein soll.* s=StrictDie Domänen müssen exakt übereinstimmen
* r=RelaxedDie Kopfzeile im SMTP-Header darf auch eine Subdomain sein, z.B. "newsletter@msxfaq.de"
|-
| | aspf
| | Dieser Parameter steuert analog die SPF-Auswertung.* s=StrictDie Domänen müssen exakt übereinstimmen
* r=RelaxedDie Kopfzeile im SMTP-Header darf auch eine Subdomain sein, z.B. "newsletter@msxfaq.de"
|-
|}
Für eine erfolgreiche DMARC-Validierung reicht es, wenn eines der beiden Checks, SPF oder DKIM erfolgreich war. DKIM wird überwiegend genutzt, wenn die Authentizität der Mail auch über Relaisstationen gewährleistet werden soll, aber erlaubt kein Umschreiben der Absender (Stichwort Mailingliste). Hier ist dann SPF besser, wenngleich dann die ausgehenden IP-Adressen gepflegt sein müssen.
Wer mit DMARC anfängt, kann also erst einmal den Eintrag setzen aber stellt also Aktion z.B. "p=none" und schaut sich die Meldungen einige Zeit an.* DMARC Record Assistant [http://kitterman.com/dmarc/assistant.html http://kitterman.com/dmarc/assistant.html]&nbsp;
* dmarc.org Deployment Tools[https://dmarc.org/resources/deployment-tools/ https://dmarc.org/resources/deployment-tools/]
* DMARC Wizard[https://www.unlocktheinbox.com/dmarcwizard/ https://www.unlocktheinbox.com/dmarcwizard/]
* DMARC Record Creator[https://app.agari.com/dmarc/record_creator https://app.agari.com/dmarc/record_creator]
* Build Your DMARC Record in 15 Minutes [https://blog.returnpath.com/build-your-dmarc-record-in-15-minutes-v2/ https://blog.returnpath.com/build-your-dmarc-record-in-15-minutes-v2/]
* HOWTO - Define a DMARC Record[http://www.zytrax.com/books/dns/ch9/dmarc.html http://www.zytrax.com/books/dns/ch9/dmarc.html]
==== Beispieleinträge von Firmen ====
Ob eine Firma DMARC einsetzt, können Sie einfach per NSLOOKUP ermitteln.
C:\>nslookup -q=TXT _dmarc.microsoft.com
Server: dns.netatwork.de
Address: 192.168.100.1
Nicht autorisierende Antwort:
_dmarc.microsoft.com text =
"v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"
Wenn man ein paar bekannte Firmen anfragt, dann sieht man durchaus einige interessante Einträge:
_dmarc.microsoft.com text = "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"
_dmarc.outlook.com text = "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@auth.returnpath.net; ruf=mailto:d@ruf.agari.com,mailto:dmarc_afrf@auth.returnpath.net; fo=1"
_dmarc.mail.ru text = "v=DMARC1;p=none;rua=mailto:d@rua.agari.com,mailto:dmarc_rua@corp.mail.ru,mailto:dmarc_agg@auth.returnpath.net;ruf=mailto:d@ruf.agari.com,mailto:dmarc_afrf@auth.returnpath.net;fo=1;"
_dmarc.yahoo.com text = "v=DMARC1; p=reject; sp=none; pct=100; rua=mailto:dmarc-yahoo-rua@yahoo-inc.com, mailto:dmarc_y_rua@yahoo.com;"
_dmarc.google.com text = "v=DMARC1; p=quarantine; rua=mailto:mailauth-reports@google.com"
_dmarc.aol.com text = "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
_dmarc.bahn.de text = "v=DMARC1; p=none; rua=mailto:dmarc.reporting@deutschebahn.com;"
_dmarc.dell.com text = "v=DMARC1; p=none; rua=mailto:dmarc-dell-rua@sonicwall.com; ruf=mailto:dmarc-dell-ruf@sonicwall.com"
_dmarc.amazon.com text = "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@bounces.amazon.com; ruf=mailto:dmarc-reports@bounces.amazon.com"
_dmarc.dhl.de text = "v=DMARC1;p=none;rua=mailto:dhl@rua.agari.com;ruf=mailto:dhl@ruf.agari.com"
_dmarc.ups.de cname = _dmarcmonitor.ups.com
_dmarcmonitor.ups.com text = "v=DMARC1; p=none; rua=mailto:ups@rua.agari.com; ruf=mailto:ups@ruf.agari.com; fo=1"
_dmarc.ups.com text = "v=DMARC1; p=reject; rua=mailto:ups@rua.agari.com; ruf=mailto:ups@ruf.agari.com; fo=1"
_dmarc.ing-diba.de text = "v=DMARC1; p=none; rua=mailto:SecurityServices@ing-diba.de"
_dmarc.ebay.de text = "v=DMARC1; p=none; rua=mailto:dmarc_agg@auth.returnpath.net; ruf=mailto:dmarc_afrf@auth.returnpath.net; rf=afrf; pct=100"
_dmarc.paypal.com text "v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com"
Es ist gut zu sehen, dass die großen Versender und Logistiker, aber auch die Internet-Firmen hier Vorreiter spielen. Interessant sind hier natürlich insbesondere die Einträge zum RUF und RUA´. Scheinbar nutzen sehr viele die Dienste von agari.com, um die Ergebnisse von "Domainmissbrauch" zentral zu erkennen. Auf deren Webseite finden sich Daten wie
In fact, we get data from 85% of all email inboxes in the US and 60% of email inboxes globally.Quelle: [http://agari.com/what-we-do/ http://agari.com/what-we-do/]
Auf der anderen Seite haben gerade deutsche Domains hier noch Nachholbedarf. (Stand Okt 2014). Ich habe einfach ein paar Namen einmal durch probiert. Gerade die großen Provider scheinen hier eher auf ihr "E-Mail Made in Germany" zu setzen.
_dmarc.t-online.de text = nicht vorhanden
_dmarc.telekom.de text = nicht vorhanden
_dmarc.gmx.de text = nicht vorhanden
_dmarc.web.de text = nicht vorhanden
_dmarc.basf.com text = nicht vorhanden
_dmarc.siemens.de text = nicht vorhanden
_dmarc.rwe.de text = nicht vorhanden
_dmarc.bsi.de text = nicht vorhanden
_dmarc.ccc.de text = nicht vorhanden
_dmarc.deutsche-bank.de text = nicht vorhanden
_dmarc.netbank.de text = nicht vorhanden
_dmarc.allianz.de text = nicht vorhanden
_dmarc.aldi.de text = nicht vorhanden
_dmarc.tchibo.de text = nicht vorhanden
_dmarc.ebay-kleinanzeigen.de text = nicht vorhanden
Interessant ist auch, dass die Banken noch nicht dabei sind.
Es ist wie gesagt nicht schlimm, wenn man DMARC nicht unterstützt. Letztlich muss jede Firma selbst entscheiden, ob ihr Mailsystem die Mails per DKIM signieren kann und dann per DMARC dies den Empfängern mitgeteilt wird. Ich persönlich würde ja eh viel mehr auf eine echte S/MIME-Signatur setzen aber es ist durchaus eine Option den eigenen Namen und die Marke zu schützen.
==== Reporting ====
Die Rückmeldungen der entfernten Server, an die Mails mit ihrer Domain gesendet werden, kommen ganz klassisch per Mail und nicht "modern" über Webservices. Entsprechend muss die im DMARC-Record hinterlegte Mailadresse natürlich einem Postfach zugeordnet sein.
Das muss aber kein Postfach in ihrer Domäne sein und wenn Sie sich die DMARC-Records der oben genannten Firmen anschauen, dann erkennen Sie eine Häufung der Firmen "agari.com" und "returnpath.net". Beide sind Dienstleister die solche Rückläufer einsammeln und die Auswertung als "Hosted Service" ihren Kunden anbieten. Sie können die Mails aber natürlich auch in ein eigenes Postfach ablegen.
Achtung:Als deutsche Firma sollten Sie überlegen ob sie selbst DMARC-Reports an andere Firmen senden oder in welcher Weise Sie die Reports aus Datenschutzgründen verwässern.[https://www.eco.de/2015/pressemeldungen/phishing-abwehr-datenschutzrechtliche-bedenken-gutachten-empfiehlt-redacting.html https://www.eco.de/2015/pressemeldungen/phishing-abwehr-datenschutzrechtliche-bedenken-gutachten-empfiehlt-redacting.html]&nbsp;
Ich habe dazu bei einer meiner Spiel-Domains einfach mal einen _DMARC-Eintrag addiert und als RUF/RUA-Adresse meine normale Mailbox angegeben. Hier der Mustereintrag
C:\>nslookup -q=TXT _dmarc.frankcarius.de
Server: fritz.box
Address: 192.168.178.1
Nicht autorisierende Antwort:
_dmarc.frankcarius.de text =
"v=DMARC1;p=none;pct=100;rua=mailto:frank.carius@netatwork.de;ruf=mailto:frank.carius@netatwork.de;adkim=s;aspf=r"
Dann habe ich eine Testmal an eine outlook.com-Adresse gesendet. Die kam durch, weil im DMARC-Eintrag ein "p=none" steht.
[[Image:Bild2.png]]
Aber nun habe ich gespannt auf die Mail in dem angegeben Postfach gewartet. Die kam dann auch kurz nach Mitternacht:
[[Image:Bild3.png]]
Der Body der Mail war leer und als Anlage war eine ZIP-Datei angehängt. In der war wiederum genau eine XML-Datei, in der z.B.: die vom Empfänger gesehenen Einstellungen wieder gegeben sind und die Detaildaten der Verbindung. Hier war es genau eine von der Source-IP "80.66.20.28".
<?xml version="1.0" encoding="utf-8"?>
<feedback>
<report_metadata>
<org_name>Microsoft Corp.</org_name>
<email>dmarcrep@microsoft.com</email>
<report_id>e7c320ad9ac24ac9a153ac17065a2db9@hotmail.com</report_id>
<date_range>
<begin>1414015200</begin>
<end>1414101600</end>
</date_range>
</report_metadata>
<policy_published>
<domain>frankcarius.de</domain>
<adkim>s</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>80.66.20.28</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>frankcarius.de</header_from>
</identifiers>
<auth_results>
<spf>
<domain>frankcarius.de</domain>
<result>none</result>
</spf>
<dkim>
<domain>frankcarius.de</domain>
<result>none</result>
</dkim>
</auth_results>
</record>
</feedback>
Man sieht auch, dass sowohl die SFP- als auch die DKIM-Abfrage fehlgeschlagen sind. Leider konnte ich im Header der Mail keine Hinweise darauf sehen, dass diese Stausmail per DKIM gesichert war. So kann ich nicht sicher sein, dass nicht jemand anderes mit einen StatusBericht sendet und damit die daraus generierten Statistiken verändert.
Ein kleiner PowerShell-Einzeiler liefert eine Tabelle der Statusmeldungen:
[xml]$report=Get-Content C:\temp\temp\report.xml
$report.feedback.record | select {$_.row.source_ip}, {$_.identifiers.header_from}, {$_.auth_results.spf.result}, {$_.row.policy_evaluated.spf}
&nbsp;
$_.row.source_ip $_.identifiers.head $_.auth_results.spf $_.row.policy_evalu
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;er_from .result ated.spf
<nowiki>---------------- </nowiki> <nowiki>------------------- ------------------- -------------------</nowiki>
117.111.120.11 msxfaq.com pass pass
117.111.120.11 de.msxfaq.com none &nbsp;&nbsp;&nbsp;fail
93.199.90.91 msxfaq.com pass pass
93.199.90.91 de.msxfaq.com none fail
93.199.90.94 msxfaq.com pass pass
93.199.90.94 de.msxfaq.com none fail
62.242.148.41 de.msxfaq.com none fail
Wer also mag, kann z.B. alle Anlagen aus dem DMARC-Sammelpostfach abfischen und verarbeiten.
==== Störpotential beim Reportpostfach ====
Für Spammer sind diese Adressen zwar leicht per DNS "einzusammeln" aber natürlich kein lohnendes Ziel. Diese Mails wird wohl nie ein unbedarfter Anwender lesen. Damit niemand gefälschte Reports darunter mischt, werden natürlich auch diese Mails per SPF/DKIM gesichert, so dass Fälschungen früh aussortiert werden können.
Und selbst dann wird der verarbeitende Prozess eine Mail nur dann verstehen, wenn Sie sich an das Format hält. Dennoch scheint es Spammer zu geben, die entweder die Mailadresse hier auf der Webseite eingesammelt haben oder tatsächlich den DNS-Eintrag parsen. Auf jeden Fall kommt tatsächlich Spam an diese Adresse.
[[Image:Bild4.png|top]]
Es gibt aber dennoch ein Störpotential. Es ist heute sehr einfach eine Domäne im Internet zu registrieren und einen DMARC-Eintrag zu addieren, in dem eine Mailadresse einer anderen Person hinterlegt wird, die ich stören möchte. Wenn der Mailserver dieses Ziels nicht SPF/DKIM prüft und gefälschte Report-Mails verwirft, dann wird er die Mails in das Postfach zustellen.
Wenn ich dann absichtlich eine Mail mit dieser Absenderdomäne z.B. an einen Server sende, der SFP/DKIM prüft und die Reports anhand des DMARC-Eintrags erstellt, dann sendet dieser Server eine Mail an die hinterlegte Adresse.
Das kann schon störend sein, wenn ich von einem PC eben tausende "kleine" Mails an viele Mailserver mit SPF/DKIM-Support sende und diese dann eine deutlich größere "Statusmail" an die DMARC-Reportadresse sende. Ob das schon für einen DDoS per SMTP reicht ?
==== DMARC bei 1&1 ====
Seit Anfang 2016 hat die 1und1-Gruppe den Schutz gegen Spam mittels [http://www.msxfaq.de/spam/filter-spf.htm SPF] noch etwas verstärkt. Der Versuch aber einen DMARC-Eintrag zu addieren, schlägt leider fehlt. Technisch musste man dazu bei 1und1 früher eine "Subdomain" anlegen aber im neuen Control-Center können Sie auf der Domäne direkt einen TXT-Record addieren. Allerdings ist die aktuell (Jun 2016) nicht möglich, da die Eingabe eine Validierung macht und ein einfaches _dmarc.<domain> nicht erlaubt ist.
[[Image:Bild5.png|top]]
Leider kann ich auch keine "Subdomain" mit einem "_" ersatzweise anlegen. Hier muss 1und1 wohl noch etwas korrigieren, damit auch DMARC-Einträge möglich werden* TXT-Record für eine Domain setzen oder löschen http://hilfe-center.1und1.de/hosting/domain-c10082638/dns-einstellungen-c10082657/txt-record-fuer-eine-domain-setzen-oder-loeschen-a10792649.html
* SPF-Record für Domain setzen [http://hilfe-center.1und1.de/hosting/domain-c10082638/dns-einstellungen-c10082657/spf-record-fuer-domain-setzen-a10795604.html http://hilfe-center.1und1.de/hosting/domain-c10082638/dns-einstellungen-c10082657/spf-record-fuer-domain-setzen-a10795604.html]&nbsp;
==== DMARC Auswertungen ====
Die Rückmeldungen von Firmen, die DMARC-Einträge auswerten, kommen in dem angegebenen Postfach als XML-Datei an. Sicher könnten Sie nun das Postfach lesen und auswerten, sei es per Outlook oder mit einem PowerShell-Skript. Aber dann steht immer noch die grafische Auswertung an. Im Zeichen der Cloud gibt es einige Anbieter, die ihnen die Arbeit hier abnehmen. Sie lassen die Reports einfach an diesen Anbieter senden oder leiten ihre Reports weiter. Per Browser&nbsp;können Sie dann entsprechend aufbereitet Reports betrachten.
Die folgende Liste von DMARC-Auswertestellen ist keine repräsentative Marktübersicht und darf nicht als Empfehlung meinerseits missverstanden werden.* DMarcian[https://dmarcian.com/ https://dmarcian.com/]
* Agari[https://www.agari.com/ https://www.agari.com/]
* ReturnPath.net[https://returnpath.com/ https://returnpath.com/]
* DMARC Analyzer[https://www.dmarcanalyzer.com/ https://www.dmarcanalyzer.com/]
==== Weitere Links ====
* SPF http://www.msxfaq.de/spam/filter-spf.htm
* RMX http://www.msxfaq.de/spam/filter-rmx.htm
* DKIM http://www.msxfaq.de/spam/filter-dkim.htm
* SMime oder PGP http://www.msxfaq.de/signcrypt/smimepgp.htm
* DANE/TLSA http://www.msxfaq.de/signcrypt/dane_tlsa.htm
* Phishing-Abwehr: datenschutzrechtliche Bedenken – Gutachten empfiehlt Redacting https://www.eco.de/2015/pressemeldungen/phishing-abwehr-datenschutzrechtliche-bedenken-gutachten-empfiehlt-redacting.html&nbsp;
* DMARC.org - Domain-based Message Authenticationwww.dmarc.org
* DMARC – Wikipedia http://en.wikipedia.org/wiki/DMARChttp://de.wikipedia.org/wiki/DMARC
* Understand DMARC - Google Apps Administrator Helphttps://support.google.com/a/answer/2466580
* Everything about DMARC https://support.sendgrid.com/hc/en-us/articles/200182958-Everything-about-DMARC-
* SENDERID, SPF, DKIM AND DMARC IN EXCHANGE 2016https://jaapwesselius.com/2016/08/19/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-i/ https://jaapwesselius.com/2016/08/22/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-ii/ https://jaapwesselius.com/2016/08/23/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-iii/
=== DMARC ===
Domain-based Message Authentication, Reporting and Conformance, kurz DMARC, ist eine Spezifikation, die entwickelt wurde, um Missbrauch von [https://de.wikipedia.org/wiki/E-Mail E-Mails] zu reduzieren. Sie versucht, einige seit langem bestehende Unzulänglichkeiten im Zusammenhang mit [https://de.wikipedia.org/wiki/Authentifizierung Authentifizierungsproblemen] beim E-Mail-Versand zu beheben. Sie wurde bei der [https://de.wikipedia.org/wiki/Internet_Engineering_Task_Force IETF] zur Standardisierung eingereicht.[https://de.wikipedia.org/wiki/DMARC#cite_note-1 [1]]
==== Überblick ====
DMARC baut auf den bekannten Techniken [https://de.wikipedia.org/wiki/Sender_Policy_Framework SPF] (Sender Policy Framework) und [https://de.wikipedia.org/wiki/DomainKeys DKIM] (DomainKeys Identified Mail) auf, indem es festlegt, wie der Empfänger von E-Mails die Authentifizierung durchführen soll.
Während die vorgenannten Techniken beschreiben, wer eine Mail versenden darf (SPF) bzw. dass diese Mail in bestimmter Weise unverändert vom Absender stammt (DKIM), kann der Absender nach der DMARC-Spezifikation zusätzlich Empfehlungen geben, auf welche Art der Empfänger mit einer Mail umgeht, die in einem oder beiden Fällen nicht den Anforderungen entspricht.
Sofern der Empfänger einer E-Mail die DMARC-Spezifikation anwendet, ist dadurch eine konsistente Überprüfung der Authentizität dieser E-Mail gesichert.
==== Aufbau eines Eintrags ====
DMARC bedient sich hierzu, wie auch SPF und DKIM, der [https://de.wikipedia.org/wiki/TXT_Resource_Record TXT-Records] des [https://de.wikipedia.org/wiki/Domain_Name_System Domain Name Systems] (DNS). Dort wird zusätzlich zu den SPF- und DKIM-Einträgen ein weiterer [https://de.wikipedia.org/wiki/Resource_Record RR-Eintrag] mit zum Beispiel folgendem Aufbau angelegt:
v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@example.org;ruf=mailto:forensik@example.org;adkim=s;aspf=r
{| class="wikitable options big"
|-
| | '''Abkürzung'''
| | '''Bedeutung'''
|-
| | v
| | Protokollversion
|-
| | pct
| | Prozentualer Anteil der zu filternden Mails
|-
| | ruf
| | Forensischer Report wird versandt an:
|-
| | rua
| | Aggregierter Report wird versandt an:
|-
| | p
| | Wie wird mit Mails der Hauptdomäne verfahren?
|-
| | sp
| | Wie wird mit Mails der Subdomäne verfahren?
|-
| | adkim
| | Abgleichmodus für DKIM
|-
| | aspf
| | Abgleichmodus für SPF
|-
|}
Besondere Bedeutung haben die Abgleichmodi. Für SPF fordert die Spezifikation, dass erstens die Überprüfung positiv ausfällt und zweitens die From: Kopfzeile der Mail dieselbe Domäne aufweist, wie im SPF-Record hinterlegt. Für DKIM wird gefordert, dass die Signatur gültig ist und zusätzlich die dort genannte Domäne dieselbe ist, wie in der From: Kopfzeile der Mail. Als Abgleichmodi sind s='strict' bzw. r='relaxed' vorgesehen. Bei 'strict' müssen die Domänen exakt übereinstimmen, bei 'relaxed' darf die From: Kopfzeile auch eine Subdomäne enthalten. Über die Auswertung erhält der Sender einen täglichen Report an die genannte Adresse.
Die [https://de.wikipedia.org/wiki/Policy Policy] (hier abgekürzt als 'p' bzw. 'sp' für Subdomains) legt schließlich fest, wie der Empfänger mit der Mail verfahren soll, wenn die Überprüfung scheitert. Vorgesehene Modi hierfür sind 'none', 'quarantine' und 'reject'. 'none' (auch als Monitormodus bezeichnet) wird in der Regel zum Testen verwendet und macht dem Empfänger keine Vorschriften über die Verfahrensweise. 'quarantine' verlangt die Kennzeichnung der Mails als Spam, 'reject' verlangt, die Mail zu verwerfen.
Die DMARC-Spezifikation entstand unter Anderem auf Initiative von [https://de.wikipedia.org/wiki/Google_Inc. Google], [https://de.wikipedia.org/wiki/Yahoo Yahoo], [https://de.wikipedia.org/wiki/Microsoft Microsoft], [https://de.wikipedia.org/wiki/Facebook_Inc. Facebook], [https://de.wikipedia.org/wiki/AOL AOL], [https://de.wikipedia.org/wiki/PayPal PayPal] und [https://de.wikipedia.org/wiki/LinkedIn LinkedIn].[https://de.wikipedia.org/wiki/DMARC#cite_note-2 [2]][https://de.wikipedia.org/wiki/DMARC#cite_note-3 [3]]
==== Kritik ====
DMARC überprüft den <tt>From</tt>-Header der E-Mails und stellt an diesen strenge Anforderungen (sog. „alignment“). Im Zusammenhang mit E-Mail-Weiterleitungen und Mailinglisten ist dies extrem problematisch, da DMARC verlangt, dass sämtliche Mailinglistensoftware (und E-Mail-Weiterleitungen) den <tt>From</tt>-Header von E-Mails verändert, und die dort angegebene E-Mail-Adresse des Absenders durch die E-Mail-Adresse der Mailingliste bzw. die eigene E-Mail-Adresse ersetzt.[https://de.wikipedia.org/wiki/DMARC#cite_note-4 [4]] Beispiel:
From: Nutzer <user@example.org>
Subject: ...
To: wikide-l@lists.wikimedia.org
müsste durch die Mailinglistensoftware folgendermaßen abgeändert werden:
From: Nutzer via wikide-l <wikide-l@lists.wikimedia.org>
Subject: ...
To: wikide-l@lists.wikimedia.org
Die E-Mail-Adresse des wirklichen Absenders würde hierdurch komplett entfernt, so dass es nicht mehr möglich ist, mit dem Absender direkt in Kontakt zu treten (es sei denn, die Mailingliste fügt einen entsprechenden <tt>Reply-To</tt>-Header hinzu, was aber ebenfalls zu Problemen führt).
DMARC fordert Änderungen an sämtlicher Mailinglisten- und Weiterleitungssoftware.
Dieses prinzipielle Problem im Konzept von DMARC hat dementsprechend auch schon zu schwerwiegenden Problemen bei Mailinglisten geführt („Yahoos DMARC-Policy führt also derzeit dazu, dass Yahoo-Sender den massenhaften Unsubscribe von Mailinglisten-Abonnenten fremder Domains verursachen.“[https://de.wikipedia.org/wiki/DMARC#cite_note-5 [5]]).
==== Einzelnachweise ====
* [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ Draft Stand: 15. Juli 2013 im IETF Datatracker]
* [http://www.golem.de/1201/89399.html Golem-Artikel vom 30. Januar 2012]
* [http://www.focus.de/digital/digital-news/anti-phishing-allianz-internet-konzerne-wollen-user-besser-schuetzen_aid_708468.html Focus-Artikel vom 30. Januar 2012]
* [https://sys4.de/de/blog/2013/08/11/mailman-dmarc-konform-betreiben/ Nachrichten DMARC-konform mit Mailman verteilen]
* [http://www.heise.de/newsticker/meldung/DMARC-Policy-Yahoo-killt-Mailinglisten-Mitgliedschaften-2168857.html Heise Newsletter: DMARC-Policy: Yahoo killt Mailinglisten-Mitgliedschaften]
==== Weblinks ====
* [http://dmarc.org/ Offizielle Webseite]
* [http://www.dmarc.org/presentations/DMARC_general_overview_20120130.pdf Überblick] (PDF; 650&nbsp;kB) (englisch)
* [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ Spezifikation] (englisch)
=== Install DKIM and DMARC on Plesk 12.5 ===
Now a days mail is an unavoidable part of life. How ever the misuse of mail also increasing day by day. Spaming, Spoofing etc. There are many way which can drag you into trouble with your mailbox.
To stop such invalid sender, few new authentication protocol (like SPF, DomainKey) has been started, but it is not enough to stop spammer.
[https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail DKIM] and [https://en.wikipedia.org/wiki/DMARC DMARC] add an extra layer of authentication using an encrypted algorithm.
Recipient mail-server can verify the DKIM signature by recovering the sender’s public key through DNS. It then uses that key to decrypt the hash value in the email’s header and simultaneously recalculate the hash value for the mail message it received.
Unfortunately, Plesk control panel user can not take advantage of this. Till&nbsp;Plesk 12.5, it use old DomainKey, SPF authentication mechanism. Outlook, Exchange server does not like it at all.
Plesk will add DKIM support on upcoming [https://docs.plesk.com/release-notes/17.0/whats-new/ Plesk 17 Onyx].
Understand, what about Plesk 12.x user ?
Don’t worry, follow the tutorial, you will learn, how to '''install DKIM and DMARC on Plesk 12.5'''
First of all I want to thanks to&nbsp;[https://www.linkedin.com/in/ilijamt Ilija Matoski] for his beautiful [https://matoski.com/article/spf-dk-dkim-plesk-debian/ demonstration].
My test environment
OS : CenetOS 7
Plesk : 12.5#43
Postfix version : 2.11
==== Step 1 ====
Install opendkim and add it to system startup script
<nowiki># yum install opendkim</nowiki>
<nowiki># chkconfig opendkim on</nowiki>
==== Step 2 ====
Turn on SPF and DomainKey on the Plesk
Go to Plesk Panel > Tools & settings > Mail Server Settings
[[Image:Bild24.png|top|alt="enable spf plesk"]]
Enable DomainKey signature for outgoing mail
Plesk Panel > Domains > Mail Settings > Use DomainKeys spam protection system to sign outgoing email messages
[[Image:Bild25.png|top|alt="enable domainkey plesk"]]
==== Step 3 ====
Generate DKIM key
Add the domain directory. The domain directory contain public and private key.
<nowiki># mkdir /etc/opendkim/keys/cos701.tld</nowiki>
Generate the keys
cd /etc/opendkim/keys/cos701.tld
opendkim-genkey -d cos701.tld -s mail
chown -Rv opendkim:opendkim /etc/opendkim/keys/cos701.tld
chmod -v u=rw,go-rwx *
Verify the keys
[root@pp1253 plesk-dkim]# ll /etc/opendkim/keys/cos701.tld/
total 8
-rw------- 1 opendkim opendkim 891 Aug 13 07:37 mail.private
-rw------- 1 opendkim opendkim 308 Aug 13 07:37 mail.txt
Domains are ready
The DNS value for DKIM is stored in the file&nbsp;/etc/opendkim/keys/cos701.tld/mail.txt
[root@pp1253 plesk-dkim]# cat /etc/opendkim/keys/cos701.tld/mail.txt
mail._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC64dnB87OrRTm7FhcVxcof4TJJKJBsTYvmR718dAbUZRFg1/8KtgZHgt/dnmGM+stn8rkEykJzzPWEvajM4YM737vD1yQBlR6ZXyYg4w5WQzgQDJvGfKjmURl5Mq8cuasLw6skVUjO6XmfgxeoB6gt+aai7d4Iq3wawRqT8nsV0QIDAQAB" ) ; ----- DKIM key mail for cos701.tld
==== Step 4 ====
Add the value to the DNS “Plesk Panel > Domains > cos701.tld > DNS settings”
[[Image:Bild26.png|top|alt="add dkim to plesk dns"]]
Additionally, add the following value for DMARC support
_dmarc.cos701.tld. &nbsp; &nbsp;TXT &nbsp; &nbsp;v=DMARC1; p=quarantine; pct=100; rua=[mailto:postmaster@cos701.tld mailto:postmaster@cos701.tld]
==== Step 5 ====
Configure openDKIM
Add the following value to the ‘/etc/opendkim/TrustedHosts’ file.
127.0.0.1
localhost
123.123.123.123
cos701.tld
ns1.cos701.tld
ns2.cos701.tld
mail.cos01.tld
Add the following value to the ‘/etc/opendkim/SigningTable’. ‘SigningTable’ file is used to list the domains along with their key file path.
<nowiki># KeyID Domain:Selector:PathToPrivateKey</nowiki>
cos701.tld cos701.tld:mail:/etc/opendkim/keys/myserverplace.de/mail.private
Add the following value to ‘/etc/opendkim/TrustedHosts’.&nbsp;It will list the top trusted hosts as you desire.
@cos701.tld cos701.tld
We need to edit the configuration file to configure DKIM, open /etc/opendkim.conf with your favorite editor and add the following lines to the end of the file
<nowiki># cp /etc/opendkim.conf{.-bak}</nowiki>
Put the following value to the file
PidFile /var/run/opendkim/opendkim.pid
Mode sv
Syslog yes
SyslogSuccess yes
LogWhy yes
UserID opendkim:opendkim
Socket inet:8891@localhost
Umask 002
Canonicalization relaxed/relaxed
Selector default
MinimumKeyBits 1024
KeyFile /etc/opendkim/keys/default.private
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts
SignatureAlgorithm rsa-sha256
AutoRestart Yes
SignHeaders From,Sender,To,CC,Subject,Message-Id,Date
OversignHeaders From,Sender,To,CC,Subject,Message-Id,Date
==== Step 6 ====
OpenDKIM is properly setup, let’s move on and configure the Postfix.
Open /etc/postfix/main.cf with your favorite editor, and modify the following&nbsp;lines
milter_default_action = accept
milter_protocol = 6
smtpd_milters = , inet:127.0.0.1:8891, inet:127.0.0.1:12768
non_smtpd_milters = $smtpd_milters
Postfix also ready
service postfix restart
==== Step 7 ====
For verification, send mail to the following mail address, you will get instant reply with the result
check-auth@verifier.port25.com
AAAA3QcKCQwA@appmaildev.com
The result should be similar like this
<nowiki>==========================================================</nowiki>
Summary of Results
<nowiki>==========================================================</nowiki>
SPF check: pass
DomainKeys check: pass
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham
Congratulation! you have successfully installed the DKIM on Plesk. It is very great full to me if this tutorial ‘Install DKIM and DMARC on Plesk 12.5’ helpful to you.
=== [http://kb.dynamichosting.biz/display/public/How+To+Setup+DMARC+in+Plesk How To Setup DMARC in Plesk] ===
DMARC stands for “Domain-based Message Authentication, Reporting & Conformance”, it's an&nbsp;email authentication&nbsp;protocol&nbsp;that allows senders and receivers to improve and monitor protection of the domain from fraudulent email. Many ISP's now require DMARC so if you do not have it properly configured your email may not be accepted by those ISP's.&nbsp;
[http://mxtoolbox.com/ mxtoolbox.com]&nbsp;is a great way to tell if your domain is correctly configured for DMARC (as well as SPF).&nbsp;
This is the process to configure DMARC for your account with our [https://dynamichosting.ca/canadian-web-hosting/ Canadian shared hosting] servers:# In the server control panel (Plesk - [http://kb.dynamichosting.biz/display/public/Logging+in+to+Plesk how to log into plesk]) go to your DNS Settings area for the domain you wish to add DMARC for:&nbsp;<br/>[[Image:Bild27.png|top]]
# Then, click on the "Add Record" button:<br/>[[Image:Bild28.png|top]]
# Next select the type as "TXT" and add the following fields and click "OK":
{| class="wikitable options big"
|-
|| Record type
|| TXT
|-
|| Domain name
|| _DMARC
|-
|| TXT record&nbsp;
|| v=DMARC1; p=none; sp=none; rf=afrf; pct=100; ri=86400
|-
|}
The end result should look like this:
[[Image:Bild29.png]]
# Click the "Update" DNS button as seen here:&nbsp;<br/>[[Image:Bild30.png]]<br/>
# Now back in the "Website & Domains" area of Plesk click on the "Mail Settings" Icon for the domain you wish to apply DMARC for as seen here:<br/>
[[Image:Bild31.png]]
# Here at the bottom of the page you will find a checkbox, ensure it is selected and click "OK"<br/>[[Image:Bild32.png]]
That should be all you have to do! It takes time for [http://kb.dynamichosting.biz/display/public/How+DNS+Propagation+Works DNS to propagate] but after that has happened you can test that it's working correctly via a free online tool such as&nbsp;[http://mxtoolbox.com/ mxtoolbox.com]&nbsp;and your emails should be DMARC compliant!&nbsp;
=== Using DNSSEC (Linux) ===
DNSSEC is the extension of the DNS protocol that allows signing of DNS data in order to secure the domain name resolving process. For general information about DNSSEC and its usage, visit [https://www.icann.org/resources/pages/dnssec-2012-02-25-en ICANN website] and [https://tools.ietf.org/html/rfc6781 https://tools.ietf.org/html/rfc6781].
Plesk enables you to protect DNS data of hosted domains with DNSSEC. You can do the following: * Configure the settings used for key generation and rollover.
* Sign and unsign domain zones according to the DNSSEC specifications.
* Receive notifications.
* View and copy DS resource records.
* View and copy DNSKEY resource record sets.
====== Requirements ======
* Plesk for Linux with the Bind DNS server, starting from Bind 9.9.
* DNSSEC extension is commercial and is not included by default in Plesk editions.
====== Enabling DNSSEC Support ======
To enable the support for DNSSEC, install the '''Plesk DNSSEC '''extension ('''Extensions''' > '''Extensions Catalog''').
====== Configuring Default DNSSEC Settings ======
The default DNSSEC settings are located in '''Tools & Settings''' > '''Extensions''' > '''DNSSEC'''. You can change the default policy for generating Key Singing Key (KSK) and Zone Signing Key (ZSK) pairs.
'''The recommended policy for KSK and ZSK''':* Use a long key and a long rollover period for the KSK (Key Signing Key).
* Every time the Key Signing Key is updated, the zone owner needs to update the DS records in the parent domain zone. The recommended policy helps to update DS records in the parent zone as seldom as possible without decreasing security.
* Use a shorter key and a shorter rollover period for the ZSK (Zone Signing Key).
* The Zone Signing Key is updated automatically. The recommended policy helps to save system resources without decreasing security.
When hosting customers sign their zones, they can use the default values or specify different values.''' '''For details, see [https://docs.plesk.com/en-US/17.0/administrator-guide/website-management/websites-and-domains/domains-and-dns/configuring-dnssec-for-a-domain.76433/ Using DNSSEC on Domains].
====== Protecting DNS Zones with DNSSEC ======
To use DNSSEC, domain owners must sign their DNS zones.''' '''For details, see [https://docs.plesk.com/en-US/17.0/administrator-guide/website-management/websites-and-domains/domains-and-dns/configuring-dnssec-for-a-domain.76433/ Using DNSSEC on Domains].
====== How Key Rollover Works in Plesk ======
In order to prevent DNS outage for a domain, Plesk uses more than one key as the KSK and more than one key as the ZSK. A previously generated key exists in parallel with a new key for some time, to allow all the changes in a DNS zone to take effect. Obsolete keys are removed automatically.
'''KSK rollover'''
Plesk uses a modification of [https://tools.ietf.org/html/rfc7583#section-3.3.3 Double-RRset method] for rolling over Key Signing Keys, the difference is that Plesk has two Key Signing Keys during each rollover period. This measure allows enough time for the domain zone owner to update the corresponding DS records in the parent zone (for example, the time period between rollover events 1 and 2 in the scheme below).
'''User actions at KSK rollover'''
The domain zone owner is notified about the rollover and about the need to update the DS records in the parent zone. The DS records become obsolete when the oldest KSK expires and the newest KSK is generated (for example, at rollover event 2 in the scheme below). If the domain zone owner did not update the DS records in the parent zone, then at the end of one rollover period after the notification the domain stops resolving.
'''ZSK rollover'''
To allow enough time for slave and caching DNS servers to sync with the master DNS server, Plesk does the following:* Adds a new key to the zone at a certain time before the rollover event.
* Removes the previous key at the same certain time after the rollover event.
This certain time before or after a ZSK rollover is called a ''transition period'' in Plesk. The transition period is either 30 days or the sum of zone's SOA TTL and SOA Expire values (if their sum is over 30 days). However, the transition period cannot be longer than half the ZSK rollover period, otherwise the rollover functionality will be disrupted and the zone signatures will become invalid.
Therefore, to make sure that ZSK rollover is performed correctly, Plesk sets limits on the following values:* The zone's SOA TTL and SOA Expire. Their sum cannot be longer than a certain calculated value.
* The ZSK rollover period. It cannot be shorter than a certain calculated value.
'''User actions at ZSK rollover'''
No actions are required of the domain's DNS zone owner when Zone Signing Keys are rolled over.
===== Leave your comments on this page =====
Leave your feedback or question on this documentation topic below. For technical assistance, contact your hosting service provider or submit a request to [https://cscontact.plesk.com/ Plesk support]. Suggest new features for Plesk [http://plesk.uservoice.com/ here]. Discuss general questions on the [http://talk.plesk.com/ Plesk forum]. All offtopic comments will be removed.
=== DMARC ===
DMARC steht für Domain-based Message Authentication, Reporting and Conformance und nutzte DNS-Einträge, die in Verbindung mit SPF und DKIM arbeiten.
Es mehren sich die Hinweise, dass Domains mit einem DMARC-Eintrag seltener zum Phising missbraucht werden, dass viele große Provider dank [http://www.msxfaq.de/spam/filter-spf.htm SPF] bzw. [http://www.msxfaq.de/spam/filter-dkim.htm DKIM] solche Fälschungen nicht nur erkennen, sondern anhand DMARC den Inhaber auch informieren und diese durchaus über den Provider dagegen vorgehen.
Der Ausgangspunkt von DMARC ist der Schutz der eigenen Domäne gegen Missbrauch von anderen Absendern, indem Sie als Inhaber die entsprechenden Vorarbeiten leisten, damit die Empfänger prüfen können, ob der Absender für diese Domäne auch senden darf.
Es gibt mit [http://www.msxfaq.de/spam/filter-spf.htm SPF] oder [http://www.msxfaq.de/spam/filter-rmx.htm RMX] schon ein Verfahren, um die "Source-IP" von Systemen zu veröffentlichen, die für eine Domäne als Absenderhost agieren. Allerdings limitiert dies die Möglichkeiten Mails z.B. über Relays oder Provider zu versenden, bei denen Sie Mailserver-Adressen ändern oder erweitern.
Mit [http://www.msxfaq.de/spam/filter-dkim.htm DKIM] gibt es daher einen Weg, wie eine Mail selbst signiert werden kann. Es ist keine klassische digitale Signatur mit [http://www.msxfaq.de/signcrypt/smimepgp.htm SMime oder PGP] aber sehr ähnlich. Die Integrität der Mail wird damit sichergestellt, d.h. der Inhalt gegen Veränderungen geschützt und der Absender bestätigt.
DMARC geht aber weiter und veröffentlich Informationen, wie die Empfänger Sie als Domaininhaber über missbrauch informieren sollen.
Die Empfänger prüfen also nicht nur die eingehenden Mails gegen SPF und DKIM-Parameter, sondern über DMARC senden Sie auch Statusmeldungen und Zusammenfassungen an die hinterlegten Rückantwortadressen.
Als Domaininhaber mit einer passenden Verarbeitung erhalten Sie also direkt ein Feedback, wir stark ihre Domäne von fremden Personen unberechtigt genutzt wird. Es dient also primär dem Schutz ihrer Marke. Interessant wird das natürlich, wenn die großen Mailempfänger und Hoster nicht nur SFP und DKIM als Spamfilter nutzen, sondern auch die Daten aus dem DMARC-Eintrag verwenden.
Es ist also kein neuer Spamfilter sondern primär addiert DMARC einen Weg, wie Missbrauch auch bekannt werden kann. Aber wenn man DMARC glauben kann, sind das zumindest in den USA schon sehr viele Postfächer.
As of early 2013 DMARC had been deployed to protect roughly 2 billion email accounts - over 60% of consumer mailboxes globally, and over 80% of consumer mailboxes in the united States.
During the first 45 days of initial monitoring, Twitter saw nearly 2.5 billion messages spoofing its domains. Twitter reports ~110 million messages/day were spoofing its domains prior to deploying DMARC, redUCEd to only 1,000/day after publishing a "reject" policy. Quelle: [http://www.dmarc.org/ http://www.dmarc.org/]
Achtung:
Ein DMARC-Eintrag auf einer Domäne gilt auch für Subdomains !. DMARC-Prüfer haben dazu eine Liste der "Root-Domains", um z.B. "<firma>.de" von "<firma.co.uk>" zu unterscheiden.
'''Achtung'''
Ein gesetzter DMARC Eintrag erfordert für die Domäne und alle Subdomains auch einen SPF-Eintrag. Fehlt dieser, dann lehnen viele Firmen die Mails ab, wenn die SPF-Prüfung bei gesetztem DMARC-Eintrag nicht möglich ist.
Die Zahlen sind beeindruckend, aber DMARC ist nur die Einstellung, dass die Empfänger mit DMARC-Support an die Domaininhaber auch die Zahlen melden. Der Filter solche "Phishing-Mails" basiert auf [http://www.msxfaq.de/spam/filter-spf.htm SPF] und/oder [http://www.msxfaq.de/spam/filter-dkim.htm DKIM] und gibt es schon länger.
===== Der DMARC Eintrag =====
Dazu ist ein DMARC-Eintrag erforderlich. Aus Sicht von DNS ist es einfach ein TXT-Record, der den Namen "_dmarc" trägt. Ein Eintrag für die MSXFAQ könnte also lauten: (alles ohne Umbrüche und bitte eine gültige Mailadresse verwenden):
'''Warnung'''
Dies ist ein Beispiel damit ich für meine Domäne die Reports bekomme. Bitte nutzen Sie als Mailadresse für ihre Domains bitte ihre eigene Adresse oder einen Dienstleister.
_dmarc.msxfaq.de TXT ="
v=DMARC1;
p=none;
pct=100;
rua=mailto:dmarc-aggregate@msxfaq.de.net;
ruf=mailto:dmarc-forensik@msxfaq.de.net;
adkim=s;
aspf=r
"
Die Felder können unterschiedliche Bedeutung haben:
{| class="wikitable options big"
|-
| | '''Feld'''
| | '''Bedeutung der Werte'''
|-
| | v=DMARC1
| | Kennzeichnet die Version. Aktuell ist Version 1 gültig.
|-
| | p=sp=
| | Policy oder "Subdomain Policy"Der Wer hinter "p=" kennzeichnet, wie der Empfänger mit Mails umgehen soll, die nicht korrekt mit SPF oder DKIM überprüft werden konnten. Der Eintrag "sp=" beschreibt das Vorgehen für Sub-Domains. mögliche Werte sind:* noneDer Empfänger soll die Mail trotzdem weiter senden
* quarantineDer Empfänger soll die Mail annehmen aber in Quarantäne legen
* rejectDer Empfänger soll die Mail einfach auf SMTP-Level ablehnen
|-
| | pct=
| | Prozentsatz der Mails, die entsprechend von "p" gefiltert werden sollen. Wenn jemand aber mit DMARC einen Eintrag addiert und korrekt alle Mails gemäß SPF und DKIM versendet, sollte kein Problem mit einer "100" hier haben
|-
| | rua
| | Receive or aggregated ReportDer Empfänger sendet an diese Adresse oder Adressen einen "Summenbericht". Das passiert in der Regel einmal am Tag
Achtung: Wenn der Empfänger in einer anderen SMTP-Domäne ist, dann senden die DMARC-Aggregatoren die Mail in der Regel erst dann, wenn die Empfängerdomäne ihr Einverständnis gegeben hat. DAs macht diese ebenfalls per DNS-Eintrag.msxfaq.de._report._dmarc.netatwork.de&nbsp;&nbsp; TXT "v=DMARC1"So gibt die Domäne "netatwork.de" bescheid, dass die DMARC-Report für msxfaq.de annehmen wird.
|-
| | ruf
| | receiver of forensic reportAn diese Mailadresse sendet der Empfänger einen forensischen Report über die fehlerhafte Mail. Als Betreiber können Sie dann gut erkennen, welcher angebliche Absender an das Ziel versucht hat, eine Mail mit ihrer Domain zu senden. So können Sie "vergessene" Versender erkennen und korrigieren oder versuchen gegen Missbrauch vorzugehen.
Auch für hier verwendete Adressen anderer Domänen muss der Empfänger seine Bereitschaft signalisieren.
|-
| | adkim
| | Abgleicheinstellung für DKIM.Hiermit können Sie vorgeben, wie streng die Prüfung bezüglich DKIM sein soll.* s=StrictDie Domänen müssen exakt übereinstimmen
* r=RelaxedDie Kopfzeile im SMTP-Header darf auch eine Subdomain sein, z.B. "newsletter@msxfaq.de"
|-
| | aspf
| | Dieser Parameter steuert analog die SPF-Auswertung.* s=StrictDie Domänen müssen exakt übereinstimmen
* r=RelaxedDie Kopfzeile im SMTP-Header darf auch eine Subdomain sein, z.B. "newsletter@msxfaq.de"
|-
|}
Für eine erfolgreiche DMARC-Validierung reicht es, wenn eines der beiden Checks, SPF oder DKIM erfolgreich war. DKIM wird überwiegend genutzt, wenn die Authentizität der Mail auch über Relaisstationen gewährleistet werden soll, aber erlaubt kein Umschreiben der Absender (Stichwort Mailingliste). Hier ist dann SPF besser, wenngleich dann die ausgehenden IP-Adressen gepflegt sein müssen.
Wer mit DMARC anfängt, kann also erst einmal den Eintrag setzen aber stellt also Aktion z.B. "p=none" und schaut sich die Meldungen einige Zeit an.* DMARC Record Assistant http://kitterman.com/dmarc/assistant.html&nbsp;
* dmarc.org Deployment Toolshttps://dmarc.org/resources/deployment-tools/
* DMARC Wizardhttps://www.unlocktheinbox.com/dmarcwizard/
* DMARC Record Creatorhttps://app.agari.com/dmarc/record_creator
* Build Your DMARC Record in 15 Minutes https://blog.returnpath.com/build-your-dmarc-record-in-15-minutes-v2/
* HOWTO - Define a DMARC Recordhttp://www.zytrax.com/books/dns/ch9/dmarc.html
===== Beispieleinträge von Firmen =====
Ob eine Firma DMARC einsetzt, können Sie einfach per NSLOOKUP ermitteln.
C:\>nslookup -q=TXT _dmarc.microsoft.com
Server: dns.netatwork.de
Address: 192.168.100.1
Nicht autorisierende Antwort:
_dmarc.microsoft.com text =
"v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"
Wenn man ein paar bekannte Firmen anfragt, dann sieht man durchaus einige interessante Einträge:
_dmarc.microsoft.com text = "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"
_dmarc.outlook.com text = "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@auth.returnpath.net; ruf=mailto:d@ruf.agari.com,mailto:dmarc_afrf@auth.returnpath.net; fo=1"
_dmarc.mail.ru text = "v=DMARC1;p=none;rua=mailto:d@rua.agari.com,mailto:dmarc_rua@corp.mail.ru,mailto:dmarc_agg@auth.returnpath.net;ruf=mailto:d@ruf.agari.com,mailto:dmarc_afrf@auth.returnpath.net;fo=1;"
_dmarc.yahoo.com text = "v=DMARC1; p=reject; sp=none; pct=100; rua=mailto:dmarc-yahoo-rua@yahoo-inc.com, mailto:dmarc_y_rua@yahoo.com;"
_dmarc.google.com text = "v=DMARC1; p=quarantine; rua=mailto:mailauth-reports@google.com"
_dmarc.aol.com text = "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
_dmarc.bahn.de text = "v=DMARC1; p=none; rua=mailto:dmarc.reporting@deutschebahn.com;"
_dmarc.dell.com text = "v=DMARC1; p=none; rua=mailto:dmarc-dell-rua@sonicwall.com; ruf=mailto:dmarc-dell-ruf@sonicwall.com"
_dmarc.amazon.com text = "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@bounces.amazon.com; ruf=mailto:dmarc-reports@bounces.amazon.com"
_dmarc.dhl.de text = "v=DMARC1;p=none;rua=mailto:dhl@rua.agari.com;ruf=mailto:dhl@ruf.agari.com"
_dmarc.ups.de cname = _dmarcmonitor.ups.com
_dmarcmonitor.ups.com text = "v=DMARC1; p=none; rua=mailto:ups@rua.agari.com; ruf=mailto:ups@ruf.agari.com; fo=1"
_dmarc.ups.com text = "v=DMARC1; p=reject; rua=mailto:ups@rua.agari.com; ruf=mailto:ups@ruf.agari.com; fo=1"
_dmarc.ing-diba.de text = "v=DMARC1; p=none; rua=mailto:SecurityServices@ing-diba.de"
_dmarc.ebay.de text = "v=DMARC1; p=none; rua=mailto:dmarc_agg@auth.returnpath.net; ruf=mailto:dmarc_afrf@auth.returnpath.net; rf=afrf; pct=100"
_dmarc.paypal.com text "v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com"
Es ist gut zu sehen, dass die großen Versender und Logistiker, aber auch die Internet-Firmen hier Vorreiter spielen. Interessant sind hier natürlich insbesondere die Einträge zum RUF und RUA´. Scheinbar nutzen sehr viele die Dienste von agari.com, um die Ergebnisse von "Domainmissbrauch" zentral zu erkennen. Auf deren Webseite finden sich Daten wie
In fact, we get data from 85% of all email inboxes in the US and 60% of email inboxes globally.Quelle: [http://agari.com/what-we-do/ http://agari.com/what-we-do/]
Auf der anderen Seite haben gerade deutsche Domains hier noch Nachholbedarf. (Stand Okt 2014). Ich habe einfach ein paar Namen einmal durch probiert. Gerade die großen Provider scheinen hier eher auf ihr "E-Mail Made in Germany" zu setzen.
_dmarc.t-online.de text = nicht vorhanden
_dmarc.telekom.de text = nicht vorhanden
_dmarc.gmx.de text = nicht vorhanden
_dmarc.web.de text = nicht vorhanden
_dmarc.basf.com text = nicht vorhanden
_dmarc.siemens.de text = nicht vorhanden
_dmarc.rwe.de text = nicht vorhanden
_dmarc.bsi.de text = nicht vorhanden
_dmarc.ccc.de text = nicht vorhanden
_dmarc.deutsche-bank.de text = nicht vorhanden
_dmarc.netbank.de text = nicht vorhanden
_dmarc.allianz.de text = nicht vorhanden
_dmarc.aldi.de text = nicht vorhanden
_dmarc.tchibo.de text = nicht vorhanden
_dmarc.ebay-kleinanzeigen.de text = nicht vorhanden
Interessant ist auch, dass die Banken noch nicht dabei sind.
Es ist wie gesagt nicht schlimm, wenn man DMARC nicht unterstützt. Letztlich muss jede Firma selbst entscheiden, ob ihr Mailsystem die Mails per DKIM signieren kann und dann per DMARC dies den Empfängern mitgeteilt wird. Ich persönlich würde ja eh viel mehr auf eine echte S/MIME-Signatur setzen aber es ist durchaus eine Option den eigenen Namen und die Marke zu schützen.
===== Reporting =====
Die Rückmeldungen der entfernten Server, an die Mails mit ihrer Domain gesendet werden, kommen ganz klassisch per Mail und nicht "modern" über Webservices. Entsprechend muss die im DMARC-Record hinterlegte Mailadresse natürlich einem Postfach zugeordnet sein.
Das muss aber kein Postfach in ihrer Domäne sein und wenn Sie sich die DMARC-Records der oben genannten Firmen anschauen, dann erkennen Sie eine Häufung der Firmen "agari.com" und "returnpath.net". Beide sind Dienstleister die solche Rückläufer einsammeln und die Auswertung als "Hosted Service" ihren Kunden anbieten. Sie können die Mails aber natürlich auch in ein eigenes Postfach ablegen.
'''Achtung'''
Als deutsche Firma sollten Sie überlegen ob sie selbst DMARC-Reports an andere Firmen senden oder in welcher Weise Sie die Reports aus Datenschutzgründen verwässern.[https://www.eco.de/2015/pressemeldungen/phishing-abwehr-datenschutzrechtliche-bedenken-gutachten-empfiehlt-redacting.html https://www.eco.de/2015/pressemeldungen/phishing-abwehr-datenschutzrechtliche-bedenken-gutachten-empfiehlt-redacting.html]&nbsp;
Ich habe dazu bei einer meiner Spiel-Domains einfach mal einen _DMARC-Eintrag addiert und als RUF/RUA-Adresse meine normale Mailbox angegeben. Hier der Mustereintrag
C:\>nslookup -q=TXT _dmarc.frankcarius.de
Server: fritz.box
Address: 192.168.178.1
Nicht autorisierende Antwort:
_dmarc.frankcarius.de text =
"v=DMARC1;p=none;pct=100;rua=mailto:frank.carius@netatwork.de;ruf=mailto:frank.carius@netatwork.de;adkim=s;aspf=r"
[[Image:Bild13.png|right|top]]Dann habe ich eine Testmal an eine outlook.com-Adresse gesendet. Die kam durch, weil im DMARC-Eintrag ein "p=none" steht.
Aber nun habe ich gespannt auf die Mail in dem angegeben Postfach gewartet. Die kam dann auch kurz nach Mitternacht:
<div >[[Image:Bild6.png|right]]</div>
Der Body der Mail war leer und als Anlage war eine ZIP-Datei angehängt. In der war wiederum genau eine XML-Datei, in der z.B.: die vom Empfänger gesehenen Einstellungen wieder gegeben sind und die Detaildaten der Verbindung. Hier war es genau eine von der Source-IP "80.66.20.28".
<?xml version="1.0" encoding="utf-8"?>
<feedback>
<report_metadata>
<org_name>Microsoft Corp.</org_name>
<email>dmarcrep@microsoft.com</email>
<report_id>e7c320ad9ac24ac9a153ac17065a2db9@hotmail.com</report_id>
<date_range>
<begin>1414015200</begin>
<end>1414101600</end>
</date_range>
</report_metadata>
<policy_published>
<domain>frankcarius.de</domain>
<adkim>s</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>80.66.20.28</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>frankcarius.de</header_from>
</identifiers>
<auth_results>
<spf>
<domain>frankcarius.de</domain>
<result>none</result>
</spf>
<dkim>
<domain>frankcarius.de</domain>
<result>none</result>
</dkim>
</auth_results>
</record>
</feedback>
Man sieht auch, dass sowohl die SFP- als auch die DKIM-Abfrage fehlgeschlagen sind. Leider konnte ich im Header der Mail keine Hinweise darauf sehen, dass diese Stausmail per DKIM gesichert war. So kann ich nicht sicher sein, dass nicht jemand anderes mit einen StatusBericht sendet und damit die daraus generierten Statistiken verändert.
Ein kleiner PowerShell-Einzeiler liefert eine Tabelle der Statusmeldungen:
[xml]$report=Get-Content C:\temp\temp\report.xml
$report.feedback.record | select {$_.row.source_ip}, {$_.identifiers.header_from}, {$_.auth_results.spf.result}, {$_.row.policy_evaluated.spf}
&nbsp;
$_.row.source_ip $_.identifiers.head $_.auth_results.spf $_.row.policy_evalu
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;er_from .result ated.spf
----------------  ------------------- ------------------- -------------------
117.111.120.11 msxfaq.com pass pass
117.111.120.11 de.msxfaq.com none &nbsp;&nbsp;&nbsp;fail
93.199.90.91 msxfaq.com pass pass
93.199.90.91 de.msxfaq.com none fail
93.199.90.94 msxfaq.com pass pass
93.199.90.94 de.msxfaq.com none fail
62.242.148.41 de.msxfaq.com none fail
Wer also mag, kann z.B. alle Anlagen aus dem DMARC-Sammelpostfach abfischen und verarbeiten.
===== Störpotential beim Reportpostfach =====
[[Image:Bild16.png|right|top]]Für Spammer sind diese Adressen zwar leicht per DNS "einzusammeln" aber natürlich kein lohnendes Ziel. Diese Mails wird wohl nie ein unbedarfter Anwender lesen. Damit niemand gefälschte Reports darunter mischt, werden natürlich auch diese Mails per SPF/DKIM gesichert, so dass Fälschungen früh aussortiert werden können.
Und selbst dann wird der verarbeitende Prozess eine Mail nur dann verstehen, wenn Sie sich an das Format hält. Dennoch scheint es Spammer zu geben, die entweder die Mailadresse hier auf der Webseite eingesammelt haben oder tatsächlich den DNS-Eintrag parsen. Auf jeden Fall kommt tatsächlich Spam an diese Adresse.
Es gibt aber dennoch ein Störpotential. Es ist heute sehr einfach eine Domäne im Internet zu registrieren und einen DMARC-Eintrag zu addieren, in dem eine Mailadresse einer anderen Person hinterlegt wird, die ich stören möchte. Wenn der Mailserver dieses Ziels nicht SPF/DKIM prüft und gefälschte Report-Mails verwirft, dann wird er die Mails in das Postfach zustellen.
Wenn ich dann absichtlich eine Mail mit dieser Absenderdomäne z.B. an einen Server sende, der SFP/DKIM prüft und die Reports anhand des DMARC-Eintrags erstellt, dann sendet dieser Server eine Mail an die hinterlegte Adresse.
Das kann schon störend sein, wenn ich von einem PC eben tausende "kleine" Mails an viele Mailserver mit SPF/DKIM-Support sende und diese dann eine deutlich größere "Statusmail" an die DMARC-Reportadresse sende. Ob das schon für einen DDoS per SMTP reicht ?
===== DMARC bei 1&1 =====
[[Image:Bild17.png|right|top]]Seit Anfang 2016 hat die 1und1-Gruppe den Schutz gegen Spam mittels [http://www.msxfaq.de/spam/filter-spf.htm SPF] noch etwas verstärkt. Der Versuch aber einen DMARC-Eintrag zu addieren, schlägt leider fehlt. Technisch musste man dazu bei 1und1 früher eine "Subdomain" anlegen aber im neuen Control-Center können Sie auf der Domäne direkt einen TXT-Record addieren. Allerdings ist die aktuell (Jun 2016) nicht möglich, da die Eingabe eine Validierung macht und ein einfaches _dmarc.<domain> nicht erlaubt ist.
Leider kann ich auch keine "Subdomain" mit einem "_" ersatzweise anlegen. Hier muss 1und1 wohl noch etwas korrigieren, damit auch DMARC-Einträge möglich werden* TXT-Record für eine Domain setzen oder löschen
* http://hilfe-center.1und1.de/hosting/domain-c10082638/dns-einstellungen-c10082657/txt-record-fuer-eine-domain-setzen-oder-loeschen-a10792649.html
* SPF-Record für Domain setzen
* [http://hilfe-center.1und1.de/hosting/domain-c10082638/dns-einstellungen-c10082657/spf-record-fuer-domain-setzen-a10795604.html http://hilfe-center.1und1.de/hosting/domain-c10082638/dns-einstellungen-c10082657/spf-record-fuer-domain-setzen-a10795604.html]&nbsp;
===== DMARC Auswertungen =====
Die Rückmeldungen von Firmen, die DMARC-Einträge auswerten, kommen in dem angegebenen Postfach als XML-Datei an. Sicher könnten Sie nun das Postfach lesen und auswerten, sei es per Outlook oder mit einem PowerShell-Skript. Aber dann steht immer noch die grafische Auswertung an. Im Zeichen der Cloud gibt es einige Anbieter, die ihnen die Arbeit hier abnehmen. Sie lassen die Reports einfach an diesen Anbieter senden oder leiten ihre Reports weiter. Per Browser&nbsp;können Sie dann entsprechend aufbereitet Reports betrachten.
Die folgende Liste von DMARC-Auswertestellen ist keine repräsentative Marktübersicht und darf nicht als Empfehlung meinerseits missverstanden werden.* DMarcian[https://dmarcian.com/ https://dmarcian.com/]
* Agari[https://www.agari.com/ https://www.agari.com/]
* ReturnPath.net[https://returnpath.com/ https://returnpath.com/]
* DMARC Analyzer[https://www.dmarcanalyzer.com/ https://www.dmarcanalyzer.com/]
===== Weitere Links =====
* SPF http://www.msxfaq.de/spam/filter-spf.htm
* RMX http://www.msxfaq.de/spam/filter-rmx.htm
* DKIM http://www.msxfaq.de/spam/filter-dkim.htm
* SMime oder PGP http://www.msxfaq.de/signcrypt/smimepgp.htm
* DANE/TLSA http://www.msxfaq.de/signcrypt/dane_tlsa.htm
* Phishing-Abwehr: datenschutzrechtliche Bedenken – Gutachten empfiehlt Redacting https://www.eco.de/2015/pressemeldungen/phishing-abwehr-datenschutzrechtliche-bedenken-gutachten-empfiehlt-redacting.html&nbsp;
* DMARC.org - Domain-based Message Authenticationwww.dmarc.org
* DMARC – Wikipedia http://en.wikipedia.org/wiki/DMARChttp://de.wikipedia.org/wiki/DMARC
* Understand DMARC - Google Apps Administrator Helphttps://support.google.com/a/answer/2466580
* Everything about DMARC https://support.sendgrid.com/hc/en-us/articles/200182958-Everything-about-DMARC-
* SENDERID, SPF, DKIM AND DMARC IN EXCHANGE 2016https://jaapwesselius.com/2016/08/19/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-i/ https://jaapwesselius.com/2016/08/22/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-ii/ https://jaapwesselius.com/2016/08/23/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-iii/
==== DMARC ====
Domain-based Message Authentication, Reporting and Conformance, kurz DMARC, ist eine Spezifikation, die entwickelt wurde, um Missbrauch von [https://de.wikipedia.org/wiki/E-Mail E-Mails] zu reduzieren. Sie versucht, einige seit langem bestehende Unzulänglichkeiten im Zusammenhang mit [https://de.wikipedia.org/wiki/Authentifizierung Authentifizierungsproblemen] beim E-Mail-Versand zu beheben. Sie wurde bei der [https://de.wikipedia.org/wiki/Internet_Engineering_Task_Force IETF] zur Standardisierung eingereicht.[https://de.wikipedia.org/wiki/DMARC#cite_note-1 [1]]
===== Überblick =====
DMARC baut auf den bekannten Techniken [https://de.wikipedia.org/wiki/Sender_Policy_Framework SPF] (Sender Policy Framework) und [https://de.wikipedia.org/wiki/DomainKeys DKIM] (DomainKeys Identified Mail) auf, indem es festlegt, wie der Empfänger von E-Mails die Authentifizierung durchführen soll.
Während die vorgenannten Techniken beschreiben, wer eine Mail versenden darf (SPF) bzw. dass diese Mail in bestimmter Weise unverändert vom Absender stammt (DKIM), kann der Absender nach der DMARC-Spezifikation zusätzlich Empfehlungen geben, auf welche Art der Empfänger mit einer Mail umgeht, die in einem oder beiden Fällen nicht den Anforderungen entspricht.
Sofern der Empfänger einer E-Mail die DMARC-Spezifikation anwendet, ist dadurch eine konsistente Überprüfung der Authentizität dieser E-Mail gesichert.
===== Aufbau eines Eintrags =====
DMARC bedient sich hierzu, wie auch SPF und DKIM, der [https://de.wikipedia.org/wiki/TXT_Resource_Record TXT-Records] des [https://de.wikipedia.org/wiki/Domain_Name_System Domain Name Systems] (DNS). Dort wird zusätzlich zu den SPF- und DKIM-Einträgen ein weiterer [https://de.wikipedia.org/wiki/Resource_Record RR-Eintrag] mit zum Beispiel folgendem Aufbau angelegt:
v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@example.org;ruf=mailto:forensik@example.org;adkim=s;aspf=r
{| class="wikitable options big"
|-
| | '''Abkürzung'''
| | '''Bedeutung'''
|-
| | v
| | Protokollversion
|-
| | pct
| | Prozentualer Anteil der zu filternden Mails
|-
| | ruf
| | Forensischer Report wird versandt an:
|-
| | rua
| | Aggregierter Report wird versandt an:
|-
| | p
| | Wie wird mit Mails der Hauptdomäne verfahren?
|-
| | sp
| | Wie wird mit Mails der Subdomäne verfahren?
|-
| | adkim
| | Abgleichmodus für DKIM
|-
| | aspf
| | Abgleichmodus für SPF
|-
|}
Besondere Bedeutung haben die Abgleichmodi. Für SPF fordert die Spezifikation, dass erstens die Überprüfung positiv ausfällt und zweitens die From: Kopfzeile der Mail dieselbe Domäne aufweist, wie im SPF-Record hinterlegt.
Für DKIM wird gefordert, dass die Signatur gültig ist und zusätzlich die dort genannte Domäne dieselbe ist, wie in der From: Kopfzeile der Mail. Als Abgleichmodi sind s='strict' bzw. r='relaxed' vorgesehen.
Bei 'strict' müssen die Domänen exakt übereinstimmen, bei 'relaxed' darf die From: Kopfzeile auch eine Subdomäne enthalten. Über die Auswertung erhält der Sender einen täglichen Report an die genannte Adresse.
Die [https://de.wikipedia.org/wiki/Policy Policy] (hier abgekürzt als 'p' bzw. 'sp' für Subdomains) legt schließlich fest, wie der Empfänger mit der Mail verfahren soll, wenn die Überprüfung scheitert. Vorgesehene Modi hierfür sind 'none', 'quarantine' und 'reject'. 'none' (auch als Monitormodus bezeichnet) wird in der Regel zum Testen verwendet und macht dem Empfänger keine Vorschriften über die Verfahrensweise. 'quarantine' verlangt die Kennzeichnung der Mails als Spam, 'reject' verlangt, die Mail zu verwerfen.
Die DMARC-Spezifikation entstand unter Anderem auf Initiative von [https://de.wikipedia.org/wiki/Google_Inc. Google], [https://de.wikipedia.org/wiki/Yahoo Yahoo], [https://de.wikipedia.org/wiki/Microsoft Microsoft], [https://de.wikipedia.org/wiki/Facebook_Inc. Facebook], [https://de.wikipedia.org/wiki/AOL AOL], [https://de.wikipedia.org/wiki/PayPal PayPal] und [https://de.wikipedia.org/wiki/LinkedIn LinkedIn].[https://de.wikipedia.org/wiki/DMARC#cite_note-2 [2]][https://de.wikipedia.org/wiki/DMARC#cite_note-3 [3]]
===== Kritik =====
DMARC überprüft den <tt>From</tt>-Header der E-Mails und stellt an diesen strenge Anforderungen (sog. „alignment“). Im Zusammenhang mit E-Mail-Weiterleitungen und Mailinglisten ist dies extrem problematisch, da DMARC verlangt, dass sämtliche Mailinglistensoftware (und E-Mail-Weiterleitungen) den <tt>From</tt>-Header von E-Mails verändert, und die dort angegebene E-Mail-Adresse des Absenders durch die E-Mail-Adresse der Mailingliste bzw. die eigene E-Mail-Adresse ersetzt.[
Beispiel:
From: Nutzer <user@example.org>
Subject: ...
To: [mailto:wikide-l@lists.wikimedia.org wikide-l@lists.wikimedia.org]
müsste durch die Mailinglistensoftware folgendermaßen abgeändert werden:
From: Nutzer via wikide-l <wikide-l@lists.wikimedia.org>
Subject: ...
To: wikide-l@lists.wikimedia.org
Die E-Mail-Adresse des wirklichen Absenders würde hierdurch komplett entfernt, so dass es nicht mehr möglich ist, mit dem Absender direkt in Kontakt zu treten (es sei denn, die Mailingliste fügt einen entsprechenden <tt>Reply-To</tt>-Header hinzu, was aber ebenfalls zu Problemen führt).
DMARC fordert Änderungen an sämtlicher Mailinglisten- und Weiterleitungssoftware.
Dieses prinzipielle Problem im Konzept von DMARC hat dementsprechend auch schon zu schwerwiegenden Problemen bei Mailinglisten geführt („Yahoos DMARC-Policy führt also derzeit dazu, dass Yahoo-Sender den massenhaften Unsubscribe von Mailinglisten-Abonnenten fremder Domains verursachen.“).
===== Einzelnachweise =====
* [https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ Draft Stand: 15. Juli 2013 im IETF Datatracker]
* [http://www.golem.de/1201/89399.html Golem-Artikel vom 30. Januar 2012]
* [http://www.focus.de/digital/digital-news/anti-phishing-allianz-internet-konzerne-wollen-user-besser-schuetzen_aid_708468.html Focus-Artikel vom 30. Januar 2012]
* [https://sys4.de/de/blog/2013/08/11/mailman-dmarc-konform-betreiben/ Nachrichten DMARC-konform mit Mailman verteilen]
* [http://www.heise.de/newsticker/meldung/DMARC-Policy-Yahoo-killt-Mailinglisten-Mitgliedschaften-2168857.html Heise Newsletter: DMARC-Policy: Yahoo killt Mailinglisten-Mitgliedschaften]
===== Weblinks =====
* Offizielle Webseite http://dmarc.org/
* Überblick (PDF; 650&nbsp;kB) (englisch) http://www.dmarc.org/presentations/DMARC_general_overview_20120130.pdf
* Spezifikation (englisch) https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
==== Install DKIM and DMARC on Plesk 12.5 ====
Now a days mail is an unavoidable part of life. How ever the misuse of mail also increasing day by day. Spaming, Spoofing etc. There are many way which can drag you into trouble with your mailbox.
To stop such invalid sender, few new authentication protocol (like SPF, DomainKey) has been started, but it is not enough to stop spammer.
[https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail DKIM] and [https://en.wikipedia.org/wiki/DMARC DMARC] add an extra layer of authentication using an encrypted algorithm.
Recipient mail-server can verify the DKIM signature by recovering the sender’s public key through DNS. It then uses that key to decrypt the hash value in the email’s header and simultaneously recalculate the hash value for the mail message it received.
Unfortunately, Plesk control panel user can not take advantage of this. Till&nbsp;Plesk 12.5, it use old DomainKey, SPF authentication mechanism. Outlook, Exchange server does not like it at all.
Plesk will add DKIM support on upcoming [https://docs.plesk.com/release-notes/17.0/whats-new/ Plesk 17 Onyx].
Understand, what about Plesk 12.x user ?
Don’t worry, follow the tutorial, you will learn, how to '''install DKIM and DMARC on Plesk 12.5'''
First of all I want to thanks to&nbsp;[https://www.linkedin.com/in/ilijamt Ilija Matoski] for his beautiful [https://matoski.com/article/spf-dk-dkim-plesk-debian/ demonstration].
My test environment
OS : CenetOS 7
Plesk : 12.5#43
Postfix version : 2.11
===== Step 1 =====
Install opendkim and add it to system startup script
# yum install opendkim
# chkconfig opendkim on
===== [[Image:Bild19.png|right|top|alt="enable spf plesk"]]Step 2 =====
Turn on SPF and DomainKey on the Plesk
Go to Plesk Panel > Tools & settings > Mail Server Settings
Enable DomainKey signature for outgoing mail
Plesk Panel > Domains > Mail Settings >
Use DomainKeys spam protection system to sign outgoing email messages
===== Step 3 =====
[[Image:Bild34.png|right|top|alt="enable domainkey plesk"]]Generate DKIM key
Add the domain directory. The domain directory contain public and private key.
# mkdir /etc/opendkim/keys/cos701.tld
Generate the keys
cd /etc/opendkim/keys/cos701.tld
opendkim-genkey -d cos701.tld -s mail
chown -Rv opendkim:opendkim /etc/opendkim/keys/cos701.tld
chmod -v u=rw,go-rwx *
Verify the keys
[root@pp1253 plesk-dkim]# ll /etc/opendkim/keys/cos701.tld/
total 8
-rw------- 1 opendkim opendkim 891 Aug 13 07:37 mail.private
-rw------- 1 opendkim opendkim 308 Aug 13 07:37 mail.txt
Domains are ready.
The DNS value for DKIM is stored in the file&nbsp;/etc/opendkim/keys/cos701.tld/mail.txt
[root@pp1253 plesk-dkim]# cat /etc/opendkim/keys/cos701.tld/mail.txt
mail._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC64dnB87OrRTm7FhcVxcof4TJJKJBsTYvmR718dAbUZRFg1/8KtgZHgt/dnmGM+stn8rkEykJzzPWEvajM4YM737vD1yQBlR6ZXyYg4w5WQzgQDJvGfKjmURl5Mq8cuasLw6skVUjO6XmfgxeoB6gt+aai7d4Iq3wawRqT8nsV0QIDAQAB" ) ; ----- DKIM key mail for cos701.tld
===== Step 4 =====
[[Image:Bild35.png|right|top|alt="add dkim to plesk dns"]]Add the value to the DNS “Plesk Panel > Domains > cos701.tld > DNS settings”
Additionally, add the following value for DMARC support
_dmarc.cos701.tld. &nbsp; &nbsp;TXT &nbsp; &nbsp;v=DMARC1; p=quarantine; pct=100; rua=[mailto:postmaster@cos701.tld mailto:postmaster@cos701.tld]
===== Step 5 =====
Configure openDKIM
Add the following value to the ‘/etc/opendkim/TrustedHosts’ file.
127.0.0.1
localhost
123.123.123.123
cos701.tld
ns1.cos701.tld
ns2.cos701.tld
mail.cos01.tld
Add the following value to the ‘/etc/opendkim/SigningTable’. ‘SigningTable’ file is used to list the domains along with their key file path.
# KeyID Domain:Selector:PathToPrivateKey
cos701.tld cos701.tld:mail:/etc/opendkim/keys/myserverplace.de/mail.private
Add the following value to ‘/etc/opendkim/TrustedHosts’.&nbsp;It will list the top trusted hosts as you desire.
@cos701.tld cos701.tld
We need to edit the configuration file to configure DKIM, open /etc/opendkim.conf with your favorite editor and add the following lines to the end of the file
# cp /etc/opendkim.conf{.-bak}
Put the following value to the file
PidFile /var/run/opendkim/opendkim.pid
Mode sv
Syslog yes
SyslogSuccess yes
LogWhy yes
UserID opendkim:opendkim
Socket inet:8891@localhost
Umask 002
Canonicalization relaxed/relaxed
Selector default
MinimumKeyBits 1024
KeyFile /etc/opendkim/keys/default.private
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts
SignatureAlgorithm rsa-sha256
AutoRestart Yes
SignHeaders From,Sender,To,CC,Subject,Message-Id,Date
OversignHeaders From,Sender,To,CC,Subject,Message-Id,Date
===== Step 6 =====
OpenDKIM is properly setup, let’s move on and configure the Postfix.
Open /etc/postfix/main.cf with your favorite editor, and modify the following&nbsp;lines
milter_default_action = accept
milter_protocol = 6
smtpd_milters = , inet:127.0.0.1:8891, inet:127.0.0.1:12768
non_smtpd_milters = $smtpd_milters
Postfix also ready
service postfix restart
===== Step 7 =====
For verification, send mail to the following mail address, you will get instant reply with the result
check-auth@verifier.port25.com
[mailto:AAAA3QcKCQwA@appmaildev.com AAAA3QcKCQwA@appmaildev.com]
The result should be similar like this
==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: pass
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham
Congratulation! you have successfully installed the DKIM on Plesk. It is very great full to me if this tutorial ‘Install DKIM and DMARC on Plesk 12.5’ helpful to you.
==== [http://kb.dynamichosting.biz/display/public/How+To+Setup+DMARC+in+Plesk How To Setup DMARC in Plesk] ====
DMARC stands for “Domain-based Message Authentication, Reporting & Conformance”, it's an&nbsp;email authentication&nbsp;protocol&nbsp;that allows senders and receivers to improve and monitor protection of the domain from fraudulent email. Many ISP's now require DMARC so if you do not have it properly configured your email may not be accepted by those ISP's.&nbsp;
[http://mxtoolbox.com/ mxtoolbox.com]&nbsp;is a great way to tell if your domain is correctly configured for DMARC (as well as SPF).&nbsp;
This is the process to configure DMARC for your account with our [https://dynamichosting.ca/canadian-web-hosting/ Canadian shared hosting] servers:# In the server control panel (Plesk - [http://kb.dynamichosting.biz/display/public/Logging+in+to+Plesk how to log into plesk]) go to your DNS Settings area for the domain you wish to add DMARC for:&nbsp;<br/>[[Image:Bild33.png|right|top]]
# Then, click on the "Add Record" button:<br/>[[Image:Bild7.png]]
# Next select the type as "TXT" and add the following fields and click "OK":
{| class="wikitable options big"
|-
| | Record type
| | TXT
|-
| | Domain name
| | _DMARC
|-
| | TXT record&nbsp;
| | v=DMARC1; p=none; sp=none; rf=afrf; pct=100; ri=86400
|-
|}
# [[Image:Bild18.png|right|top]]The end result should look like this:
# Click the "Update" DNS button as seen here:<br/>[[Image:Bild8.png]]
# Now back in the "Website & Domains" area of Plesk click on the "Mail Settings" Icon for the domain you wish to apply DMARC for as seen here:<br/>[[Image:Bild15.png|right|top]]
# Here at the bottom of the page you will find a checkbox, ensure it is selected and click "OK"<br/>
That should be all you have to do!
[[Image:Bild11.png|right|top]]It takes time for [http://kb.dynamichosting.biz/display/public/How+DNS+Propagation+Works DNS to propagate] but after that has happened you can test that it's working correctly via a free online tool such as&nbsp;[http://mxtoolbox.com/ mxtoolbox.com]&nbsp;and your emails should be DMARC compliant!&nbsp;
==== Using DNSSEC (Linux) ====
DNSSEC is the extension of the DNS protocol that allows signing of DNS data in order to secure the domain name resolving process. For general information about DNSSEC and its usage, visit [https://www.icann.org/resources/pages/dnssec-2012-02-25-en ICANN website] and [https://tools.ietf.org/html/rfc6781 https://tools.ietf.org/html/rfc6781].
Plesk enables you to protect DNS data of hosted domains with DNSSEC. You can do the following: * Configure the settings used for key generation and rollover.
* Sign and unsign domain zones according to the DNSSEC specifications.
* Receive notifications.
* View and copy DS resource records.
* View and copy DNSKEY resource record sets.
===== Requirements =====
* Plesk for Linux with the Bind DNS server, starting from Bind 9.9.
* DNSSEC extension is commercial and is not included by default in Plesk editions.
===== Enabling DNSSEC Support =====
To enable the support for DNSSEC, install the '''Plesk DNSSEC '''extension ('''Extensions''' > '''Extensions Catalog''').
===== Configuring Default DNSSEC Settings =====
The default DNSSEC settings are located in '''Tools & Settings''' > '''Extensions''' > '''DNSSEC'''. You can change the default policy for generating Key Singing Key (KSK) and Zone Signing Key (ZSK) pairs.
'''The recommended policy for KSK and ZSK''':* Use a long key and a long rollover period for the KSK (Key Signing Key).
* Every time the Key Signing Key is updated, the zone owner needs to update the DS records in the parent domain zone. The recommended policy helps to update DS records in the parent zone as seldom as possible without decreasing security.
* Use a shorter key and a shorter rollover period for the ZSK (Zone Signing Key).
* The Zone Signing Key is updated automatically. The recommended policy helps to save system resources without decreasing security.
When hosting customers sign their zones, they can use the default values or specify different values.''' '''For details, see [https://docs.plesk.com/en-US/17.0/administrator-guide/website-management/websites-and-domains/domains-and-dns/configuring-dnssec-for-a-domain.76433/ Using DNSSEC on Domains].
===== Protecting DNS Zones with DNSSEC =====
To use DNSSEC, domain owners must sign their DNS zones.''' '''For details, see [https://docs.plesk.com/en-US/17.0/administrator-guide/website-management/websites-and-domains/domains-and-dns/configuring-dnssec-for-a-domain.76433/ Using DNSSEC on Domains].
===== How Key Rollover Works in Plesk =====
In order to prevent DNS outage for a domain, Plesk uses more than one key as the KSK and more than one key as the ZSK. A previously generated key exists in parallel with a new key for some time, to allow all the changes in a DNS zone to take effect. Obsolete keys are removed automatically.
'''KSK rollover'''
Plesk uses a modification of [https://tools.ietf.org/html/rfc7583#section-3.3.3 Double-RRset method] for rolling over Key Signing Keys, the difference is that Plesk has two Key Signing Keys during each rollover period. This measure allows enough time for the domain zone owner to update the corresponding DS records in the parent zone (for example, the time period between rollover events 1 and 2 in the scheme below).
'''User actions at KSK rollover'''
The domain zone owner is notified about the rollover and about the need to update the DS records in the parent zone. The DS records become obsolete when the oldest KSK expires and the newest KSK is generated (for example, at rollover event 2 in the scheme below). If the domain zone owner did not update the DS records in the parent zone, then at the end of one rollover period after the notification the domain stops resolving.
'''ZSK rollover'''
To allow enough time for slave and caching DNS servers to sync with the master DNS server, Plesk does the following:* Adds a new key to the zone at a certain time before the rollover event.
* Removes the previous key at the same certain time after the rollover event.
This certain time before or after a ZSK rollover is called a ''transition period'' in Plesk. The transition period is either 30 days or the sum of zone's SOA TTL and SOA Expire values (if their sum is over 30 days). However, the transition period cannot be longer than half the ZSK rollover period, otherwise the rollover functionality will be disrupted and the zone signatures will become invalid.
Therefore, to make sure that ZSK rollover is performed correctly, Plesk sets limits on the following values:* The zone's SOA TTL and SOA Expire. Their sum cannot be longer than a certain calculated value.
* The ZSK rollover period. It cannot be shorter than a certain calculated value.
'''User actions at ZSK rollover'''
No actions are required of the domain's DNS zone owner when Zone Signing Keys are rolled over.


[[Kategorie:E-Mail/Protokolle]]
[[Kategorie:E-Mail/Protokolle]]
[[Kategorie:Spam]]
[[Kategorie:Spam]]

Aktuelle Version vom 12. Juli 2026, 09:42 Uhr

DMARC - Domain-based Message Authentication, Reporting and Conformance

Beschreibung

DMARC ist eine Spezifikation, um den Missbrauch von E-Mails zu reduzieren

DMARC versucht, bestehende Unzulänglichkeiten im Zusammenhang mit der Authentifizierung von E-Mails zu beheben

  • wurde bei der IETF zur Standardisierung eingereicht

Überblick

DMARC baut auf den Techniken Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM) auf, indem es für eine Absender-Domain festlegt, wie der Empfänger die Authentifizierung von E-Mails durchführen soll und wie im Falle eines Fehlers zu verfahren ist.

  • Während die vorgenannten Techniken beschreiben, wer eine Mail versenden darf (SPF) bzw. sicherstellen, dass diese Mail in bestimmter Weise unverändert vom Absender stammt (DKIM), kann der Absender nach der DMARC-Spezifikation zusätzlich Empfehlungen geben, auf welche Art der Empfänger mit einer Mail umgeht, die in einem oder beiden Fällen nicht den Anforderungen entspricht.
  • Sofern der Empfänger einer E-Mail die DMARC-Spezifikation anwendet, ist dadurch eine konsistente Überprüfung der Authentizität dieser E-Mail gesichert.

Die DMARC-Richtlinie für eine Absender-Domain kann der Empfänger einem Eintrag im Domain Name System (DNS) entnehmen.

Die DMARC-Spezifikation entstand unter anderem auf Initiative von Google, Yahoo, Microsoft, Facebook, AOL, PayPal und LinkedIn

Aufbau einer DMARC-Richtlinie

DMARC verwendet, so wie auch SPF und DKIM, TXT-Records im DNS.

  • Für eine Absender-Domain wird auf der Subdomain _dmarc ein Resource Record angelegt, der die DMARC-Richtlinie für diese Absender-Domain enthält.

Folgend ist ein Beispiel dargestellt, wie DMARC im TXT-Record von _dmarc.example.org konfiguriert sein könnte: 

v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@example.org;ruf=mailto:forensik@example.org;adkim=s;aspf=r
Abkürzung Bedeutung
v Protokollversion
pct Prozentualer Anteil der zu filternden Mails
ruf Forensischer Report wird versandt an:
rua Aggregierter Report wird versandt an:
p Anweisung, wie mit Mails der Hauptdomäne zu verfahren ist.
sp Anweisung, wie mit Mails der Subdomäne zu verfahren ist.
adkim Abgleichmodus für DKIM
aspf Abgleichmodus für SPF

Besondere Bedeutung haben die Abgleichmodi: Für SPF fordert die DMARC-Spezifikation, dass erstens die Überprüfung positiv ausfällt und zweitens die From Kopfzeile der Mail dieselbe Domäne aufweist, wie im SPF-Record hinterlegt.

  • Für DKIM wird gefordert, dass die Signatur gültig ist und zusätzlich die dort genannte Domäne dieselbe ist, wie in der From Kopfzeile der Mail.
  • Als Abgleichmodi sind s für 'strict' bzw. r für 'relaxed' vorgesehen.
  • Bei 'strict' müssen die Domänen exakt übereinstimmen, bei 'relaxed' darf die From Kopfzeile auch eine Subdomäne enthalten. Über die Auswertung erhält der Sender einen täglichen Report an die genannte Adresse.

Die Policy (hier abgekürzt als 'p' bzw. 'sp' für Subdomains) legt schließlich fest, wie der Empfänger mit der Mail verfahren soll, wenn die Überprüfung scheitert.

  • Vorgesehene Modi hierfür sind 'none', 'quarantine' und 'reject'. 'none' (auch als Monitormodus bezeichnet) wird in der Regel zum Testen verwendet und macht dem Empfänger keine Vorschriften über die Verfahrensweise. 'quarantine' verlangt die Kennzeichnung der Mails als Spam, 'reject' verlangt, die Mail zu verwerfen.

Kritik

DMARC überprüft den From-Header der E-Mails und stellt an diesen strenge Anforderungen (sog. "alignment").

  • Im Zusammenhang mit E-Mail-Weiterleitungen und Mailinglisten ist dies problematisch, da DMARC verlangt, dass die Absenderangabe im From-Header der E-Mail durch die Adresse der Mailingliste oder die eigene Adresse ersetzt wird.[1] Beispiel:
From: Nutzer <user@example.org>
Subject: ...
To: wikide-l@lists.wikimedia.org

muss entsprechend DMARC durch die Mailinglistensoftware folgendermaßen abgeändert werden: 

From: Nutzer via wikide-l <wikide-l@lists.wikimedia.org>
Subject: ...
To: wikide-l@lists.wikimedia.org

Die E-Mail-Adresse des wirklichen Absenders wird bei dieser Ersetzung komplett entfernt, so dass es nicht mehr möglich ist, den tatsächlichen Absender zu ermitteln oder mit dem Absender direkt in Kontakt zu treten.

  • Eine Option besteht darin, dass die Mailingliste den ursprünglichen Absender in alternativen Kopfdaten wie den Reply-To-Header einfügt, was aber ebenfalls zu Problemen führen kann.
  • Eine Lösung für dieses Problem existiert nicht.

DMARC fordert Änderungen an jeder Mailinglisten- und Weiterleitungssoftware.

  • Das Konzept von DMARC hat dementsprechend auch zu Problemen bei Mailinglisten geführt

Normen und Standards

  • RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC), 2015

Quellen

  1. https://de.wikipedia.org/wiki/DMARC
  1. ↑ Nachrichten DMARC-konform mit Mailman verteilen
Abgerufen von „https://wiki.foxtom.de/index.php?title=DMARC&oldid=171473“