[postfix-users] OpenDMARC und dhl.com
Mal ein Zwischenergebnis:
IMHO ist OpenDMARC Schrott!
DHL.com hat eine Dmarc-Policy mit p=reject, besitzt SPF aber sendet teilweise ohne DKIM-Signatur. Google Mail verkraftet das, nicht jedoch OpenDMARC. Trotz Compilierung mit "--with-spf" und Konfig "SPFIgnoreResults true" und "SPFSelfValidate true" scheitert OpenDMARC.
Man kann natürlich dhl.com auf die Ignore-Liste setzen, aber das ist ja wohl nicht Sinn und Zweck der Übung.
Jetzt kann man natürlich auf dhl.com schimpfen, weil die keine DKIM-Signatur senden (würde ich ja gerne), aber wenn es Google akzeptiert sollte das bei OpenDMARC nicht anders ein.
* Joachim Fahrner jf@fahrner.name:
Mal ein Zwischenergebnis:
IMHO ist OpenDMARC Schrott!
DHL.com hat eine Dmarc-Policy mit p=reject, besitzt SPF aber sendet teilweise ohne DKIM-Signatur. Google Mail verkraftet das, nicht jedoch OpenDMARC. Trotz Compilierung mit "--with-spf" und Konfig "SPFIgnoreResults true" und "SPFSelfValidate true" scheitert OpenDMARC.
Man kann natürlich dhl.com auf die Ignore-Liste setzen, aber das ist ja wohl nicht Sinn und Zweck der Übung.
Jetzt kann man natürlich auf dhl.com schimpfen, weil die keine DKIM-Signatur senden (würde ich ja gerne), aber wenn es Google akzeptiert sollte das bei OpenDMARC nicht anders ein.
Sehe ich nicht so. DMARC setzt vorraus, dass SPF und DKIM gesetzt und korrekt sind. Die Senderdomain spezifiziert was passieren soll, wenn das nicht eingehalten wird. Die Policy der DHL ist reject. OpenDMARC setzt diese policy um. Das Problem sind die Fehler auf der Senderseite und nicht der Filter, der sie Policy der Senderdomain umsetzt.
p@rick
Am Dienstag, den 16.09.2014, 22:00 +0200 schrieb Patrick Ben Koetter:
Sehe ich nicht so. DMARC setzt vorraus, dass SPF und DKIM gesetzt und korrekt sind.
Und genau das scheint das Problem zu sein. Keiner kann einem sagen was jetzt Sache ist. Die einen sagen "SPF *und* DKIM" müssen erfolgreich sein, die anderen sagen "SPF *oder* DKIM". Es gibt keinerlei Doku was jetzt richtig ist. Auch die RFC sagt darüber nichts aus!
Und so ist das Müll. Fakt ist: Google nimmt die Mails an, mein OpenDMARC lehnt sie ab. Was "juckt" DHL nun mehr, Google, oder mein kleiner Mailserver? Ich hab da keine Chance solange die "Großen" damit anders umgehen. Und somit ist OpenDMARC für mich unbrauchbar.
Am 16.09.2014 um 22:10 schrieb Joachim Fahrner:
Am Dienstag, den 16.09.2014, 22:00 +0200 schrieb Patrick Ben Koetter:
Sehe ich nicht so. DMARC setzt vorraus, dass SPF und DKIM gesetzt und korrekt sind.
Und genau das scheint das Problem zu sein. Keiner kann einem sagen was jetzt Sache ist. Die einen sagen "SPF *und* DKIM" müssen erfolgreich sein, die anderen sagen "SPF *oder* DKIM". Es gibt keinerlei Doku was jetzt richtig ist. Auch die RFC sagt darüber nichts aus!
Na na, ich habe dir eine Erklaerung aus der doku gegeben, ich bin/war mir nur nicht sicher ob die stimmt
Und so ist das Müll. Fakt ist: Google nimmt die Mails an, mein OpenDMARC lehnt sie ab. Was "juckt" DHL nun mehr, Google, oder mein kleiner Mailserver? Ich hab da keine Chance solange die "Großen" damit anders umgehen. Und somit ist OpenDMARC für mich unbrauchbar.
Das ist voellig normal ich hab x Ausnahmen fuer x domains bei x dingen wir leben nicht in einer idealen Welt , wo jeder alles richtig macht
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
On Tue, Sep 16, 2014 at 22:00:51 +0200, Patrick Ben Koetter wrote:
- Joachim Fahrner jf@fahrner.name:
DHL.com hat eine Dmarc-Policy mit p=reject, besitzt SPF aber sendet teilweise ohne DKIM-Signatur. Google Mail verkraftet das, nicht jedoch OpenDMARC. Trotz Compilierung mit "--with-spf" und Konfig "SPFIgnoreResults true" und "SPFSelfValidate true" scheitert OpenDMARC.
Man kann natürlich dhl.com auf die Ignore-Liste setzen, aber das ist ja wohl nicht Sinn und Zweck der Übung.
Jetzt kann man natürlich auf dhl.com schimpfen, weil die keine DKIM-Signatur senden (würde ich ja gerne), aber wenn es Google akzeptiert sollte das bei OpenDMARC nicht anders ein.
Sehe ich nicht so. DMARC setzt vorraus, dass SPF und DKIM gesetzt und korrekt sind. Die Senderdomain spezifiziert was passieren soll, wenn das nicht eingehalten wird. Die Policy der DHL ist reject. OpenDMARC setzt diese policy um. Das Problem sind die Fehler auf der Senderseite und nicht der Filter, der sie Policy der Senderdomain umsetzt.
Soviel ich weiss, stimmt das nicht. Dass sowohl SPF als auch DKIM ueberprueft werden, ist als Rubustheit-Massnahme gedacht, um moeglichst alle use-cases abzudecken und den Betrieb zu vereinfachen. Grundsaetzlich wuerde Ja sonst DKIM ausreichen...
DMARC sagt, dass SPF *oder* DKIM reichen. Siehe auch hier: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
4. Policy: ... A Mail Receiver MUST consider an arriving message to pass the DMARC test if and only if one or more of the underlying message authentication mechanisms pass with proper identifier alignment.
Warum es in OpenDKIM nicht funktioniert, weiss ich auch nicht. Vielleicht funktioniert es besser mit "SPFIgnoreResults false" und einen anderen SPF query daemon?
Gruss David
Am 17.09.2014 um 01:23 schrieb David Schweikert:
On Tue, Sep 16, 2014 at 22:00:51 +0200, Patrick Ben Koetter wrote:
- Joachim Fahrner jf@fahrner.name:
DHL.com hat eine Dmarc-Policy mit p=reject, besitzt SPF aber sendet teilweise ohne DKIM-Signatur. Google Mail verkraftet das, nicht jedoch OpenDMARC. Trotz Compilierung mit "--with-spf" und Konfig "SPFIgnoreResults true" und "SPFSelfValidate true" scheitert OpenDMARC.
Man kann natürlich dhl.com auf die Ignore-Liste setzen, aber das ist ja wohl nicht Sinn und Zweck der Übung.
Jetzt kann man natürlich auf dhl.com schimpfen, weil die keine DKIM-Signatur senden (würde ich ja gerne), aber wenn es Google akzeptiert sollte das bei OpenDMARC nicht anders ein.
Sehe ich nicht so. DMARC setzt vorraus, dass SPF und DKIM gesetzt und korrekt sind. Die Senderdomain spezifiziert was passieren soll, wenn das nicht eingehalten wird. Die Policy der DHL ist reject. OpenDMARC setzt diese policy um. Das Problem sind die Fehler auf der Senderseite und nicht der Filter, der sie Policy der Senderdomain umsetzt.
Soviel ich weiss, stimmt das nicht. Dass sowohl SPF als auch DKIM ueberprueft werden, ist als Rubustheit-Massnahme gedacht, um moeglichst alle use-cases abzudecken und den Betrieb zu vereinfachen. Grundsaetzlich wuerde Ja sonst DKIM ausreichen...
DMARC sagt, dass SPF *oder* DKIM reichen. Siehe auch hier: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
- Policy:
... A Mail Receiver MUST consider an arriving message to pass the DMARC test if and only if one or more of the underlying message authentication mechanisms pass with proper identifier alignment.
ich wuerde das anders verstehen, weil gar kein DKIM Key existiert, das ist ungleich zu der TEST zu einem existierenden KEY scheitert ich sehe schon ich werde die rfc heute nochmal durchlesen *g
Warum es in OpenDKIM nicht funktioniert, weiss ich auch nicht. Vielleicht funktioniert es besser mit "SPFIgnoreResults false" und einen anderen SPF query daemon?
Gruss David _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
Am 17.09.2014 um 07:19 schrieb Robert Schetterer:
Am 17.09.2014 um 01:23 schrieb David Schweikert:
On Tue, Sep 16, 2014 at 22:00:51 +0200, Patrick Ben Koetter wrote:
- Joachim Fahrner jf@fahrner.name:
DHL.com hat eine Dmarc-Policy mit p=reject, besitzt SPF aber sendet teilweise ohne DKIM-Signatur. Google Mail verkraftet das, nicht jedoch OpenDMARC. Trotz Compilierung mit "--with-spf" und Konfig "SPFIgnoreResults true" und "SPFSelfValidate true" scheitert OpenDMARC.
Man kann natürlich dhl.com auf die Ignore-Liste setzen, aber das ist ja wohl nicht Sinn und Zweck der Übung.
Jetzt kann man natürlich auf dhl.com schimpfen, weil die keine DKIM-Signatur senden (würde ich ja gerne), aber wenn es Google akzeptiert sollte das bei OpenDMARC nicht anders ein.
Sehe ich nicht so. DMARC setzt vorraus, dass SPF und DKIM gesetzt und korrekt sind. Die Senderdomain spezifiziert was passieren soll, wenn das nicht eingehalten wird. Die Policy der DHL ist reject. OpenDMARC setzt diese policy um. Das Problem sind die Fehler auf der Senderseite und nicht der Filter, der sie Policy der Senderdomain umsetzt.
Soviel ich weiss, stimmt das nicht. Dass sowohl SPF als auch DKIM ueberprueft werden, ist als Rubustheit-Massnahme gedacht, um moeglichst alle use-cases abzudecken und den Betrieb zu vereinfachen. Grundsaetzlich wuerde Ja sonst DKIM ausreichen...
DMARC sagt, dass SPF *oder* DKIM reichen. Siehe auch hier: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
- Policy:
... A Mail Receiver MUST consider an arriving message to pass the DMARC test if and only if one or more of the underlying message authentication mechanisms pass with proper identifier alignment.
ich wuerde das anders verstehen, weil gar kein DKIM Key existiert, das ist ungleich zu der TEST zu einem existierenden KEY scheitert ich sehe schon ich werde die rfc heute nochmal durchlesen *g
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
der Text meint wohl wenn mind "eine" gueltige DKIM signatur dabei ist lass es durch
failure and nonexistence of authentication mechanisms are equivalent.
wenns DKIM nicht gibt = Fehler => je nach policy bei dhl.com reject
reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. See Section 15.4 for some discussion of SMTP rejection methods and their implications.
ich wuerde sagen der dmarc-milter macht das schon richtig
die policy ist Mist , wenn es systeme gibt die ohne DKIM key senden
Warum es in OpenDKIM nicht funktioniert, weiss ich auch nicht. Vielleicht funktioniert es besser mit "SPFIgnoreResults false" und einen anderen SPF query daemon?
Gruss David _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
Best Regards MfG Robert Schetterer
Am 16.09.2014 um 20:47 schrieb Joachim Fahrner:
Mal ein Zwischenergebnis:
IMHO ist OpenDMARC Schrott!
DHL.com hat eine Dmarc-Policy mit p=reject, besitzt SPF aber sendet teilweise ohne DKIM-Signatur. Google Mail verkraftet das, nicht jedoch OpenDMARC. Trotz Compilierung mit "--with-spf" und Konfig "SPFIgnoreResults true" und "SPFSelfValidate true" scheitert OpenDMARC.
Man kann natürlich dhl.com auf die Ignore-Liste setzen, aber das ist ja wohl nicht Sinn und Zweck der Übung.
Jetzt kann man natürlich auf dhl.com schimpfen, weil die keine DKIM-Signatur senden (würde ich ja gerne), aber wenn es Google akzeptiert sollte das bei OpenDMARC nicht anders ein.
was macht dich glauben das goggle eine referenz darstellt ? mich wuerde eher interesieren warum genau der dmarc-milter scheitert
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
Am 17.09.2014 07:12, schrieb Robert Schetterer:
mich wuerde eher interesieren warum genau der dmarc-milter scheitert
Das würde mich auch interessieren. Kann man dem irgendwie mehr Informationen entlocken? Gibts irgendeine Beschreibung was die kryptischen Angaben im HistoryFile bedeuten?
Am 17.09.2014 um 07:15 schrieb Jochen Fahrner:
Am 17.09.2014 07:12, schrieb Robert Schetterer:
mich wuerde eher interesieren warum genau der dmarc-milter scheitert
Das würde mich auch interessieren. Kann man dem irgendwie mehr Informationen entlocken? Gibts irgendeine Beschreibung was die kryptischen Angaben im HistoryFile bedeuten?
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
http://www.trusteddomain.org/opendmarc/opendmarc.conf.5.html
MilterDebug (integer) ?
wir finden das schon raus *g
Best Regards MfG Robert Schetterer
Am 17.09.2014 07:22, schrieb Robert Schetterer:
MilterDebug (integer) ? wir finden das schon raus *g Best Regards MfG Robert Schetterer
Also, mit Debug Level 9 sieht das so aus:
Sep 17 07:23:48 s2 opendmarc[6931]: OpenDMARC Filter: mi_stop=1 Sep 17 07:23:48 s2 opendmarc[6931]: OpenDMARC Filter v1.3.0 terminating with status 0, errno = 0 Sep 17 07:23:48 s2 opendmarc[14615]: OpenDMARC Filter v1.3.0 starting (args: -c /etc/opendmarc.conf -u opendmarc -P /var/run/opendmarc/opendmarc.pid -p inet:8893@localhost) Sep 17 07:23:48 s2 opendmarc[14615]: trusted authentication services: s2.fahrner.name Sep 17 07:23:48 s2 opendmarc[14615]: OpenDMARC Filter: Opening listen socket on conn inet:8893@localhost Sep 17 07:25:54 s2 postfix/postscreen[14681]: CONNECT from [149.239.48.15]:51845 to [78.46.184.248]:25 Sep 17 07:25:54 s2 postfix/postscreen[14681]: PASS OLD [149.239.48.15]:51845 Sep 17 07:25:55 s2 postfix/smtpd[14690]: connect from ppf01015.deutschepost.de[149.239.48.15] Sep 17 07:25:56 s2 policyd-spf[14699]: None; identity=helo; client-ip=149.239.48.15; helo=ppf01015.deutschepost.de; envelope-from=trackandtrace@dhl.com; receiver=jf@fahrner.name Sep 17 07:25:57 s2 policyd-spf[14699]: Pass; identity=mailfrom; client-ip=149.239.48.15; helo=ppf01015.deutschepost.de; envelope-from=trackandtrace@dhl.com; receiver=jf@fahrner.name Sep 17 07:25:57 s2 postfix/smtpd[14690]: 93460341B5: client=ppf01015.deutschepost.de[149.239.48.15] Sep 17 07:25:57 s2 postfix/cleanup[14701]: 93460341B5: message-id=875134885.60663340.1410931553336.JavaMail.dpagmk@PPF01015.deutschepost.de Sep 17 07:25:58 s2 opendmarc[14615]: 93460341B5: dhl.com fail Sep 17 07:25:58 s2 opendkim[6724]: 93460341B5: ppf01015.deutschepost.de [149.239.48.15] not internal Sep 17 07:25:58 s2 opendkim[6724]: 93460341B5: not authenticated Sep 17 07:25:58 s2 postfix/pickup[14662]: 5517834449: uid=118 from=<opendmarc> Sep 17 07:25:58 s2 postfix/cleanup[14705]: 5517834449: message-id=20140917052558.5517834449@s2.fahrner.name
Und im History File: job 93460341B5 reporter s2.fahrner.name received 1410931557 ipaddr 149.239.48.15 from dhl.com mfrom dhl.com spf 0 pdomain dhl.com policy 16 rua mailto:dhl@rua.agari.com pct 100 adkim 114 aspf 114 p 114 sp 110 align_dkim 5 align_spf 5 action 2
Am 17.09.2014 um 07:33 schrieb Jochen Fahrner:
Sep 17 07:25:58 s2 opendkim[6724]: 93460341B5: not authenticated
das stehts wuerde ich sagen, und nach meiner Auffassung ist dann ein reject nach deren policy und rfc voellig ok
Best Regards MfG Robert Schetterer
Am 17.09.2014 07:41, schrieb Robert Schetterer:
das stehts wuerde ich sagen, und nach meiner Auffassung ist dann ein reject nach deren policy und rfc voellig ok
Na ja, die Meldung war vom opendkim, und dass die Signatur fehlt wissen wir ja von Anfang an.
Bei Google sieht die gleiche Mail übrigens so aus (dmarc=pass):
Received: by 10.52.236.228 with SMTP id ux4csp1272414vdc; Tue, 16 Sep 2014 08:57:30 -0700 (PDT) X-Received: by 10.112.160.163 with SMTP id xl3mr17201869lbb.80.1410883049829; Tue, 16 Sep 2014 08:57:29 -0700 (PDT) Return-Path: trackandtrace@dhl.com Received: from PPF01015.deutschepost.de (ppf01015.deutschepost.de. [149.239.48.15]) by mx.google.com with ESMTP id od10si24950873lbc.20.2014.09.16.08.57.29 for ...@gmail.com; Tue, 16 Sep 2014 08:57:29 -0700 (PDT) Received-SPF: pass (google.com: domain of trackandtrace@dhl.com designates 149.239.48.15 as permitted sender) client-ip=149.239.48.15; Authentication-Results: mx.google.com; spf=pass (google.com: domain of trackandtrace@dhl.com designates 149.239.48.15 as permitted sender) smtp.mail=trackandtrace@dhl.com; dmarc=pass (p=REJECT dis=NONE) header.from=dhl.com Received: from localhost (localhost.localdomain [127.0.0.1]) by PPF01015.deutschepost.de (Postfix) with ESMTP id 1E8675229B for ...@gmail.com; Tue, 16 Sep 2014 17:57:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at deutschepost.de Received: from PPF01015.deutschepost.de ([127.0.0.1]) by localhost (PPF01015.deutschepost.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HRRUlzIkrPg for ...@gmail.com; Tue, 16 Sep 2014 17:57:28 +0200 (CEST) Received: from DYN-S19092349 (unknown [160.58.107.18]) by PPF01015.deutschepost.de (Postfix) with ESMTP for ...@gmail.com; Tue, 16 Sep 2014 17:57:28 +0200 (CEST) Date: Tue, 16 Sep 2014 17:57:28 +0200 (CEST) From: trackandtrace@dhl.com To: ...@gmail.com Message-ID: 1325933392.60070139.1410883048989.JavaMail.dpagmk@PPF01015.deutschepost.de References: mkaTechnicalID="219685295" mkaContactReason="OB_SENDUNGSSTATUS_PUBLIC"
Am 17.09.2014 um 07:55 schrieb Jochen Fahrner:
Am 17.09.2014 07:41, schrieb Robert Schetterer:
das stehts wuerde ich sagen, und nach meiner Auffassung ist dann ein reject nach deren policy und rfc voellig ok
Na ja, die Meldung war vom opendkim, und dass die Signatur fehlt wissen wir ja von Anfang an.
ich wuerde sagen das spielt keine Rolle ( ausser es ist ein software bug )
Bei Google sieht die gleiche Mail übrigens so aus (dmarc=pass):
Received: by 10.52.236.228 with SMTP id ux4csp1272414vdc; Tue, 16 Sep 2014 08:57:30 -0700 (PDT) X-Received: by 10.112.160.163 with SMTP id xl3mr17201869lbb.80.1410883049829; Tue, 16 Sep 2014 08:57:29 -0700 (PDT) Return-Path: trackandtrace@dhl.com Received: from PPF01015.deutschepost.de (ppf01015.deutschepost.de. [149.239.48.15]) by mx.google.com with ESMTP id od10si24950873lbc.20.2014.09.16.08.57.29 for ...@gmail.com; Tue, 16 Sep 2014 08:57:29 -0700 (PDT) Received-SPF: pass (google.com: domain of trackandtrace@dhl.com designates 149.239.48.15 as permitted sender) client-ip=149.239.48.15; Authentication-Results: mx.google.com; spf=pass (google.com: domain of trackandtrace@dhl.com designates 149.239.48.15 as permitted sender) smtp.mail=trackandtrace@dhl.com; dmarc=pass (p=REJECT dis=NONE) header.from=dhl.com
http://lists.dmarc.org/pipermail/dmarc-discuss/2013-April/001857.html
Hi Al, dis=none means that Gmail applied "none" policy, even the domain published "reject". There are hundred other reasons the message can be as classified spam. Please mark it as "non-spam" in gmail UI, and we will learn about this false positive. Thank you, Olga
Google hat die also whitegelistet , wahrscheinlich aus dem gleichem Grund
koennen wir das Thema nun abschliessen ?
Received: from localhost (localhost.localdomain [127.0.0.1]) by PPF01015.deutschepost.de (Postfix) with ESMTP id 1E8675229B for ...@gmail.com; Tue, 16 Sep 2014 17:57:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at deutschepost.de Received: from PPF01015.deutschepost.de ([127.0.0.1]) by localhost (PPF01015.deutschepost.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HRRUlzIkrPg for ...@gmail.com; Tue, 16 Sep 2014 17:57:28 +0200 (CEST) Received: from DYN-S19092349 (unknown [160.58.107.18]) by PPF01015.deutschepost.de (Postfix) with ESMTP for ...@gmail.com; Tue, 16 Sep 2014 17:57:28 +0200 (CEST) Date: Tue, 16 Sep 2014 17:57:28 +0200 (CEST) From: trackandtrace@dhl.com To: ...@gmail.com Message-ID: 1325933392.60070139.1410883048989.JavaMail.dpagmk@PPF01015.deutschepost.de References: mkaTechnicalID="219685295" mkaContactReason="OB_SENDUNGSSTATUS_PUBLIC"
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
On Wed, Sep 17, 2014 at 07:41:19 +0200, Robert Schetterer wrote:
Am 17.09.2014 um 07:33 schrieb Jochen Fahrner:
Sep 17 07:25:58 s2 opendkim[6724]: 93460341B5: not authenticated
das stehts wuerde ich sagen, und nach meiner Auffassung ist dann ein reject nach deren policy und rfc voellig ok
Gemaess Spezifikation reicht es, wenn eine Authentifizierung-Mechanismus erfolgreich ist.
Ich finde den DMARC Draft schon klar diesbezueglich, aber sehe auch z.B. Google: https://support.google.com/a/answer/2466580?hl=en
"A message must fail both SPF and DKIM checks to also fail DMARC."
Was ich komisch finde: warum policyd-spf verwenden, und auch SPFIgnoreResults=yes setzen?
Gruss David
Am 17.09.2014 08:00, schrieb David Schweikert:
Was ich komisch finde: warum policyd-spf verwenden, und auch SPFIgnoreResults=yes setzen?
Weil der Verdacht besteht dass OpenDMARC den Header nicht korrekt auswertet oder Postfix den nicht übergibt (aus der opedmarc Mailingliste). Deswegen soll OpenDMARC das SPF selber machen:
## SPFSelfValidate { true | false } ## default false ## ## Enable internal spf checking with --with-spf ## To use libspf2 instead: --with-spf --with-spf2-include=path --with-spf2-lib=path ## ## Causes the filter to perform a fallback SPF check itself when ## it can find no SPF results in the message header. If SPFIgnoreResults ## is also set, it never looks for SPF results in headers and ## always performs the SPF check itself when this is set. # SPFSelfValidate true
Und ja, opendmarc ist mit SPF-Support compiliert:
opendmarc: OpenDMARC Filter v1.3.0 SMFI_VERSION 0x1000001 Active code options: WITH_SPF
Am 17.09.2014 um 08:00 schrieb David Schweikert:
On Wed, Sep 17, 2014 at 07:41:19 +0200, Robert Schetterer wrote:
Am 17.09.2014 um 07:33 schrieb Jochen Fahrner:
Sep 17 07:25:58 s2 opendkim[6724]: 93460341B5: not authenticated
das stehts wuerde ich sagen, und nach meiner Auffassung ist dann ein reject nach deren policy und rfc voellig ok
Gemaess Spezifikation reicht es, wenn eine Authentifizierung-Mechanismus
eben nicht bei dieser dhl.com dmarc policy, es reicht wenn "ein" gueltiger DKIM KEY enthalten ( soll robust gegen forwarding machen ), wenn "kein" DKIM KEY enthalten ist , ist das gleichbedeutend mit failure daraus folgt bei dieser policy ein reject zu 100 %
erfolgreich ist.
Ich finde den DMARC Draft schon klar diesbezueglich, aber sehe auch z.B. Google: https://support.google.com/a/answer/2466580?hl=en
"A message must fail both SPF and DKIM checks to also fail DMARC."
Was ich komisch finde: warum policyd-spf verwenden, und auch SPFIgnoreResults=yes setzen?
google hat die domain whitegelistet, und es ist auch letztendlich auch voellig egal was google oder sonst ein Empfaenger tut, jeder ist frei mit mails umzugehen wie er es ihm beliebt, es geht einzig und allein um die Frage ob der Absender sich an seine eigene im dns publizierte DMARC Policy haelt oder nicht.
die dhl.com dmarc policy ist also insofern falsch , wenn sie mails verschicken in denen nicht mind "ein" gueltiger DKIM key enthalten ist
Solange mir jetzt niemand das Gegenteil beweist , ist das mein finaler report zu dem Thema *g
Gruss David _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
Am 17.09.2014 10:01, schrieb Robert Schetterer:
die dhl.com dmarc policy ist also insofern falsch , wenn sie mails verschicken in denen nicht mind "ein" gueltiger DKIM key enthalten ist
Solange mir jetzt niemand das Gegenteil beweist , ist das mein finaler report zu dem Thema *g
Ok, hier kommt der Beweis: ;-)
Wenn man opendmarc mit libspf2 compiliert *und* ihn die SPF-Prüfung selber machen lässt, dann klappt das. Wichtig ist die libspf2, mit der normalen geht es nicht!
Sep 17 10:09:40 s2 postfix/postscreen[29514]: CONNECT from [149.239.48.15]:33929 to [78.46.184.248]:25 Sep 17 10:09:40 s2 postfix/postscreen[29514]: PASS OLD [149.239.48.15]:33929 Sep 17 10:09:40 s2 postfix/smtpd[29515]: connect from ppf01015.deutschepost.de[149.239.48.15] Sep 17 10:09:43 s2 policyd-spf[29525]: None; identity=helo; client-ip=149.239.48.15; helo=ppf01015.deutschepost.de; envelope-from=trackandtrace@dhl.com; receiver=jf@fahrner.name Sep 17 10:09:43 s2 policyd-spf[29525]: Pass; identity=mailfrom; client-ip=149.239.48.15; helo=ppf01015.deutschepost.de; envelope-from=trackandtrace@dhl.com; receiver=jf@fahrner.name Sep 17 10:09:43 s2 postfix/smtpd[29515]: 233AA341B5: client=ppf01015.deutschepost.de[149.239.48.15] Sep 17 10:09:43 s2 postfix/cleanup[29527]: 233AA341B5: message-id=960037238.60909839.1410941380549.JavaMail.dpagmk@PPF01015.deutschepost.de Sep 17 10:09:43 s2 opendmarc[29479]: 233AA341B5: dhl.com pass Sep 17 10:09:43 s2 opendkim[6724]: 233AA341B5: ppf01015.deutschepost.de [149.239.48.15] not internal Sep 17 10:09:43 s2 opendkim[6724]: 233AA341B5: not authenticated Sep 17 10:09:43 s2 opendkim[6724]: 233AA341B5: no signature data Sep 17 10:09:43 s2 postfix/qmgr[14661]: 233AA341B5: from=trackandtrace@dhl.com, size=5632, nrcpt=1 (queue active) Sep 17 10:09:43 s2 postfix/smtpd[29515]: disconnect from ppf01015.deutschepost.de[149.239.48.15]
Am 17.09.2014 um 10:17 schrieb Jochen Fahrner:
Am 17.09.2014 10:01, schrieb Robert Schetterer:
die dhl.com dmarc policy ist also insofern falsch , wenn sie mails verschicken in denen nicht mind "ein" gueltiger DKIM key enthalten ist
Solange mir jetzt niemand das Gegenteil beweist , ist das mein finaler report zu dem Thema *g
Ok, hier kommt der Beweis: ;-)
Wenn man opendmarc mit libspf2 compiliert *und* ihn die SPF-Prüfung selber machen lässt, dann klappt das. Wichtig ist die libspf2, mit der normalen geht es nicht!
ok ,und jetzt nochmal mit der aktuellen config deines dmarc milters
Sep 17 10:09:40 s2 postfix/postscreen[29514]: CONNECT from [149.239.48.15]:33929 to [78.46.184.248]:25 Sep 17 10:09:40 s2 postfix/postscreen[29514]: PASS OLD [149.239.48.15]:33929 Sep 17 10:09:40 s2 postfix/smtpd[29515]: connect from ppf01015.deutschepost.de[149.239.48.15] Sep 17 10:09:43 s2 policyd-spf[29525]: None; identity=helo; client-ip=149.239.48.15; helo=ppf01015.deutschepost.de; envelope-from=trackandtrace@dhl.com; receiver=jf@fahrner.name Sep 17 10:09:43 s2 policyd-spf[29525]: Pass; identity=mailfrom; client-ip=149.239.48.15; helo=ppf01015.deutschepost.de; envelope-from=trackandtrace@dhl.com; receiver=jf@fahrner.name Sep 17 10:09:43 s2 postfix/smtpd[29515]: 233AA341B5: client=ppf01015.deutschepost.de[149.239.48.15] Sep 17 10:09:43 s2 postfix/cleanup[29527]: 233AA341B5: message-id=960037238.60909839.1410941380549.JavaMail.dpagmk@PPF01015.deutschepost.de Sep 17 10:09:43 s2 opendmarc[29479]: 233AA341B5: dhl.com pass Sep 17 10:09:43 s2 opendkim[6724]: 233AA341B5: ppf01015.deutschepost.de [149.239.48.15] not internal Sep 17 10:09:43 s2 opendkim[6724]: 233AA341B5: not authenticated Sep 17 10:09:43 s2 opendkim[6724]: 233AA341B5: no signature data Sep 17 10:09:43 s2 postfix/qmgr[14661]: 233AA341B5: from=trackandtrace@dhl.com, size=5632, nrcpt=1 (queue active) Sep 17 10:09:43 s2 postfix/smtpd[29515]: disconnect from ppf01015.deutschepost.de[149.239.48.15]
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Best Regards MfG Robert Schetterer
Am 17.09.2014 10:23, schrieb Robert Schetterer:
ok ,und jetzt nochmal mit der aktuellen config deines dmarc milters
??? Was meinst du damit? Das war doch mit der aktuellen config.
Am 17.09.2014 um 10:26 schrieb Jochen Fahrner:
Am 17.09.2014 10:23, schrieb Robert Schetterer:
ok ,und jetzt nochmal mit der aktuellen config deines dmarc milters
??? Was meinst du damit? Das war doch mit der aktuellen config.
ja genau und die will ich sehen *g genauer , alle parameter die nicht im default stehen, weil das log nur beweisst dass die mail den milter erfolgreich durchlaufen hat , das koennte auch einfach ein "besonderen" Einstellungen liegen, je nachdem hast du dann eben einen Weg gefunden mit "dieser dmarc policy" umzugehen ( was ja auch voellig ok ist ), ein Beweis dass es OK ist mit dieser dmarc policy mails ohne DKIM key zu versenden hast du aber dann aber noch nicht erbracht.
Best Regards MfG Robert Schetterer
Am 17.09.2014 10:34, schrieb Robert Schetterer:
ja genau und die will ich sehen *g
Bitte sehr:
AuthservID s2.fahrner.name IgnoreAuthenticatedClients true PidFile /var/run/opendmarc.pid RejectFailures true SoftwareHeader false SPFIgnoreResults true SPFSelfValidate true Syslog true UMask 0002 UserID opendmarc CopyFailuresTo postmaster@fahrner.name FailureReports true FailureReportsBcc postmaster@fahrner.name FailureReportsSentBy postmaster@fahrner.name HistoryFile /var/run/opendmarc/opendmarc.dat
Und hier noch die Header einer aktuellen (finalen) Testmail:
Return-Path: trackandtrace@dhl.com Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=149.239.48.15; helo=ppf01015.deutschepost.de; envelope-from=trackandtrace@dhl.com; receiver=jf@fahrner.name Received: from PPF01015.deutschepost.de (ppf01015.deutschepost.de [149.239.48.15]) by s2.fahrner.name (Postfix) with ESMTP id B0917341B5 for jf@fahrner.name; Wed, 17 Sep 2014 10:33:32 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by PPF01015.deutschepost.de (Postfix) with ESMTP id 4849051148 for jf@fahrner.name; Wed, 17 Sep 2014 10:33:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at deutschepost.de Received: from PPF01015.deutschepost.de ([127.0.0.1]) by localhost (PPF01015.deutschepost.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1ndV2hTBKMm for jf@fahrner.name; Wed, 17 Sep 2014 10:33:32 +0200 (CEST) Received: from DYN-S19092370 (unknown [160.58.107.19]) by PPF01015.deutschepost.de (Postfix) with ESMTP for jf@fahrner.name; Wed, 17 Sep 2014 10:33:32 +0200 (CEST) Date: Wed, 17 Sep 2014 10:33:32 +0200 (CEST) From: trackandtrace@dhl.com To: jf@fahrner.name Message-ID: 1704872964.60721586.1410942812149.JavaMail.dpagmk@PPF01015.deutschepost.de References: mkaTechnicalID="220194065" mkaContactReason="OB_SENDUNGSSTATUS_PUBLIC" Subject: Aktueller Status der Sendung Finaler Ofen mit der Sendungsnummer MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit contentType: text/html; charset=UTF-8 Authentication-Results: s2.fahrner.name; spf=pass smtp.mailfrom=trackandtrace@dhl.com Authentication-Results: s2.fahrner.name; dmarc=pass header.from=dhl.com
Am 17.09.2014 08:00, schrieb David Schweikert:
Gemaess Spezifikation reicht es, wenn eine Authentifizierung-Mechanismus erfolgreich ist.
Ich finde den DMARC Draft schon klar diesbezueglich, aber sehe auch z.B. Google: https://support.google.com/a/answer/2466580?hl=en
"A message must fail both SPF and DKIM checks to also fail DMARC."
Ich würde sagen, halten wir fest:
Die RFC ist "interpreationsfähig". Google beschreibt es klarer. Postfix und/oder OpenDMARC haben ein Problem mit dem normalen policyd-spf, OpenDMARC *muss* den SPF-Check selber machen, und das klappt auch nur korrekt mit der libspf2.
Falls Robert immer noch Zweifel hat, hier ein Auszug aus dem Sourcecode von OpenDMARC (opendmarc_policy.c):
/* * If dkim passes and dkim aligns OR spf passes and spf aligns * Accept the message. */ if (pctx->spf_alignment == DMARC_POLICY_SPF_ALIGNMENT_PASS || pctx->dkim_alignment == DMARC_POLICY_DKIM_ALIGNMENT_PASS) return DMARC_POLICY_PASS;
Am 17.09.2014 um 10:46 schrieb Jochen Fahrner:
Am 17.09.2014 08:00, schrieb David Schweikert:
Gemaess Spezifikation reicht es, wenn eine Authentifizierung-Mechanismus erfolgreich ist.
Ich finde den DMARC Draft schon klar diesbezueglich, aber sehe auch z.B. Google: https://support.google.com/a/answer/2466580?hl=en
"A message must fail both SPF and DKIM checks to also fail DMARC."
Ich würde sagen, halten wir fest:
Die RFC ist "interpreationsfähig".
jep da hast du absolut recht, ich hab den Author jetzt angeschrieben wenn man die Reihenfolge in der RFC beruecksichtigt muesste der milter es durchlassen wenn mind ein check ok ist, das widerspricht sich aber dann etwas im weiteren Text, aber vieleicht reichts da dann auch einfach nimmer mit meinem English *g
Google beschreibt es klarer.
Postfix und/oder OpenDMARC haben ein Problem mit dem normalen policyd-spf,
OpenDMARC *muss* den SPF-Check selber machen, und das
also anfaenglich habe ich das mal so vorausgesetzt, aber gut zu wissen
klappt auch nur korrekt mit der libspf2.
Falls Robert immer noch Zweifel hat, hier ein Auszug aus dem Sourcecode von OpenDMARC (opendmarc_policy.c):
/* * If dkim passes and dkim aligns OR spf passes and spf aligns * Accept the message. */ if (pctx->spf_alignment == DMARC_POLICY_SPF_ALIGNMENT_PASS || pctx->dkim_alignment == DMARC_POLICY_DKIM_ALIGNMENT_PASS) return DMARC_POLICY_PASS;
ich hab in deiner config jetzt nicht weiteres gesehen, wenn jetzt nicht irgendein Bug drinn ist , hab ich mich vertan, und du hast "den Fehler" gefunden. Mal sehen evtl kriegen wir das vom DMARC RFC Author verifiziert, wir finden das schon raus *g
Best Regards MfG Robert Schetterer
Lustig: jetzt geht zwar DHL, dafür werden jetzt DMARC-Reports von Google abgewiesen. ;-)
Sep 17 11:12:27 s2 postfix/postscreen[29962]: CONNECT from [2607:f8b0:4003:c01::249]:37530 to [2a01:4f8:d13:3016::2]:25 Sep 17 11:12:33 s2 postfix/postscreen[29962]: PASS NEW [2607:f8b0:4003:c01::249]:37530 Sep 17 11:12:35 s2 postfix/smtpd[29971]: connect from mail-ob0-x249.google.com[2607:f8b0:4003:c01::249] Sep 17 11:12:36 s2 postfix/smtpd[29971]: Anonymous TLS connection established from mail-ob0-x249.google.com[2607:f8b0:4003:c01::249]: TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Sep 17 11:12:37 s2 policyd-spf[29978]: None; identity=helo; client-ip=2607:f8b0:4003:c01::249; helo=mail-ob0-x249.google.com; envelope-from=noreply-dmarc-support@google.com; receiver=dmarc@fahrner.name Sep 17 11:12:37 s2 policyd-spf[29978]: Pass; identity=mailfrom; client-ip=2607:f8b0:4003:c01::249; helo=mail-ob0-x249.google.com; envelope-from=noreply-dmarc-support@google.com; receiver=dmarc@fahrner.name Sep 17 11:12:37 s2 postfix/smtpd[29971]: 47544341FA: client=mail-ob0-x249.google.com[2607:f8b0:4003:c01::249] Sep 17 11:12:37 s2 postfix/cleanup[29980]: 47544341FA: message-id=14117120610198414199@google.com Sep 17 11:12:37 s2 opendmarc[29698]: 47544341FA: google.com fail Sep 17 11:12:37 s2 postfix/pickup[29793]: 8C12734449: uid=118 from=<opendmarc> Sep 17 11:12:37 s2 postfix/cleanup[29984]: 8C12734449: message-id=20140917091237.8C12734449@s2.fahrner.name Sep 17 11:12:37 s2 opendkim[6724]: 8C12734449: DKIM-Signature header added (s=mail, d=fahrner.name) Sep 17 11:12:37 s2 postfix/cleanup[29980]: 47544341FA: milter-hold: END-OF-MESSAGE from mail-ob0-x249.google.com[2607:f8b0:4003:c01::249]: milter triggers HOLD action; from=noreply-dmarc-support@google.com to=dmarc@fahrner.name proto=ESMTP helo=<mail-ob0-x249.google.com>
Kann es sein dass SPF ein Problem mit ipv6 Adressen hat?
Am 17.09.2014 11:19, schrieb Jochen Fahrner:
Sep 17 11:12:37 s2 policyd-spf[29978]: Pass; identity=mailfrom; client-ip=2607:f8b0:4003:c01::249; helo=mail-ob0-x249.google.com; envelope-from=noreply-dmarc-support@google.com; receiver=dmarc@fahrner.name Sep 17 11:12:37 s2 postfix/smtpd[29971]: 47544341FA: client=mail-ob0-x249.google.com[2607:f8b0:4003:c01::249] Sep 17 11:12:37 s2 postfix/cleanup[29980]: 47544341FA: message-id=14117120610198414199@google.com Sep 17 11:12:37 s2 opendmarc[29698]: 47544341FA: google.com fail
Kann es sein dass SPF ein Problem mit ipv6 Adressen hat?
Hmmm... an der libspf2 liegts nicht:
spfquery -ip 2607:f8b0:4003:c01::249 -sender 'noreply-dmarc-support@google.com' pass
spfquery: domain of google.com designates 2607:f8b0:4003:c01::249 as permitted sender Received-SPF: pass (spfquery: domain of google.com designates 2607:f8b0:4003:c01::249 as permitted sender) client-ip=2607:f8b0:4003:c01::249; envelope-from=noreply-dmarc-support@google.com;
Am 17.09.2014 11:44, schrieb Jochen Fahrner:
Kann es sein dass SPF ein Problem mit ipv6 Adressen hat?
Hmmm... an der libspf2 liegts nicht:
http://sourceforge.net/p/opendmarc/tickets/95/
Am 17.09.2014 um 11:50 schrieb Jochen Fahrner:
Am 17.09.2014 11:44, schrieb Jochen Fahrner:
Kann es sein dass SPF ein Problem mit ipv6 Adressen hat?
Hmmm... an der libspf2 liegts nicht:
jep hab ich jetzt auch gefunden....
Best Regards MfG Robert Schetterer
Am 17.09.2014 11:50, schrieb Jochen Fahrner:
Ich hab mir den Sourcecode mal angesehen. Die IPv6-Unterstützung fehlt da defintiv. Aus opendmarc_spf.c:
opendmarc_spf2_specify_ip_address(SPF_CTX_T *spfctx, char *ip_address, size_t ip_address_len) { if (spfctx == NULL) return EINVAL;
if (ip_address == NULL) return EINVAL;
/* * we don't care at this point if it is ipv6 or ipv4 */ SPF_request_set_ipv4_str(spfctx->spf_request, ip_address); return 0; }
Ich hab da jetzt mal das SPF_request_set_ipv6_str reingebastelt, wenn es eine v6 Adresse ist. Laut Ticket soll es aber dann noch ein weiteres Problem bei der HELO-Prüfung geben. Fragt sich an welchen Stellen sonst noch ipv6-Unterstützung fehlt. Ich werde weiter beobachten.
Am 17.09.2014 um 12:28 schrieb Jochen Fahrner:
Am 17.09.2014 11:50, schrieb Jochen Fahrner:
Ich hab mir den Sourcecode mal angesehen. Die IPv6-Unterstützung fehlt da defintiv. Aus opendmarc_spf.c:
opendmarc_spf2_specify_ip_address(SPF_CTX_T *spfctx, char *ip_address, size_t ip_address_len) { if (spfctx == NULL) return EINVAL;
if (ip_address == NULL) return EINVAL;
/* * we don't care at this point if it is ipv6 or ipv4 */ SPF_request_set_ipv4_str(spfctx->spf_request, ip_address); return 0; }
Ich hab da jetzt mal das SPF_request_set_ipv6_str reingebastelt, wenn es eine v6 Adresse ist. Laut Ticket soll es aber dann noch ein weiteres Problem bei der HELO-Prüfung geben. Fragt sich an welchen Stellen sonst noch ipv6-Unterstützung fehlt. Ich werde weiter beobachten.
cool, danke !
Best Regards MfG Robert Schetterer
Ich hab jetzt mal den Sourcecode von OpenDMARC etwas studiert. Im Prinzip gibt es 3 Möglichkeiten für den SPF-Check:
1. ein externer Check eines Policy Daemon oder Milter, der sein Ergebnis im Header übergibt. Laut opendmarc Mailingliste scheint so ein Header aber nicht vom Postfix Policy check an den DMARC Milter übergeben zu werden. Jetzt könnte man mal versuchen ob es mit einem SPF-milter klappt. Kennt jemand einen guten SPF-Milter? Am besten einen der libspf2 benutzt, das scheint ausgereift zu sein und lässt sich gut mit spfquery nachvollziehen.
2. interner check mit eigenen SPF-check Funktionen. Die sind offenbar buggy, wie das Beispiel DHL gezeigt hat.
3. interner check mit libspf2. Klappt besser als 2., hat aber noch Probleme mit ipv6. Was OpenDMARC da macht entspricht praktisch dem Coding Beispiel von libspf2 hier: http://www.libspf2.org/docs/html/. Es fehlte lediglich der Aufruf für ipv6 Adressen, den habe ich bei mir eingebaut. Laut Fehlerticket soll es noch ein weiteres Problem mit HELO Namen geben. Das kann aber eigentlich nur auftreten wenn eine Mail-From Adresse fehlt, denn nur dann wird der HELO Name benutzt. Ich hab keine Ahnung wann der Fall eintreten kann.
Ob 2. oder 3. genutzt wird hängt davon ab wie man es compiliert. Ob 1. oder 2./3. genutzt wird hängt von der Config ab (SPFSelfValidate).
Am zuverlässigsten erscheint mir wohl derzeit die Variante 1. mit milter zu sein (falls die Header-Übergabe da klappt). Was ich hier lese hört sich für Debian aber nicht so rosig an: http://tanguy.ortolo.eu/blog/article103/spf-milter
Am 17.09.2014 um 15:40 schrieb Jochen Fahrner:
Ich hab jetzt mal den Sourcecode von OpenDMARC etwas studiert. Im Prinzip gibt es 3 Möglichkeiten für den SPF-Check:
- ein externer Check eines Policy Daemon oder Milter, der sein Ergebnis
im Header übergibt. Laut opendmarc Mailingliste scheint so ein Header aber nicht vom Postfix Policy check an den DMARC Milter übergeben zu werden. Jetzt könnte man mal versuchen ob es mit einem SPF-milter klappt. Kennt jemand einen guten SPF-Milter? Am besten einen der libspf2 benutzt, das scheint ausgereift zu sein und lässt sich gut mit spfquery nachvollziehen.
- interner check mit eigenen SPF-check Funktionen. Die sind offenbar
buggy, wie das Beispiel DHL gezeigt hat.
- interner check mit libspf2. Klappt besser als 2., hat aber noch
Probleme mit ipv6. Was OpenDMARC da macht entspricht praktisch dem Coding Beispiel von libspf2 hier: http://www.libspf2.org/docs/html/. Es fehlte lediglich der Aufruf für ipv6 Adressen, den habe ich bei mir eingebaut. Laut Fehlerticket soll es noch ein weiteres Problem mit HELO Namen geben. Das kann aber eigentlich nur auftreten wenn eine Mail-From Adresse fehlt, denn nur dann wird der HELO Name benutzt. Ich hab keine Ahnung wann der Fall eintreten kann.
irgendwann wird auch diese Variante sicher auftreten *g
Ob 2. oder 3. genutzt wird hängt davon ab wie man es compiliert. Ob 1. oder 2./3. genutzt wird hängt von der Config ab (SPFSelfValidate).
Am zuverlässigsten erscheint mir wohl derzeit die Variante 1. mit milter zu sein (falls die Header-Übergabe da klappt). Was ich hier lese hört sich für Debian aber nicht so rosig an: http://tanguy.ortolo.eu/blog/article103/spf-milter
nicht schoen... evtl das ganze noch etwas "reifen" lassen
Best Regards MfG Robert Schetterer
Am 17.09.2014 um 17:10 schrieb Robert Schetterer:
Am 17.09.2014 um 15:40 schrieb Jochen Fahrner:
Ich hab jetzt mal den Sourcecode von OpenDMARC etwas studiert. Im Prinzip gibt es 3 Möglichkeiten für den SPF-Check:
- ein externer Check eines Policy Daemon oder Milter, der sein Ergebnis
im Header übergibt. Laut opendmarc Mailingliste scheint so ein Header aber nicht vom Postfix Policy check an den DMARC Milter übergeben zu werden. Jetzt könnte man mal versuchen ob es mit einem SPF-milter klappt. Kennt jemand einen guten SPF-Milter? Am besten einen der libspf2 benutzt, das scheint ausgereift zu sein und lässt sich gut mit spfquery nachvollziehen.
- interner check mit eigenen SPF-check Funktionen. Die sind offenbar
buggy, wie das Beispiel DHL gezeigt hat.
- interner check mit libspf2. Klappt besser als 2., hat aber noch
Probleme mit ipv6. Was OpenDMARC da macht entspricht praktisch dem Coding Beispiel von libspf2 hier: http://www.libspf2.org/docs/html/. Es fehlte lediglich der Aufruf für ipv6 Adressen, den habe ich bei mir eingebaut. Laut Fehlerticket soll es noch ein weiteres Problem mit HELO Namen geben. Das kann aber eigentlich nur auftreten wenn eine Mail-From Adresse fehlt, denn nur dann wird der HELO Name benutzt. Ich hab keine Ahnung wann der Fall eintreten kann.
irgendwann wird auch diese Variante sicher auftreten *g
Ob 2. oder 3. genutzt wird hängt davon ab wie man es compiliert. Ob 1. oder 2./3. genutzt wird hängt von der Config ab (SPFSelfValidate).
Am zuverlässigsten erscheint mir wohl derzeit die Variante 1. mit milter zu sein (falls die Header-Übergabe da klappt). Was ich hier lese hört sich für Debian aber nicht so rosig an: http://tanguy.ortolo.eu/blog/article103/spf-milter
nicht schoen... evtl das ganze noch etwas "reifen" lassen
Best Regards MfG Robert Schetterer
evtl schaltet man milter-manager davor nutzt eine regex condition auf den dns reverse
http://milter-manager.sourceforge.net/reference/configuration.html#configura...
Ziel waere dann opendmarc nur auf die ueblichen reverse dyn ips anzuwenden oder/und alles mit mehr als 4 punkten im namen etc, das sollte dann ein guter Kompromiss sein und die meisten pish mails abhalten ohne zu viele false positives wegen falscher policies oder was auch immer zu produzieren, ausserdem wuerde es Resourcen sparen, koennte man auch fuer spf und dkim milter anwenden, da man auch noch amavis und/oder spamassassin haben kann die selbst auch nochmal spf und dkim check machen koennen sollte man evtl ein "fast" ideales Setup configurieren koennen, auf jeden Fall waere es wohl einfach als fuer jeden Sonderfall in jedem Milter etwas whitelisten zu muessen
Best Regards MfG Robert Schetterer
Am Mittwoch, den 17.09.2014, 17:57 +0200 schrieb Robert Schetterer:
evtl schaltet man milter-manager davor nutzt eine regex condition auf den dns reverse
http://milter-manager.sourceforge.net/reference/configuration.html#configura...
Das ist mir zu kompliziert.
Ich hab jetzt noch mal die RFC gelesen wann das mit dem HELO auftreten kann:
"For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] authenticates either the domain that appears in the RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom is null (in the case of Delivery Status Notifications)."
Dann den Sourcecode nochmal studiert wann er was mit dem HELO macht. Ist eigentlich ganz einfach: wenn im Mailfrom was drin steht versucht er da einen Domainnamen rauszukriegen (was in der Mailadresse nach dem @ steht). Ist Mailfrom leer oder enthält keine Domain, dann wird stattdessen der HELO Name genommen. Ich kann da rein vom drüberschauen keinen Fehler entdecken. Man müsste mal an der Stelle reale Daten sehen, aber ich weiss nicht wie ich das debuggen soll. Man kann dem zwar zum Test eine Maildatei übergeben, aber ich kenn das Format dafür nicht. Mit dem Rohtext einer Mail klappt das jedenfalls nicht.
Aber ich bin eigentlich ganz zuversichtlich dass das jetzt funktioniert, ich kann mir nur vorstellen dass es mit dem Alignment bei Subdomains im HELO ein Problem gibt. Leider steht in dem Fehlerticket nix genaueres drin was denn nun das Problem bei HELO-Namen ist. Vielleicht sollte man in dem Fall die Subdomains vorne dran entfernen? Schade dass der Autor des Tickets kein Beispiel gebracht hat.
Am 17.09.2014 um 18:09 schrieb Joachim Fahrner:
Am Mittwoch, den 17.09.2014, 17:57 +0200 schrieb Robert Schetterer:
evtl schaltet man milter-manager davor nutzt eine regex condition auf den dns reverse
http://milter-manager.sourceforge.net/reference/configuration.html#configura...
Das ist mir zu kompliziert.
verstehe ich , aber ich brauche fuer meine tausenden von Usern , etwas was sehr "robust" auch bei "Fehlern" ist und trotzdem noch gut seinen Zweck erfuellt, perfekt wird es eh nie , es reicht wenn es "gute" Resultate bringt
Ich hab jetzt noch mal die RFC gelesen wann das mit dem HELO auftreten kann:
"For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] authenticates either the domain that appears in the RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom is null (in the case of Delivery Status Notifications)."
Dann den Sourcecode nochmal studiert wann er was mit dem HELO macht. Ist eigentlich ganz einfach: wenn im Mailfrom was drin steht versucht er da einen Domainnamen rauszukriegen (was in der Mailadresse nach dem @ steht). Ist Mailfrom leer oder enthält keine Domain, dann wird stattdessen der HELO Name genommen. Ich kann da rein vom drüberschauen keinen Fehler entdecken. Man müsste mal an der Stelle reale Daten sehen, aber ich weiss nicht wie ich das debuggen soll. Man kann dem zwar zum Test eine Maildatei übergeben, aber ich kenn das Format dafür nicht. Mit dem Rohtext einer Mail klappt das jedenfalls nicht.
Aber ich bin eigentlich ganz zuversichtlich dass das jetzt funktioniert, ich kann mir nur vorstellen dass es mit dem Alignment bei Subdomains im HELO ein Problem gibt. Leider steht in dem Fehlerticket nix genaueres drin was denn nun das Problem bei HELO-Namen ist. Vielleicht sollte man in dem Fall die Subdomains vorne dran entfernen? Schade dass der Autor des Tickets kein Beispiel gebracht hat.
nun ich bin zuversichtlich dass der code gefixed wird, aber selbst wenn die Software alles richtig macht , kann ja jederzeit jemand seine policy verpfuschen ,diesen Fall moechte auch weitgehend abgefangen haben, der Support der User ist in solchen Faellen ist naemlich sehr nervig und zeitraubend.
Best Regards MfG Robert Schetterer
Am 17.09.2014 um 11:19 schrieb Jochen Fahrner:
Lustig: jetzt geht zwar DHL, dafür werden jetzt DMARC-Reports von Google abgewiesen. ;-)
Sep 17 11:12:27 s2 postfix/postscreen[29962]: CONNECT from [2607:f8b0:4003:c01::249]:37530 to [2a01:4f8:d13:3016::2]:25 Sep 17 11:12:33 s2 postfix/postscreen[29962]: PASS NEW [2607:f8b0:4003:c01::249]:37530 Sep 17 11:12:35 s2 postfix/smtpd[29971]: connect from mail-ob0-x249.google.com[2607:f8b0:4003:c01::249] Sep 17 11:12:36 s2 postfix/smtpd[29971]: Anonymous TLS connection established from mail-ob0-x249.google.com[2607:f8b0:4003:c01::249]: TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits) Sep 17 11:12:37 s2 policyd-spf[29978]: None; identity=helo; client-ip=2607:f8b0:4003:c01::249; helo=mail-ob0-x249.google.com; envelope-from=noreply-dmarc-support@google.com; receiver=dmarc@fahrner.name Sep 17 11:12:37 s2 policyd-spf[29978]: Pass; identity=mailfrom; client-ip=2607:f8b0:4003:c01::249; helo=mail-ob0-x249.google.com; envelope-from=noreply-dmarc-support@google.com; receiver=dmarc@fahrner.name Sep 17 11:12:37 s2 postfix/smtpd[29971]: 47544341FA: client=mail-ob0-x249.google.com[2607:f8b0:4003:c01::249] Sep 17 11:12:37 s2 postfix/cleanup[29980]: 47544341FA: message-id=14117120610198414199@google.com Sep 17 11:12:37 s2 opendmarc[29698]: 47544341FA: google.com fail Sep 17 11:12:37 s2 postfix/pickup[29793]: 8C12734449: uid=118 from=<opendmarc> Sep 17 11:12:37 s2 postfix/cleanup[29984]: 8C12734449: message-id=20140917091237.8C12734449@s2.fahrner.name Sep 17 11:12:37 s2 opendkim[6724]: 8C12734449: DKIM-Signature header added (s=mail, d=fahrner.name) Sep 17 11:12:37 s2 postfix/cleanup[29980]: 47544341FA: milter-hold: END-OF-MESSAGE from mail-ob0-x249.google.com[2607:f8b0:4003:c01::249]: milter triggers HOLD action; from=noreply-dmarc-support@google.com to=dmarc@fahrner.name proto=ESMTP helo=<mail-ob0-x249.google.com>
Kann es sein dass SPF ein Problem mit ipv6 Adressen hat?
uff ich weiss das google "beim hinsenden" hin und wieder mails von ipv6 Adressen als Spam markiert hat , der workaround waere ein transport nur auf ipv4 fuer google, mein letzter Stand dazu ist dass es daran liegen koennte das viele Sender vergessen auch fuer ihre ipv6 Adressen zusaetzlich SPF policies zu veroeffentlichen ( inkl harte SPF A Eintrage fuer ihren mailserver hostnamen ), damals waren die google Seiten dazu nicht hilfreich, und ich konnte es auch final nicht verifizieren
zu deiner Frage
dig -t txt google.com
; <<>> DiG 9.7.0-P1 <<>> -t txt google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33915 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION: ;google.com. IN TXT
;; ANSWER SECTION: google.com. 3600 IN TXT "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
dig -t txt _spf.google.com
; <<>> DiG 9.7.0-P1 <<>> -t txt _spf.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33721 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION: ;_spf.google.com. IN TXT
;; ANSWER SECTION: _spf.google.com. 300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
dig -t txt _netblocks.google.com
; <<>> DiG 9.7.0-P1 <<>> -t txt _netblocks.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42680 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION: ;_netblocks.google.com. IN TXT
;; ANSWER SECTION: _netblocks.google.com. 400 IN TXT "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ~all"
dig -t txt _netblocks2.google.com
; <<>> DiG 9.7.0-P1 <<>> -t txt _netblocks2.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55896 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION: ;_netblocks2.google.com. IN TXT
;; ANSWER SECTION: _netblocks2.google.com. 2958 IN TXT "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
dig -t txt _netblocks3.google.com
; <<>> DiG 9.7.0-P1 <<>> -t txt _netblocks3.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 913 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION: ;_netblocks3.google.com. IN TXT
;; ANSWER SECTION: _netblocks3.google.com. 883 IN TXT "v=spf1 ~all"
es gibt also ipv6 Angaben, alles ist im Testing mode, die scheinen auch ok zu sein nach deinem policy-spf
Sep 17 11:12:37 s2 policyd-spf[29978]: Pass; identity=mailfrom;
Sep 17 11:12:37 s2 opendmarc[29698]: 47544341FA: google.com fail
ok wieder opendmarc
in meinem report ist ein DKIM KEY drinn , ich geh mal davon aus dass der Ok ist
ich wuerde hier auf einen bug tippen, da gabs wohl mit DKIM schon mal Probleme, die aber gefixed worden sind , per se wg ipv6 hab ich jetzt nichts gefunden
ich empfehle ein Ticket bei opendmarc aufzumachen
Best Regards MfG Robert Schetterer
Am 17.09.2014 um 11:09 schrieb Robert Schetterer:
Am 17.09.2014 um 10:46 schrieb Jochen Fahrner:
Am 17.09.2014 08:00, schrieb David Schweikert:
Gemaess Spezifikation reicht es, wenn eine Authentifizierung-Mechanismus erfolgreich ist.
Ich finde den DMARC Draft schon klar diesbezueglich, aber sehe auch z.B. Google: https://support.google.com/a/answer/2466580?hl=en
"A message must fail both SPF and DKIM checks to also fail DMARC."
Ich würde sagen, halten wir fest:
Die RFC ist "interpreationsfähig".
jep da hast du absolut recht, ich hab den Author jetzt angeschrieben wenn man die Reihenfolge in der RFC beruecksichtigt muesste der milter es durchlassen wenn mind ein check ok ist, das widerspricht sich aber dann etwas im weiteren Text, aber vieleicht reichts da dann auch einfach nimmer mit meinem English *g
Google beschreibt es klarer.
Postfix und/oder OpenDMARC haben ein Problem mit dem normalen policyd-spf,
OpenDMARC *muss* den SPF-Check selber machen, und das
also anfaenglich habe ich das mal so vorausgesetzt, aber gut zu wissen
klappt auch nur korrekt mit der libspf2.
Falls Robert immer noch Zweifel hat, hier ein Auszug aus dem Sourcecode von OpenDMARC (opendmarc_policy.c):
/* * If dkim passes and dkim aligns OR spf passes and spf aligns * Accept the message. */ if (pctx->spf_alignment == DMARC_POLICY_SPF_ALIGNMENT_PASS || pctx->dkim_alignment == DMARC_POLICY_DKIM_ALIGNMENT_PASS) return DMARC_POLICY_PASS;
ich hab in deiner config jetzt nicht weiteres gesehen, wenn jetzt nicht irgendein Bug drinn ist , hab ich mich vertan, und du hast "den Fehler" gefunden. Mal sehen evtl kriegen wir das vom DMARC RFC Author verifiziert, wir finden das schon raus *g
Best Regards MfG Robert Schetterer
zumindest weiss ich jetzt wie es "gemeint ist"
Am 17.09.2014 um 11:05 schrieb Murray S. Kucherawy:
If the message has no DKIM signature, then SPF has to be failing for opendmarc to block it.
mein Annahme war also falsch ( sich in den Staub wirft ... )
auf die Kritik an dem RFC Text hab ich noch keine Antwort *g
Best Regards MfG Robert Schetterer
participants (5)
-
David Schweikert -
Joachim Fahrner -
Jochen Fahrner
-
Patrick Ben Koetter -
Robert Schetterer