DKIM-Signatur Implementierung

•  Modifikationen von Mails auf dem Weg werden erkennbar.
• Spam-Whitelisten werden zuverlässiger und einfacher pflegbar, da der Header-From signiert ist und unterwegs nicht gefälscht werden kann.

• Vertraulichkeit
  Die Vertrauensbasis bildet die DKIM-Signatur-Domain, nicht der einzelne Absender. Eine Signatur/Verschlüsselung seitens des Absenders ist für die Vertraulichkeit daher trotzdem notwendig.
• Spam-/Malware-Abwehr
  Spammer können für ihre eigenen Domains DKIM-Records im DNS veröffentlichen.
• Phishing-Abwehr
  Gekaperte Mailboxen können signierte Phishing-Mails versenden.

• Signatur-Domain ungleich Absender
  Die signierende Domain muss nicht mit einer der Domains des Absenders aus dem Header-From oder Envelope-From übereinstimmen, z.B. wenn man die Signierung an einen Mailprovider delegiert.Lösung: keine, wird von DMARC angegangen
• Mailheader dürfen unterwegs legal verändert werden
  Bestimmte fehlende Header (From, Date) sowie Received-Header dürfen von den Mailservern unterwegs hinzugefügt werden.Lösung: Header werden gesondert vom Body signiert, eine Liste der signierten Header wird der Signatur hinzugefügt.
• Mails werden unterwegs inhaltlich geändert
  Mailinglisten ändern gerne den Inhalt der Mails, sie fügen Footer an oder schreiben den From-Header um. Damit einher gehen Umkodierungen, Einfügen oder Entfernen von Leerzeichen, Tabulatoren oder Leerzeilen.Lösung: Der Inhalt wird mittels einer Canonicalization umgeschrieben, die Differenzen in Leerzeichen, Leerzeilen und Tabulatoren ignoriert. Weiterhin werden Mehrfachsignierungen erlaubt, d.h. der verändernde Mailserver darf danach seine eigene Signatur hinzufügen.
• Mehrfachsignierung
  Ein Mailserver (z.B. Mailinglisten) kann eine weitere Signatur hinzufügen, welche der Signaturen ist nun zu beachten? Lösung: Nur eine der Signaturen muss valide sein, die ungültigen werden ignoriert.
• Böswilliges Einfügen zusätzlicher Header (From, To, Subject)
  Angreifer versuchen durch Einfügen verschiedener Versionen derselben Header schlecht programmierte Mailprogramme der Empfänger z.B. dazu zu bringen, falsche Absenderangaben anzuzeigen.Lösung: Liste der signierten Header enthält die zu schützenden Header mehrfach.
• Zertifikatstausch sowie RevocationLösung
  Zusätzlich zur Domain wird ein Selektor eingefügt, der bei den DNS-Abfragen verwendet wird. Damit kann man parallel mehrere DKIM-TXT-Records im DNS verbreiten. Die Revocation wird durch einen Record mit leerem Publickey erreicht.
• Behandlung von signierten versus unsignierten Mails derselben Domain
  Man kann als Absender keine DKIM-Policy festlegen. Z.B. kann man nicht deklarieren, dass ausnahmslos alle Mails signiert werden und somit unsignierte Mails als gefälscht abgewiesen werden dürfen. Lösung: DMARC. Ein früherer Versuch war ADSP, der aber von DMARC ersetzt wurde.

Der Betreiber der Domain, unter deren Namen die Mails signiert werden sollen, muss im DNS DKIM-Records veröffentlichen. Hierbei handelt es sich um TXT-Records in einem bestimmten Format. Hier folgt ein Beispiel für die Domain dfn.de und den Selektor s1:

dig +short txt s1._domainkey.dfn.de

"v=DKIM1; p="
"MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5tjEwjdy5Xynwaub38d3Lk1e8"
"7O2W0qNp69swt85//ZjXNckUDm1dMK8/Aj8DIyASgDDOHjUrBzSx7a/EchjqgN0S"
"+JFs+DPy+FQsGuNZReVaaBgB3OjqJ25R1CZwDoKK2cD3f4RNhYLctuboB14AZSLt"

Es muss zumindest die Version (v=) und der Publickey (p=) enthalten sein, weitere Einträge sind optional.
Weiterhin ist es nicht empfehlenswert, eine DKIM-Keylänge von mehr als 2048 Bit zu wählen, da es sonst zu Übertragungsproblemen im DNS kommen kann.

• Es gibt pro Instanz nur ein RSA-Keypaar.
• Das Keypaar wird von uns erzeugt, Sie bekommen von uns eine Vorlage für ihre DNS-Records. Die Keylänge beträgt aktuell 1024 Bit.
• Die Selektoren sind frei wählbar.
• Das Einfügen einer Signatur in die Mails ist pro Absender-Domain individuell aktivierbar.
• Als Canonicalization wird relaxed/simple eingesetzt (relaxed für Header, simple für Body).
• Die Liste der zu signierenden Header entspricht dem Amavis-Default und kann nicht modifiziert werden.
• Der Signatur-Algorithmus ist stets rsa-sha256.

Es folgt die Liste der Header, die Amavis für die Signatur heranzieht:

# Nach RFC 6376

From Sender Reply-To Subject Date Message-ID To Cc
In-Reply-To References MIME-Version Content-Type Content-Transfer-Encoding
Content-ID Content-Description Resent-Date Resent-From Resent-Sender
Resent-To Resent-Cc Resent-Message-ID List-Id List-Post List-Owner
List-Subscribe List-Unsubscribe List-Help List-Archive

Von diesen werden folgende NICHT signiert, weil Mailinglisten bzw. manche Mailer-Implementierungen diese oft modifizieren:

Sender To Cc Resent-To Resent-Cc

Zusätzlich kommen nach RFC 4021, 3834, RFC 5518 und IANA registry Permanent Message Header Field Names folgende hinzu, Note that we are signing Received despite the advise in RFC 6376:

Received Precedence
Original-Message-ID Message-Context PICS-Label Sensitivity Solicitation
Content-Location Content-Features Content-Disposition Content-Language
Content-Alternative Content-Base Content-MD5 Content-Duration Content-Class
Accept-Language Auto-Submitted Archived-At VBR-Info

Some additional nonstandard header fields:

Organisation User-Agent X-Mailer

Folgende Header werden doppelt eingefügt, d.h. böswilliges Hinzufügen solcher Header durch Angreifer wird erkannt:

From Date Subject Content-Type