E-Mails signieren mit DKIM
Seite 3: Praxis-Einsatz
Praxis
Über ein halbes Jahr ist der DKIM-Standard nun alt, trotzdem haben erst wenige Admins ihren Servern das Verfahren beigebracht. Dabei lässt es sich selbst in ein mit Anti-Spam- und Anti-Virenfiltern bis an die Zähne bewaffnetes Mailsystem integrieren – wenn die Planung stimmt.
Eine DKIM-Signatur in der E-Mail schadet keinem, aber das Verfahren hilft umso besser bei der Spam-Vermeidung, je mehr Domains ihre Mail signiert verschicken. Postmaster, die ihrem Mail-Server das Signieren und Verifizieren ein- und ausgehender E-Mails gemäß RFC 4871 beibringen möchten, sollten zuerst sicherstellen, dass der eigene Mail-Server nicht zum Spam-Versand missbraucht werden kann. Denn wenn er eine untergeschobene Mail mit der Absender-Signatur adeln würde, wäre das fatal für die Reputation. Die Empfänger könnten die Signatur nicht mehr als Kriterium zum Filtern benutzen und sie wäre somit überflüssig. Wenn der Server wasserdicht läuft, folgt die Planung, an welcher Stelle im Mailtransport eine Nachricht bearbeitet werden soll. Nur so bringt DKIM einerseits den etablierten Ablauf nicht durcheinander und andererseits kommen die bestehenden Prozesse DKIM bei seiner Arbeit nicht in die Quere.
Erst nach der Planungsphase generiert der Postmaster die Schlüssel und integriert sie in den SMTP- und den DNS-Dienst. Damit kann das System dann DKIM-Signaturen hinzufügen und es kann auch DKIM-Signaturen in Mails erkennen. Um anhand der so gewonnenen Signatur-Informationen Spam- und Phishing-Mails herauszufiltern, muss der Postmaster zuletzt die Regeln seiner Content-Filter anpassen.
Bitte hier unterschreiben
Ein typischer Mailserver besteht aus mehreren Komponenten für die einzelnen Aspekte des Mailtransports. Ein SMTP-Server – in diesem Artikel wird es Postfix sein – hat die Aufgabe, E-Mails aus dem Internet anzunehmen; eine Mailinglisten-Software wie mailman verteilt Nachrichten an Abonnenten und eine Content Inspection Engine (hier: amavisd-new) regelt die Überprüfung der Nachrichten durch Filter wie SpamAssassin und trennt damit Gut von Böse.
Grundsätzlich kann der annehmende Server schon während der SMTP-Session mit dem Absender die Signatur prüfen, bevor er die Mail annimmt (Position 1 in der Abbildung oben rechts). Oder die Prüfung findet erst im Content-Filter statt, wenn die Mail bereits im System ist (Position 2). Bei der ersten Variante liefert der absendende Server die Mail an den DKIM-tauglichen Server und wartet innerhalb der SMTP-Session auf die Quittung. Der empfangende Server prüft – ganz RFC-konform – die Unterschrift, bevor er antwortet und gibt bei einem Fehlschlag sofort eine Fehlermeldung zurück. Dafür spricht, dass der absendende Server sofort weiß, woran er ist und den Absender informieren kann. Andernfalls geht die Verantwortung für die weitere Beförderung auf den empfangenden Mailserver über und der absendende kann die Nachricht aus seiner Warteschlange entfernen.
Dagegen spricht, dass sich die frühe Prüfung in der Realität eher selten robust implementieren lässt. Denn bis ein gut beschäftigter Server sich entschieden hat, ob er die Nachricht annehmen will, kann der andere schon längst die SMTP-Sitzung abgebrochen haben. Denn erstens muss der Verifizierer sich den passenden öffentlichen Schlüssel per DNS aus den Weiten des Internet besorgen. Zweitens kosten die kryptographischen Berechnungen einiges an CPU-Zeit. Je nach Last auf dem empfangenden Server kann das so lange dauern, dass der Sende-Timeout des absendenden zuschlägt und er die Sitzung beendet. In der Regel versucht er es zwar dann später wieder, aber die Prüfung kann auch dann wieder zu lange dauern und schließlich schickt er die Nachricht unvollbrachter Dinge an den Anwender zurück.
Vor allem, wenn keine gesicherten Erkenntnisse über die Systemressouren und das Lastverhalten des eigenen Mailsystems vorliegen, ist es deshalb besser, die Signatur später zu prüfen. Dazu akzeptiert der Server die Mail und erst die anschließende Filterkette verarbeitet sie, wenn kein ungeduldiger Absender-Server mehr zu bedienen ist. Allerdings muss der Server eine Nachricht, die er einmal angenommen hat, auch dem Anwender zustellen. Wie weit der Postmaster beim späten Filtern noch gehen darf, ohne sich juristischen Ärger einzuhandeln, behandelt der Kasten auf Seite 123 im kostenpflichtigen Artikel Spam-Golem.
