DKIM Authenticated wir nicht bestanden / DKIM-Signature Leerzeichen nach d=

[W. Reichert]

Hallo Allerseits,

ich habe hier einen Fehler der sich wie folgt auswirkt, DKIM Authenticated wird nicht bestanden.

Ursache:
Beim einfügen der DKIM-Signature wird nach dem 'd=' ein Leezeichen eingefügt, bei langen Domännamen -> 'd= domain.de' statt 'd=domain.de'.
Dies widerspricht den RFs. Dies tritt vermutlich (nach Tests mit unterschiedlichen Domänamenlänge)
wohl nur auf, wenn der Domänname eine gewisse Länge überschreitet.

In den folgenden Beispielen beträgt die Länge der ersten Domain 17 Zeichen, im zweiten Fall 15 Zeichen.

Beispiele:


Andere Domain:




Besten Dank für Eure Unterstützung.

 

[Stoiko Ivanov]

Ursache:
Beim einfügen der DKIM-Signature wird nach dem 'd=' ein Leezeichen eingefügt, bei langen Domännamen -> 'd= domain.de' statt 'd=domain.de'.
Dies widerspricht den RFs. Dies tritt vermutlich (nach Tests mit unterschiedlichen Domänamenlänge)
wohl nur auf, wenn der Domänname eine gewisse Länge überschreitet.

In den folgenden Beispielen beträgt die Länge der ersten Domain 17 Zeichen, im zweiten Fall 15 Zeichen.

habe ich hier jetzt nicht nachstellen können ...
* domain 'aaaaaaaaaaaaaaaaaaaaaaaaa.XXXX.proxmox.invalid'
* PMG als signer
* der header wird genauso umgebrochen wie in den screenshots die gepasted wurden
* rspamd auf der receiver seite nimmt die mail mit DKIM-pass an

Soweit ich das sehe sollte das auch kein Thema sein, da e-mail header durchaus gewrapped werden (um nicht zu lange zu werden)

Potentiell mal beim provider des Testtools nachfragen warum genau es failed.

Dies widerspricht den RFs.

falls damit RFCs gemeint sind - welchen widerspricht es?

Ich hoffe das hilft!

 

[noodysseus]

Hallo Support,
wir haben das selbe Problem an 3 unterschiedliche PMG Server (letzter Software-Stand 8.0.11/0509e565d48).
Test: eine E-Mail an mxtoolbox.com (abuse@mxtoolbox.com). Dann sieht man im Header der E-Mail d= example.com
(man beachte den Blank hinter dem d=).

Einige Server quoten den blank hier dem d=
Dann ist der Fehler nicht bemerkbar (z.B. check-auth@verifier.port25.com)

Bei Exchange-Online kommt es zu teilweise zur Probleme.

Der Schreiber davor hat das Problem korrekt geschildert.

MfG

 

[W. Reichert]

Sorry noodysseus die korrekte Adresse für mxtoolbox ist 'ping@tools.mxtoolbox.com'

 

[Stoiko Ivanov]

wir haben das selbe Problem an 3 unterschiedliche PMG Server (letzter Software-Stand 8.0.11/0509e565d48).
Test: eine E-Mail an mxtoolbox.com (abuse@mxtoolbox.com). Dann sieht man im Header der E-Mail d= example.com
(man beachte den Blank hinter dem d=).

Einige Server quoten den blank hier dem d=
Dann ist der Fehler nicht bemerkbar (z.B. check-auth@verifier.port25.com)

Bei Exchange-Online kommt es zu teilweise zur Probleme.

Der Schreiber davor hat das Problem korrekt geschildert.

da bräuchte es die gesamten header dieser testmail - ich würde mal annehmen, dass da potentiell ein weiteres service beim relayen der email die header nicht ganz korrekt umschreibt ....

auch wäre es spannend ob das Problem mit anderen DKIM Signers ebenso besteht....

 

[noodysseus]

Hallo Support, können wir gerne machen, aber nicht öffentlich

MfG

 

[W. Reichert]

...
Soweit ich das sehe sollte das auch kein Thema sein, da e-mail header durchaus gewrapped werden (um nicht zu lange zu werden)
....

Bin auch der Meinung das ein Zeilenumbruch nicht stören solle. Jedoch an der Stelle 'd=' ist das wohl nicht gut. Ideal wäre davor oder dahinter. So wie es aussieht haben einige Systeme mit eienm Zeilenumbruch an der Stelle echte Probleme das richtig zu interpretieren/auszuwerten.

 

[Stoiko Ivanov]

beim näheren betrachten fällt mir auf, dass es nicht so aussieht als ob die mails von PMG gesigned werden? (auf Grund der Auswahl an headern die signiert werden) - ist das der Fall - wie sieht die mail aus wenn sie nicht durch PMG geht, funktioniert die DKIM authentication in dem fall?

 

[noodysseus]

