Einer der Vorteile eines eigenen Mailservers ist, dass man hier so restriktiv in seiner Konfiguration sein kann wie man es selbst für sich und seine Zwecke für richtig erachtet. So habe ich für mich entschieden, dass ich nur E-Mails annehmen möchte, welche über eine Transportverschlüsselung (TLS) bei mir eingeliefert werden. Wer also die folgende Meldung in seiner Errormail hat, dessen Mailserver hat sicher probiert die E-Mail bei mir ohne Transportverschlüsselung (also im Klartext) abzuliefern.
[...]
530-5.7.0 Must issue a STARTTLS command first
530 5.7.0 For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com
[...]
Transportverschlüsselung ist dabei bitte nicht zu verwechseln mit einer signierten oder gar verschlüsselten E-Mail. Ich nehme auch E-Mails an, welche weder signiert oder verschlüsselt sind. Die Transportverschlüsselung ist hier etwas wie das s bei httpS://. Das Mitlesen der E-Mail auf dem Weg zwischen eurem und meinem Mailserver soll damit nach Möglichkeit verhindert werden.
Möglichst verhindert werden? Ja, einen 100%tigen Schutz gibt es selbstverständlich nicht. Man kann nur versuchen sich diesem zu nähern. Dieses Nähern betrifft nun den zweiten Punkt welcher verhindern könnte, dass ihr mir eine E-Mail senden könnt. Die eingesetzte Transportverschlüsselung muss nämlich als „sicher“ gelten. Ich nehme also keine SSLv3 RC4 MD5 bla Verbindungen an. Wer also etwas wie das Folgende oder halt „Verbindung nicht möglich“ bekommt, dessen Mailserver ist nicht in der Lage eine „sichere“ TLS Verbindung aufzubauen.
Warum macht dieses nun nicht jeder so? Nun… Möchte man als Unternehmen Geld damit verdienen, dass man in irgendeiner Form Benutzer dazu bringt bei einem einen E-Mail Service zu nutzen, dann möchte man natürlich seinen Kunden einen möglichst reibungsfreien Austausch ermöglichen. Denn der normale Benutzer wird es kaum verstehen und sicher einfach einen Anbieter wählen bei dem es „funktioniert“. Dieses könnte man daher als Grund anführen warum nicht jeder so restriktiv in seinen Empfangseinstellungen ist. Davon abgesehen hindert es kein Unternehmen daran, seinem Mailserver für ausgehende E-Mails die Möglichkeit zu schaffen gutes TLS zu sprechen. Ok, es sei denn dieser Server steht in China oder Nordkorea. Mein Mailserver ist also weit davon entfernt etwas Unmögliches zu verlangen!!!
Sprecht also mal mit der zuständigen Person eures Mailservers und fragt aus welchem Grund euer Mailserver nicht in der Lage ist sicheres TLS zu sprechen und ob man dieses nicht vielleicht doch ändern könnte!
Um mich in der Zwischenzeit dennoch irgendwie zu erreichen gibt es verschiedene Möglichkeiten welche man >>hier<< findet. Am einfachsten sicher über Matrix/Riot: @kernel-error:kernel-error.com.
Veraltet: Der dedizierte SPF-DNS-Record-Typ (Typ 99) wurde mit RFC 7208 als deprecated eingestuft. SPF wird ausschließlich über TXT-Records veröffentlicht. Siehe den aktuellen SPF-Beitrag.
Da ich es gerade mal wieder auf dem Tisch habe…. Ja, „früher“ konnte man verschiedene RECORDS im DNS setzten um SPF-RECORDS zu veröffentlichen. So auch einen Record Type mit dem direkten Namen SPF. Seit 2014 ist dem aber nicht mehr so! Denn ab jetzt soll man seine SPF-Records nur noch als TXT-Record (RFC1035 Typ 16) veröffentlichen. Dieses steht im fertigen RFC7208 Abschnitt 3.1.
Damit also bitte die ganzen anderen RECORDS zu SPF aus dem DNS entfernen und nur noch TXT-RECORDS einsetzten. Ich freue mich darüber, denn bisher musste man sonst eine Vielzahl verschiedener Records pflegen, da man sich nicht sicher sein konnte, welchen jetzt bitte die Implementierung des Empfängers nutzt. Zugegeben, die Basis TXT war die am meisten verbreitete Version. Denn noch gab es da hin und wieder ein Problem. Nun steht das RFC bereits einige Zeit fest, und ich habe alle anderen „SPF-RECORDS“ aus dem DNS entfernt. Nun also nur noch TXT bei mir.
Mailgraph von David Schweikert ist ein simples Perl-Script, das Postfix-Logdateien parst und daraus RRDtool-Graphen erzeugt. Empfangene, gesendete, abgelehnte Mails auf einen Blick. Für kleinere Mailserver oder Testsysteme reicht das völlig.
Was mailgraph nicht kann: SPF-, DMARC– und DKIM-Ergebnisse darstellen. Wie viele Mails bestehen den SPF-Check? Wie oft schlägt DMARC fehl? Gibt es einen Trend? Ich habe zwar einen existierenden SPF-Patch für mailgraph gefunden, wollte aber alle drei Protokolle in einem Aufwasch.
Die folgenden Patches erweitern mailgraph 1.14 um drei zusätzliche Graphen: SPF (pass/none/fail), DMARC (pass/none/fail) und DKIM (pass/none/fail). Ausgelegt für Postfix mit postfix-policyd-spf, opendkim und opendmarc.
Installation
Auf einem Debian-System müssen zwei Dateien ersetzt werden: /usr/sbin/mailgraph (der Daemon) und /usr/lib/cgi-bin/mailgraph.cgi (die Weboberfläche). Vorher sichern.
Der Daemon-Patch fügt neun RRD-Datasources hinzu (spfnone, spffail, spfpass, dmarcnone, dmarcfail, dmarcpass, dkimnone, dkimfail, dkimpass) und parst die Logzeilen von policy-spf, opendmarc und opendkim:
Der CGI-Patch erzeugt die drei neuen Graphen (SPF, DMARC, DKIM) und bindet sie in die HTML-Ausgabe ein. Jeder Graph zeigt pass als Fläche, none als Stack und fail als Linie:
Der Daemon-Patch erweitert die RRD-Datenbank um neun Datasources und erkennt im Syslog die Ausgaben von drei Diensten:
Dienst
Log-Pattern
Ergebnis
policy-spf
Received-SPF: pass/none/*
spfpass, spfnone, spffail
opendmarc
pass/none/fail
dmarcpass, dmarcnone, dmarcfail
opendkim
DKIM verification successful / no signature data / bad signature data
dkimpass, dkimnone, dkimfail
Der CGI-Patch erzeugt drei neue Graphen unterhalb der bestehenden. Jeder zeigt pass als Fläche, none als Stack darüber und fail als rote Linie. Die Zeiträume (Tag, Woche, Monat, Jahr) werden wie bei den Standard-Graphen automatisch erzeugt.
Hinweise
Die Patches sind für mailgraph 1.14 geschrieben. Weil mailgraph die RRD-Datasources beim ersten Start festlegt, muss nach dem Patchen die bestehende mailgraph.rrd gelöscht werden. Die alten Daten gehen dabei verloren, die neuen Graphen fangen bei Null an.
Wer heute mit dem Monitoring anfängt: rspamd bringt eine eigene Weboberfläche mit und prüft SPF, DKIM und DMARC in einem Durchgang. Zusammen mit Prometheus und Grafana bekommt man deutlich flexiblere Dashboards als mit RRDtool. Mailgraph bleibt trotzdem nützlich wenn man schnell was Schlankes braucht, das ohne externe Abhängigkeiten läuft.
Eine DMARC-Policy zu veröffentlichen ist die eine Seite. Die andere ist, eingehende Mails gegen die DMARC-Policy des Absenders zu prüfen. Postfix kann das nicht selbst. Dafür gibt es zwei Wege: OpenDMARC als eigenständigen Milter oder rspamd, der DMARC als eines von vielen Modulen mitbringt.
Variante 1: OpenDMARC
OpenDMARC ist ein dedizierter DMARC-Milter. Er liest die Ergebnisse von SPF und DKIM aus den Mailheadern und prüft ob die DMARC-Policy des Absenders erfüllt ist.
RejectFailures false ist ein guter Startwert. Damit werden Mails die den DMARC-Check nicht bestehen nicht sofort abgelehnt, sondern nur markiert. So kann man erst beobachten bevor man scharf schaltet. AuthservID muss zum Hostnamen des Mailservers passen.
Wichtig: OpenDMARC verlässt sich darauf, dass SPF und DKIM bereits geprüft wurden und die Ergebnisse in den Authentication-Results-Headern stehen. Die Reihenfolge der Milter in Postfix ist daher entscheidend: SPF und DKIM müssen vor OpenDMARC laufen.
Postfix-Integration
In der main.cf den Milter registrieren. OpenDMARC muss nach dem DKIM-Milter stehen:
Port 8891 ist hier OpenDKIM, Port 8893 OpenDMARC. Nach einem postfix reload prüft OpenDMARC jede eingehende Mail und schreibt einen Authentication-Results-Header mit dem DMARC-Ergebnis.
Variante 2: rspamd
Wer rspamd als Spamfilter einsetzt, braucht keinen separaten DMARC-Milter. rspamd prüft SPF, DKIM und DMARC in einem Durchgang und verrechnet das Ergebnis mit dem Gesamtscore. Das DMARC-Modul ist standardmäßig aktiv und unterstützt auch DMARC-Reporting (rua/ruf).
Der Vorteil von rspamd: Statt einer harten Ablehnung bei DMARC-Fail fließt das Ergebnis in die Gesamtbewertung ein. Eine Mail die DMARC nicht besteht aber sonst sauber aussieht, wird nicht sofort abgelehnt. Umgekehrt kann eine Mail die DMARC besteht trotzdem als Spam markiert werden wenn andere Indikatoren dagegen sprechen.
Was passt besser?
OpenDMARC
rspamd
Aufwand
Eigener Dienst, eigene Config
Bereits als Milter integriert
Verhalten
Harte Entscheidung (reject/accept)
Score-basiert, flexibel
Reporting
Eigenes Reporting-Tool nötig
rua-Reports eingebaut
Abhängigkeiten
Braucht SPF/DKIM in den Headern
Prüft SPF/DKIM selbst
Für neue Setups ist rspamd meist die bessere Wahl, weil es SPF, DKIM, DMARC, ARC und Spam-Filterung in einem Paket liefert. OpenDMARC ist sinnvoll wenn man einen minimalen Stack ohne Content-Filter will oder bereits einen anderen Spamfilter einsetzt.
Übrigens: DMARC und Mailinglisten vertragen sich nicht ohne Weiteres. ARC löst das Problem. Fragen? Einfach melden.
Na was lese ich denn da wieder bei golem.de? Yahoo soll Mailinglisten kaputt machen weil DMARC eingesetzt wird?
Über DMARC habe ich ja schon etwas geschrieben, auch dass man mit Mailinglisten Probleme bekommen kann, wenn man eine Policy veröffentlicht. Denn die meisten Mailinglisten arbeiten leider nicht DKIM konform. Denn DKIM signiert den Body und ebenfalls den Betreff einer E-Mail. Wenn die Mailingliste nun den Betreff ändert um ein [Mailinglistenname] in den Betreff zu schreiben (damit die Anwender darüber besser „filtern“ können und wegen Übersicht bla bla). Sowie einen kleinen Footer mit Infos zur Liste in den Body hängen, ja dann ist die DKIM Signatur ungültig. Soll ja so sein! Mailinglisten lassen sich prima über den Mail-Header: List-id Filtern, die Infos zur Mailingliste im Footer liest eh keiner und es produziert nur unnötig viele Daten, da sie an jede E-Mail gehangen werden. Übersicht? Filtert man seine E-Mail sauber und sortiert sie in die passenden Ordner, dann ist die Übersicht gegeben.
Wie auch immer… DKIM Signaturen werden durch Mailinglisten schon seit vielen Jahren gebrochen. Einige Mailinglisten werfen sogar die DKIM Signaturen aus den E-Mails bevor sie „weitergeleitet“ werden. Damit kann es zwar keine ungültige/gebrochene Signatur mehr geben, in Kombination mit einer DMARC Policy gibt es denn noch ein Problem. Denn wenn in der Policy steht: E-Mails sind immer DKIM und SPF signiert und wenn sie es nicht sind oder wenn die Signatur ungültig ist, dann weise die E-Mail zurück. Dann passiert das so!
All dieses ist schon seit längerem fest in ein RFC gegossen. Eingesetzt wird DMARC bereits von vielen der großen Anbieter… Bisher war nur noch keiner cool genug es „scharf“ zu schalten. Ist völlig legitim, denn auch die Mailinglisten Admins sollen eine gewisse „Übergangszeit“ haben. Wie so oft hat nur kaum einer reagiert. Ist ja nur mal wieder Security oder Features welche die User nicht direkt betreffen. Ja, es ist eine gewisse Art ~Vergewaltigung~!
Der DMARC-RECORD von yahoo.com gibt eine klare Policy vor:
Wer eine strenge DMARC-Policy veröffentlicht und gleichzeitig Mailinglisten nutzt, wird früher oder später feststellen: Die eigenen Mails werden auf der Liste zugestellt, aber beim Empfänger abgelehnt. Das liegt nicht an einem Konfigurationsfehler, sondern an der Art wie Mailinglisten funktionieren.
Das Problem
DKIM signiert nicht nur den Body einer E-Mail, sondern auch bestimmte Header wie den Betreff. Mailinglisten-Manager wie Mailman verändern die Mail aber auf dem Weg zum Empfänger. Sie hängen einen Identifier an den Betreff ([liste-name]), fügen einen Footer mit Abmelde-Link an den Body an und setzen eigene Header. Jede dieser Änderungen bricht die DKIM-Signatur.
SPF schlägt ebenfalls fehl, weil die Mail jetzt vom Listserver kommt und nicht mehr vom Mailserver des ursprünglichen Absenders. Die IP des Listservers steht nicht im SPF-Record der Absender-Domain.
DMARC prüft ob mindestens DKIM oder SPF bestehen und das Alignment stimmt. Beides schlägt fehl. Bei einer Policy von p=reject wird die Mail vom empfangenden Server abgelehnt. Der Absender bekommt einen Bounce, der Empfänger sieht die Mail nie.
Workarounds der Listenbetreiber
Mailinglisten-Manager haben verschiedene Strategien entwickelt um das Problem zu umgehen:
From-Rewriting
Der Absender wird auf die Listenadresse umgeschrieben. DMARC-Alignment passt dann zur Listendomain. Nachteil: Man sieht nicht mehr wer die Mail geschrieben hat.
Subject-Tag weglassen
Kein [liste] im Betreff. Schont die DKIM-Signatur, aber der Betreff allein reicht nicht, die Signatur kann trotzdem brechen wenn der Body verändert wird.
Footer weglassen
Kein Abmelde-Link im Body. Schont DKIM, aber Listenbetreiber brauchen den Footer oft aus rechtlichen Gründen.
DKIM re-signing
Die Liste signiert die Mail neu mit ihrer eigenen Domain. Funktioniert, aber die originale Signatur des Absenders geht verloren.
Keiner dieser Workarounds ist sauber. Entweder geht Information verloren oder die Authentizität leidet.
ARC: Die eigentliche Lösung
Authenticated Received Chain (RFC 8617) wurde genau für dieses Problem entwickelt. Die Idee: Jeder Zwischenserver (wie ein Listserver) speichert die Authentifizierungsergebnisse der eingehenden Mail in einem ARC-Header und signiert diesen. Der empfangende Server kann dann die Kette zurückverfolgen und sehen, dass die Mail beim Eintritt in die Liste noch gültig war.
ARC-Authentication-Results enthält die Ergebnisse zum Zeitpunkt der Annahme. ARC-Message-Signature signiert die Nachricht in ihrem aktuellen Zustand. ARC-Seal signiert die gesamte ARC-Kette und verhindert Manipulation.
Der empfangende Mailserver prüft die ARC-Kette. Wenn er dem Listserver vertraut und die Kette gültig ist, kann er die Mail trotz gebrochener DKIM-Signatur zustellen. Gmail, Microsoft und Yahoo werten ARC bereits aus. rspamd unterstützt ARC-Validierung und ARC-Signing von Haus aus.
In der Praxis
Mailman 3 unterstützt ARC-Signing. Bei Mailman 2 lässt sich ARC über einen vorgeschalteten Milter nachrüsten. Wer rspamd als Milter einsetzt, kann ARC dort aktivieren und braucht keinen separaten Dienst.
Die Empfehlung für Listenbetreiber: ARC-Signing aktivieren und den Betreff nicht verändern (statt [liste] den List-Id-Header nutzen, den alle modernen Mailclients auswerten können). Für Absender mit p=reject: ARC reduziert das Problem erheblich, löst es aber nur wenn die Gegenseite ARC auch prüft. In der Übergangsphase hilft es, bekannte Listserver per DMARC-Whitelist von der Policy auszunehmen.
Am besten gefällt mir dabei der SPF Test, denn dieser sammelt auch gleich alle nötigen DNS Lookups zusammen und visualisiert sie einem recht ansprechend.
Bunte Bilder *wwwööööööööööhhhhhhhhhyyyyyyyyy*
Ja, wenn es hilft schick mir eine E-Mail und ich sage dir ob deine Konfiguration sauber ist.
SPF (Sender Policy Framework, RFC 7208) legt per DNS fest, welche Server für eine Domain E-Mails versenden dürfen. Empfangende Mailserver prüfen bei jeder eingehenden Mail, ob die IP-Adresse des sendenden Servers im SPF-Record der Absenderdomain steht. Steht sie nicht drin, wird die Mail je nach Policy abgewiesen oder markiert.
Aufbau eines SPF-Records
Ein SPF-Record ist ein TXT-Record im DNS der Domain. Ein typisches Beispiel:
kernel-error.de. IN TXT "v=spf1 ip4:148.251.30.205 ip6:2a01:4f8:262:4716::25 mx -all"
Wichtig: Der alte DNS-Record-Typ IN SPF ist seit RFC 7208 (2014) abgeschafft. Nur IN TXT verwenden.
Mechanismen
Jeder Mechanismus definiert eine Regel, gegen die die IP des sendenden Servers geprüft wird:
ip4:148.251.30.205
Diese IPv4-Adresse darf senden. Auch Netze möglich: ip4:148.251.30.0/24
ip6:2a01:4f8:...
Diese IPv6-Adresse darf senden
mx
Alle IP-Adressen der MX-Records der Domain dürfen senden
a
Die IP-Adresse des A/AAAA-Records der Domain darf senden
a:smtp.example.de
Die IP-Adresse eines bestimmten Hosts darf senden
include:example.de
Die SPF-Policy einer anderen Domain mit einbeziehen (z.B. für externe Dienstleister)
redirect=example.de
Gesamte SPF-Policy von einer anderen Domain übernehmen
Nicht mehr verwenden: Der ptr-Mechanismus ist seit RFC 7208 explizit nicht empfohlen. Er erzeugt unnötige Reverse-DNS-Abfragen und ist fehleranfällig.
Qualifier: Was passiert bei einem Treffer?
Vor jedem Mechanismus kann ein Qualifier stehen, der bestimmt, was mit der Mail passiert:
+ (Pass)
Erlaubt (Standard, wenn kein Qualifier angegeben)
- (Fail)
Nicht erlaubt — Mail soll abgewiesen werden
~ (SoftFail)
Nicht erlaubt, aber nicht hart ablehnen — Mail markieren
? (Neutral)
Keine Aussage — wie kein SPF
Hardfail oder Softfail?
Am Ende des SPF-Records steht der Catch-All-Mechanismus all mit einem Qualifier:
-all (Hardfail) — alle Server die nicht explizit gelistet sind, dürfen nicht senden. Empfänger soll ablehnen.
~all (Softfail) — alle nicht gelisteten Server sind verdächtig, aber nicht definitiv verboten. Mail wird zugestellt, aber markiert.
In der Praxis: -all ist die klare Empfehlung, wenn man weiß, welche Server für die Domain senden. ~all war lange der konservative Ansatz, weil manche Empfänger SPF-Fails zu aggressiv behandelten. Seit DMARC den Umgang mit SPF-Ergebnissen standardisiert hat, ist das kein Argument mehr. Wer DMARC einsetzt, sollte -all verwenden.
Das 10-Lookup-Limit
RFC 7208 erlaubt maximal 10 DNS-Abfragen pro SPF-Prüfung. Jeder include, mx, a und redirect zählt als Lookup. ip4 und ip6 verursachen keine Abfrage, die stehen direkt im Record.
Das wird schnell zum Problem, wenn man externe Dienstleister einbindet. Ein include:_spf.google.com zieht allein schon 3-4 weitere Lookups nach sich. Wer Office 365, Google Workspace und einen Newsletter-Dienst kombiniert, sprengt das Limit leicht. Die Fehlermeldung:
PermError SPF Permanent Error: Too many DNS lookups
Lösung: Den SPF-Record so schlank wie möglich halten. Wo möglich ip4/ip6 statt include verwenden, das verbraucht keine Lookups. Externe Dienstleister nach IP-Ranges fragen statt blind deren Include-Ketten zu übernehmen.
SPF-Record testen
# SPF-Record abfragen
dig TXT kernel-error.de +short
# Ergebnis prüfen — sollte den v=spf1 Record zeigen
# Mehrere TXT-Records sind normal (SPF, DMARC, DKIM Policy etc.)
Für einen vollständigen Check mit Lookup-Zählung eignen sich Online-Tools wie kitterman.com/spf oder mxtoolbox.com. Die zeigen auch verschachtelte Includes auf und warnen bei Überschreitung des 10-Lookup-Limits.
SPF allein reicht nicht
SPF prüft die IP-Adresse gegen den Envelope-From (die Adresse aus dem SMTP-MAIL FROM-Kommando), nicht gegen den From:-Header, den der Empfänger sieht. Ein Angreifer kann also eine Mail mit gefälschtem From:-Header senden, solange der Envelope-From eine Domain ist, die er kontrolliert. Der Empfänger sieht den gefälschten Absender, SPF sagt trotzdem „Pass“.
Genau dieses Problem löst DMARC: Es prüft, ob die Domain im From:-Header mit der SPF-Domain (Alignment) oder der DKIM-Signatur übereinstimmt. Erst SPF + DKIM + DMARC zusammen ergeben eine vollständige E-Mail-Authentifizierung. Fragen? Einfach melden.
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) baut auf SPF und DKIM auf. Es löst zwei Probleme, die SPF und DKIM allein offen lassen: Erstens kann der Absender festlegen, was mit Mails passieren soll, die weder SPF noch DKIM bestehen. Zweitens bekommt der Absender Berichte darüber, wie seine Mails bei den Empfängern ankommen.
DMARC-Record aufbauen
DMARC wird als TXT-Record unter _dmarc.domain.de im DNS veröffentlicht. Ein Beispiel:
_dmarc.kernel-error.de. IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de"
Die einzelnen Parameter:
v=DMARC1
Protokollversion (immer DMARC1)
p=quarantine
Policy für die Hauptdomain (siehe unten)
sp=quarantine
Policy für Subdomains (optional, erbt sonst von p)
adkim=s
DKIM-Alignment: s = strict, r = relaxed
aspf=s
SPF-Alignment: s = strict, r = relaxed
pct=100
Prozent der Mails, auf die die Policy angewendet wird
rua=mailto:...
Adresse für aggregierte Berichte (täglich, XML)
ruf=mailto:...
Adresse für forensische Berichte (pro Vorfall)
Alignment: Wofür DMARC wirklich da ist
SPF prüft den Envelope-From, DKIM prüft die signierende Domain. Beides sagt nichts über den From:-Header aus, den der Empfänger tatsächlich sieht. DMARC schließt diese Lücke mit dem sogenannten Alignment: Es verlangt, dass mindestens eine der beiden Prüfungen (SPF oder DKIM) zur Domain im From:-Header passt.
Strict (s) bedeutet: Die Domains müssen exakt übereinstimmen. Relaxed (r) erlaubt auch Subdomains (z.B. mail.kernel-error.de passt zu kernel-error.de). Für die meisten Setups ist strict die richtige Wahl, solange alle ausgehenden Mails über die Hauptdomain signiert werden.
Policy-Stufen
Der p-Parameter legt fest, was der Empfänger mit Mails machen soll, die weder SPF noch DKIM bestehen:
p=none
Nur beobachten, nichts tun. Gut zum Einstieg, um über die Reports erstmal zu sehen was passiert.
p=quarantine
Als Spam markieren. Die Mail wird zugestellt, landet aber im Spam-Ordner.
p=reject
Ablehnen. Die Mail wird gar nicht erst angenommen.
Der empfohlene Weg: Mit p=none anfangen und die Reports auswerten. Wenn alles sauber aussieht, auf quarantine hochdrehen. Wenn auch das stabil läuft, auf reject gehen. Mit pct kann man die Policy schrittweise ausrollen, z.B. erst auf 10% der Mails anwenden und dann langsam erhöhen.
Reporting
Die aggregierten Reports (rua) kommen einmal am Tag als komprimierte XML-Dateien per Mail. Darin steht, welche IPs Mails mit deiner Domain versendet haben und ob SPF/DKIM bestanden oder durchgefallen sind. Das ist Gold wert: Man sieht sofort, ob jemand die Domain missbraucht oder ob ein legitimer Dienst falsch konfiguriert ist.
Die XML-Dateien sind nicht besonders lesefreundlich. Zum Auswerten eignet sich dmarcian.com (XML hochladen, menschenlesbare Übersicht bekommen) oder man baut sich eine eigene Auswertung. Für größere Setups gibt es Open-Source-Tools wie parsedmarc, die Reports automatisch verarbeiten und in Elasticsearch oder eine Datenbank schieben.
Die forensischen Reports (ruf) liefern Details zu einzelnen fehlgeschlagenen Mails. In der Praxis schicken die meisten großen Provider (Google, Microsoft) allerdings keine forensischen Reports mehr, aus Datenschutzgründen. Die aggregierten Reports reichen für die meisten Fälle aus.
Cross-Domain-Reporting
Wer mehrere Domains betreibt und die Reports zentral an eine Adresse schicken will, muss aufpassen. Soll der Report für kernel-error.com an postmaster@kernel-error.de gehen, muss die Empfänger-Domain das erlauben. Dafür braucht es einen zusätzlichen TXT-Record in der Zone von kernel-error.de:
kernel-error.com._report._dmarc.kernel-error.de. IN TXT "v=DMARC1"
Dieser Record sagt: „kernel-error.de akzeptiert DMARC-Reports für kernel-error.com.“ Ohne diesen Eintrag ignorieren Empfänger die Report-Adresse, weil sie in einer fremden Domain liegt.
Einen vollständigen Check inklusive SPF und DKIM bekommt man über mxtoolbox.com oder ähnliche Online-Tools. Einfach eine Testmail an die Prüfadresse schicken und den Report abwarten.
Das Zusammenspiel
DMARC funktioniert nur zusammen mit SPF und DKIM. Alle drei zusammen ergeben eine vollständige E-Mail-Authentifizierung: SPF legt fest welche Server senden dürfen, DKIM signiert die Mail kryptografisch und DMARC verknüpft beides mit einer Policy und liefert Feedback. Wer das Ganze mit rspamd betreibt, hat Auswertung und Enforcement gleich mit dabei. Fragen? Einfach melden.
Ich war mal wieder auf so einem lustigen Postfixvortrag… Die verschiedenen Möglichkeiten der Spamabwehr waren natürlich wieder Thema. Der Vortragende ist dabei tierisch auf sender adress verification abgegangen. Er hat es quasie als Lösung aller Probleme verkauft. Puhh, ich habe mich bald an der Mate verschluckt. Ich mein… OK in ganz besonderen Fällen kann es möglicherweise helfen (mir fallen zwar gerade keine ein aber…) und früher ging da vielleicht mal was. Im Grunde macht diese Art der „Spamabwehr“ nur Stress.
Versucht jemand eine E-Mail einzuliefern, versucht Postfix vor der Annahme der E-Mails zuerst selbst eine E-Mail an den Absender zuzustellen. Klappt dieses nimmt er die E-Mail an und wenn es nicht geht, dann nicht. Kommt also eine E-Mail vom Absender: spam@spamgott.net versucht Postfix diesem Absender eine E-Mail zuzustellen. Es wird also geprüft ob es die Domain überhaupt gibt, dann wird geschaut ob es einen MX-RECORD gibt, dann wird versucht eine Verbindung zu diesem Server aufzubauen. Ist es nicht möglich würde Postfix die jeweilige Meldung an den einliefernden „durchreichen“. Damit würden E-Mails nicht abgewiesen nur weil der Maileingangsserver des vermeintlichen Absenders gerade Stress hat oder dort Greylisting aktiviert ist. Wäre es möglich eine E-Mail einzuliefern wird die E-Mail erst überhaupt angekommen und die Absenderadresse in folgender Datei abgelegt:
/var/lib/postfix/verify_cache.db
Aktiviert wird der ganze Foo in der Postfix Konfigurationsdatei /etc/postfix/main.cf:
Klingt alles erst einmal ganz gut, oder? Ne überhaupt nicht…. Die Idee ist nett aber wenn man sich nun mal vorstellt eine Domain wird zum versenden von Spam missbraucht, dann schlagen bei diesem Server nicht nur die ganzen Bounce E-Mails auf, sondern zusätzlich noch der ganze Verification Krims. Es soll auch Absender geben die man wirklich nicht erreichen kann (sinnfrei, ist mir auch klar). Diese E-Mails kommen natürlich nicht an…. Versucht immer mal wieder jemand E-Mails an Empfänger zuzustellen, welche es nicht gibt, machen Mailserver gerne mal für eine gewisse Zeit dicht. Was ebenfalls nicht gut ist.
Und mal im Ernst, niemand will wirklich Strom, Traffic und Hardwareleistung bezahlen für den Mist. Wenn man sich einfach nur unnötige Last auf sein System ziehen will, wäre SETI@home mein Tipp! Mit etwas Hirnschmalz in seine Konfiguration gibt es deutlich bessere und effektivere Möglichkeiten. Dieser Weg ist einfach mal wieder der Versuch die Arbeit anderen aufzuhalsen.