* n3rdfr0mh3ll via postfix-users n3rd@sec-mail.guru:
Hello,
Am 21.05.2014 22:44, schrieb Patrick Ben Koetter via postfix-users:
Ich würde generell danach streben, alles mit einer DKIM-Signatur zu
versehen
wenn es von meiner Domain raus zu remote recipients geht
Wow, das überrascht mich doch ein wenig.
Weshalb? Was daran überrascht Dich?
- unabhängig davon
welches Medium die E-Mail generiert, verändert oder in Umlauf bringt.
Ohne jetzt das genaue Verhalten von DMARC zu kennen, würde mich nun schon interessieren, was so ein dmarc-policy-daemon nun macht, wenn ein Mailserver eine Nachricht soweit manipuliert, dass eine DKIM-Signatur gebrochen wurde, und er diese erneut signiert. Was macht dann ein empfangenes DMARC-prüfendes System?
Es prüft zuerst über DNS ob eine DMARC-Policy in der Senderdomain existiert. Ist sie gegeben, prüft es ob die Nachricht noch in Übereinstimmung (alignment) mit den Vorgaben für DKIM und SPF sind. Ist das nicht der Fall, folgt des den Vorgaben der, in der Senderdomain veröffentlichten, DMARC-Policy.
Die kann - und das wird aktuell sehr strittig und auch ohne Bandagen diskutiert - besagen: "Wenn eine Mail nicht mehr in alignment ist, dann rejecte die Nachricht." Das resultiert in einem Bounce und der kann auf Mailinglisten zum unsubsribe des Senders führen, obwohl der gar nichts dafür kann, dass der MLM die DKIM Sig geshreddert hat.
Eine DMARC-Policy muss nicht immer einen reject einfordern. Sie kann auch 'none' und 'quarantine' bestimmen - 'none' ist dann gut wenn Du wissen willst, ob Du Probleme hast, derer Du ggf. mit DMARC Herr werden könntest.
Dazu setzt Du dann eine Feedback-Adresse und an die werden dann reports und ggf. forensic-reports (mehr verbose) gesendet.
Das grundsätzliche Ziel von DMARC ist, Phishing im Namen Deiner Senderdomain zu unterbinden. Du veröffentlichst die Policy (z.B. rejecten und feedback) und die anderen kicken das raus, was von Deiner Domain vorzugeben scheint, aber nicht die Routing-Ansagen von SPF einhält oder verifizierbare DKIM-Sigs hat.
Der Nutzen von DMARC ist offensichtlich. Wenn es flächendeckend und auch in mailverarbeitenden/-verändernden Instanzen (z.B.: MTA -> Mailingliste -> MTA) eingesetzt werden soll, dann muss die Art der Verarbeitung so verändert werden, dass SPF und DKIM unverändert passieren können.
Auf Mailinglisten bedeutet das z.B. dass der Betreff nicht verändert wird indem der Mailinglisten-Name hinzugfügt wird und auch, dass kein Footer hinzugefügt wird. Beides würde die DKIM-Sig zerstören.
Alternativ kann der MLM die Autorenschaft übernehmen und die Nachricht als Sender "Mailingliste" verbreiten. Dann wird alles auf Null zurückgesetzt und (alte) Regeln für SPF und DKIM gelten nicht mehr - sie können dann auch nicht mehr aus dem 'alignment' fallen und ein DMARC-Filter hat keinen Anlass, die Nachricht zu rejecten.
Hier, auf dieser ML, machen wir beides (weil Ralf und ich auch postmaster für python.org sind und entsprechend nahe an der Entwicklung von mailman sind). Wir verändern weder Subject noch fügen wir einen Footer ein und wir modifizieren den From:-Header (lies: übernehmen die Autorenschaft).
Für viele bedeutet das, sie müssen durch diese Veränderungen von für sie nützlichen und liebgewonnenen Gewohnheiten Abschied nehmen und ich kenne einige, die das zutiefst ablehnen und dabei auch richtig wütend werden.
Ich selbst habe noch keine abschliessende Meinung. Ich sehe, DMARC ist effektiv. Ich verstehe, dazu muss sich auch was in der Mailverarbeitung ändern. Mein Verständnis dafür hält sich in Grenzen.
Wenn es denn sein muss, dann werde ich das Verändern mitragen, aber wenn eine besser Idee auftaucht, dann heule ich den erzwungenen Veränderungen auch nicht nach und mache sie lieber heute als morgen rückgängig.
Ein wenig wie Greylisting. Da bin ich auch tierische dankbar, dass es postscreen gibt, der mir Greylisting ersetzen geholfen hat. :)
p@rick