Hallo Support, bei uns gehen die E-Mail definitiv durch die PMG. Davor werden dise nicht signiert, der Postfix ist von mir nicht konfiguriert. Ich arbeite seit mehr als 25 Jahr mit Mailsysteme. Der PMG Cluster signiert.
MfG

 

[noodysseus]

Hallo Support, wie könnte ich den Header bereitstellen? So dass die Vertraulichkeit bewahrt bleibt.
MfG

 

[W. Reichert]

beim näheren betrachten fällt mir auf, dass es nicht so aussieht als ob die mails von PMG gesigned werden? (auf Grund der Auswahl an headern die signiert werden) - ist das der Fall - wie sieht die mail aus wenn sie nicht durch PMG geht, funktioniert die DKIM authentication in dem fall?

Definitive werden die Mails von der PMG signiert. Das ist einer der Gründe warum diese über eingerichtet wurde.
Ich möchte Ihnen gerne die Reports zukommen, jedoch möchte ich diese nicht hier im öffentlichen Bereich posten. Gib es die Möglichkeit einer persönlichen Nachricht oder sowas in der Art?

Danke

 

[Stoiko Ivanov]

Gib es die Möglichkeit einer persönlichen Nachricht oder sowas in der Art?

Prinzipiell gäbe es dafür unser Enterprise support portal - das steht aber nur Usern mit Subscriptions der Level Basic oder höher zur Verfügung.
Falls die vorhanden sind - bitte einfach dort ein Ticket aufmachen.

beim näheren betrachten fällt mir auf, dass es nicht so aussieht als ob die mails von PMG gesigned werden? (auf Grund der Auswahl an headern die signiert werden)

da habe ich mich verlesen... und meine testmail war etwas zu simpel um content-transfer-encoding header zu brauchen - danke für den Hinweis.


Das Leerzeichen nach 'd=' sollte soweit ich die RFCs lese nicht ursächlich für das Problem sein:
siehe https://datatracker.ietf.org/doc/html/rfc6376#section-3.2

Note that WSP is allowed anywhere around tags. In particular, any
WSP after the "=" and any WSP before the terminating ";" is not part
of the value; however, WSP inside the value is significant.

 

[noodysseus]

