Fallstricke mit OpenDMARC und Postfix

Abstract

Durch ein Posting auf der deutschen Postfix-Liste wurde ich darauf aufmerksam, wie nachlässig ich mich bisher mit DMARC und OPENDMARC beschäftigt habe.

Dieser Blog-Post ist mehr ein Status-Quo-Bericht als eine vollständige Anleitung, DMARC auf Serverseite in Postfix zu konfigurieren. Das liegt vor allem daran, dass das Thema DMARC bisher wenig etabliert ist und die beteiligte Software Fehler aufweist bzw. nicht passend aufeinander abgestimmt ist.

Ich selbst bin durch einen Post von Jochen Fahrner auf der deutschen Postfix-Liste auf DMARC aufmerksam geworden, und mir wurde klar, wie nachlässig ich mich bisher mit DMARC und OpenDMARC beschäftigt hatte.

Zunächst musste ich einige Unklarheiten mit den DMARC-RFCs klären, weil sie aus meiner Sicht etwas widersprüchlich formuliert waren. Die Widersprüche bezogen sich auf eine DMARC-Policy, die als Default reject gesetzt hatte. Diverse Webserver der Maildomain, um die es in dem Thread ging, sendeten ohne einen DKIM-Key.

Wie sich herausstellte, war das auch vollkommen in Ordnung so, denn diese Webserver waren in der SPF-Policy dieser Maildomain enthalten. Gelten also weitgehend die Default-DMARC-Werte, ist ein fehlender DKIM-Key kein Grund für einen Reject, solange SPF eingehalten wird. Nachdem wir dies geklärt hatten, testete Jochen Fahrner den OpenDMARC-Milter intensiver.

Er entdeckte einen Bug und förderte einige Überraschungen zu Tage. Ich fasse diese hier kurz zusammen und verweise auf seine und andere Mails, weil diese Infos zumindest bis jetzt nur verstreut im Internet zu finden sind.

Um ordnungsgemäß zu funktionieren, benötigt der OpenDMARC-Milter zwei weitere vorgeschaltete Milter – einen für DKIM- und einen für SPF-Valdierung. Andreas Schulze empfiehlt hierfür einen gepatchten SPF-Milter und OpenDKIM. Diese Hilfsmilter sollen nur valdieren, sie dürfen selbst nicht rejecten. Ein eher unübliches Setup.

Den vorgeschalteten SPF-Milter kann man sich dann sparen, wenn OpenDMARC mit libspf2 kompiliert wurde. In diesem Fall muss OpenDMARC mit den Optionen SPFSelfValidate true und evtl. SPFIgnoreResults true betrieben werden. Oder wie Christian Rößner anmerkte: „SPF in den OPENDKIM Milter integrieren“.

Grundsätzlich sollte man wohl den OpenDMARC-Milter im SUBMISSION-Setup (Port 587) von Postfix ausschließen, beziehungsweise die Option IgnoreAuthenticatedClients true (leider gibt es auch da derzeit einen Bug) setzen, zwingend ist außerdem die Option AddAllSignatureResults true.

Verwendet man einen vorgeschalteten SPF-Milter, muss dieser gepatcht werden, da es derzeit noch ein Problem in Postfix gibt, das aus Sendmail-Kompatibilitäten herrührt. Wietse Venema wird dieses demnächst beheben. Es existieren aber noch andere Workarounds, um mit diesem Problem umzugehen.

Hier nun ein paar Links zum Thema:

Leider ist mir bis jetzt noch keine Zeit geblieben, OpenDMARC selbst ausgiebig zu testen. Trotzdem bin ich jetzt etwas schlauer.

UPDATE

Ein paar Probleme sollten zumindest in Postfix jetzt behoben sein, siehe:

http://www.postfix.org/announcements/postfix-2.11.2.html

Bugfixes for Postfix 2.11, 2.10, 2.9 and 2.8:

  • Fix for DMARC implementations based on SPF policy plus DKIM Milter. The PREPEND access/policy action added headers ABOVE Postfix's own Received: header, exposing Postfix's own Received: header to Milters (protocol violation) and hiding the PREPENDed header from Milters. PREPENDed headers are now added BELOW Postfix's own Received: header and remain visible to Milters.

UPDATE 2

Das Thema scheint noch nicht ausgestanden zu sein:

http://archives.neohapsis.com/archives/postfix/2014-10/0386.html

To avoid this difference with Sendmail, Postfix would have to implement the same behavior as Sendmail: ignore the MTA's own received header when reporting headers to Milters, but don't ignore the MTA's own received header when receiving Milter requests with a header index. That is, ignore the header based on its name, not on its position.

If we do that, then we can also roll back this week's patch that placed access/policy PREPENDed headers after the MTA's own received header.

UPDATE 3

Es gibt einen neuen Patch dazu:

http://www.postfix.org/announcements/postfix-2.11.3.html

THIS IS NOT A DUPLICATE OF PATCHES THAT WERE RELEASED ON OCTOBER 13, 2014. THE HEADER PREPEND PATCH IN THAT SET IS REVERTED AND REPLACED WITH A COMPLETE SOLUTION.

Bugfix for Postfix 2.11, 2.10, 2.9 and 2.8:

  • Fix for configurations that prepend message headers with Postfix access maps, policy servers or Milter applications. Postfix now hides its own Received: header from Milters and exposes prepended headers to Milters, regardless of the mechanism used to prepend a header. This fix reverts a partial solution that was released on October 13, 2014, and replaces it with a complete solution.
Robert Schetterer, 20. September 2014