Hallo Support, hier ein bereinigter Header:
--snipp
From info@12345678901234567.de Mon Feb 12 11:37:27 2024
Return-Path:
X-Original-To: ping@tools.mxtoolbox.com
Delivered-To: tools@tools.mxtoolbox.com
Received: from mail.example.eu (mail.example.eu [000.000.000.001])
(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by tools.mxtoolbox.com (Postfix) with ESMTPS id B0676B5F22
for ; Mon, 12 Feb 2024 11:37:27 +0000 (UTC)
Received: from mail.example.eu (localhost.localdomain [127.0.0.1])
by mail.example.eu (Proxmox) with ESMTP id 9FC55308D6
for ; Mon, 12 Feb 2024 12:37:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
12345678901234567.de; h=cc:content-transfer-encoding
:content-type:content-type:date:from:from:message-id
:mime-version:reply-to:subject:subject:to:to; s=s1; bh=47DEQpj8H
BSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Rnq5RzszDHW822r8ff8KrvO9+
vmFe2Kr0aWFJqTCqgg6nt0BriaTf1kAQEUu9i+Z+6OzUWl06GmUroTEQTjHixblE
PLLVLM26tBiDQblgabnUVXFojUkaUpcVrtib/nIeskzV/j4gIjJlVxudBvKCYc7M
HGcOJGnjjNW4Q1Zn4TIGWTwtr+t1wjnghXvNj9aNJfB1tp5gusHQfC1hRgYY/7uS
1e2qItR/0tAcSF26NkP07gNxyN+YjG5SXLRxL7U7HDWlcs6MWmV+oqwxBt7DJhaH
FnsRgGq8KT4y5U5Ogl6YAyc1CdmyB4WRNUL3RBz2z3FGpBbXkLQRIKh1RwKkg==
To: "ping@tools.mxtoolbox.com"
From: "info@12345678901234567.de"
Subject: 19
Message-ID:
Disposition-Notification-To: "info@12345678901234567.de"
--snipp

MfG

 

[noodysseus]

Hallo Support, leider haben wir nur den community support.
Hmm, bei der RFC 5672 Punkt 10. und RFC 4871 Section 3.5 wird nur von "d=" gesprochen, aber es wird auch nicht explizit ausgeschlossen, dass es nicht erlaubt sei.
Jedoch ist d=domain bedingt durch die " eingeschlossen und bei einem blank wird ein CRLF interpretiert, was einen Zeilemumbruch bedeutet. Damit ist die domaine, aber von d= getrennt und mxtoolbox wirft es einem als nicht "DKIM Athenticated" vor die Füße.
Gerade nochmal gegen Exchange Online getestet und das selbe Problem kommt. Nach dem d= wird die Leerstelle als neue Zeile interpretiert.
Ist die Interpretation falsch?
MfG

 

[Stoiko Ivanov]

Hmm, bei der RFC 5672 Punkt 10. und RFC 4871 Section 3.5 wird nur von "d=" gesprochen, aber es wird auch nicht explizit ausgeschlossen, dass es nicht erlaubt sei.

Verstehe die Analyse nicht so ganz - in der Section die ich verlinkt habe (aus der mein Quote kommt ) steht kurz über dem Quote:

[FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]

Soweit ich das lese is '[FWS]' - folding white space - dass wiederum spaces und CRLF beinhalten kann - sprich, so wie ich das lese muesste beides
"d=12345678901234567.de" und "d= 12345678901234567.de" akzeptiert werden (und wird es bei meinen tests auch).

(außerdem sind RFC 4871 und RFC 5672 beide von RFC 6373 obsoleted worden, der jedoch bei dem Punkt mit beiden übereinstimmt)

Jedenfalls habe ich jetzt mal von einer Domain (ohne DMARC record) eine testmail mit DKIM signature geschickt - da wird der DKIM Authentication check zwar auch in Rot dargestellt, allerdings steht unten bei der Analyse, dass der body hash und sonst alle checks mit der DKIM signature funktionieren (siehe screenshot)
Wie sieht das bei euch aus? (bevor der test was ganz anderes testet und wir hier vergebens suchen....)

 

[noodysseus]

Hallo Support, wir haben die RFC nochmal und nochmals gelesen, Sie haben recht, laut RFC ist es erlaubt.
Bei mxtoolbox ist es genauso, wie bei Ihnen (s. Bild). Der Check ist i.O. aber der DKIM Authentication check schlägt fehl.
Dummerweise schickt Exchange Online zumeist die E-Mails weiterhin in die Quarantäne - aber auch nicht immer (andere Server, wie Sendmail und Postfix nicht - zumindest keine Rückmeldungen diesbezüglich).
Wie der Vorgänger schreibt, klang es ganz plausible als Problem.
Leider haben wir keine Idee mehr, was hier sonst das Problem sein kann. Falls es nicht ein mxtoolbox Bug ist (was immer wahrscheinlicher wird) und MS andere Probleme hat und die Blanks anders interpretiert als der Rest der Welt.
Evtl. sollte die Leerstelle bei d= "weggequotet" werden - falls es überhaupt das Problem ist, da die Markmacht von MS ungünstig groß ist.
Sind wir und der vorschreiber, die einzigen, die ein solches Problem mit längeren Domänennamen haben?

MfG und Danke!!

 

[Stoiko Ivanov]

Hallo Support, wir haben die RFC nochmal und nochmals gelesen, Sie haben recht, laut RFC ist es erlaubt.
Bei mxtoolbox ist es genauso, wie bei Ihnen (s. Bild). Der Check ist i.O. aber der DKIM Authentication check schlägt fehl.

Sehr gut - zumindest suchen wir jetzt nicht mehr an der falschen Stelle

Leider haben wir keine Idee mehr, was hier sonst das Problem sein kann. Falls es nicht ein mxtoolbox Bug ist (was immer wahrscheinlicher wird) und MS andere Probleme hat und die Blanks anders interpretiert als der Rest der Welt.

bezüglich mxtoolbox habe ich zumindest folgendes gefunden:
https://serverfault.com/questions/1...oolbox-reports-as-dkim-signature-not-verified
Ich würde vorschlagen dort mal nachzufragen, da sie bestimmt am besten wissen warum ein test bei Ihnen nicht funktioniert.

Evtl. sollte die Leerstelle bei d= "weggequotet" werden -

das ist nicht wirklich zuverlässig möglich - sämtliche E-mail RFCs, die mir so bekannt sind, bedenken, das e-mails potentiell im Verlauf der Zustellung öfter etwas umformatiert werden - und das Header gefoldet (auf mehrere Zeilen verteilt mit space oder tab danach) bzw. wieder zusammengesetzt werden.

falls es überhaupt das Problem ist, da die Markmacht von MS ungünstig groß ist.

hm - auch hier wuerde ich versuchen den Microsoft support zu fragen - bzw. auch die Logs von den abgelehnten mails mal genauer anzusehen - da stehen oft links auf deren Dokumentation, die das Problem vielleicht besser beschreiben.

Danke für das Teilen der results!

 

[noodysseus]

Guten Morgen Support, das ist unser erachtens nach kein PMG Problem mehr.
MfG

 

[noodysseus]

Hallo Support, wir tun alles damit Proxmox PMG zu einer ernsthaften Konkurenz zu MS wird.
MfG

 

[W. Reichert]

Auch von meiner Seite Besten Dank für Eure Unterstützung..
Die Geschichte mit dem Leerzeichen war der einzige offensichtliche Unterschied, welcher sich auch reporduzieren lies.
MfG