<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div class=""><p class=""><font face="Trebuchet MS" class="">Sorry, die Mail sollte eigentlich an
die Liste gehen 😅</font><br class=""></p></div></div></blockquote><div>Über die Liste bekomme ich von rspamd:</div><div>DMARC_POLICY_QUARANTINE:1.50:<a href="http://syntaxys.de" class="">syntaxys.de</a> : SPF not aligned (relaxed), DKIM not aligned (relaxed);quarantine</div><div><br class=""></div><div><a href="https://datatracker.ietf.org/doc/html/rfc7960#section-2.2" class="">https://datatracker.ietf.org/doc/html/rfc7960#section-2.2</a></div><div><br class=""></div><div>------------------------</div><div>2.2. Message Forwarding<br class=""><br class=""> Section 3 describes forwarding behavior as it relates to the<br class=""> components of the Internet Mail Architecture.<br class=""><br class=""> All forwarding operations involve the retransmission of email. As<br class=""> discussed above, in order for SPF to yield an Authenticated<br class=""> Identifier that is pertinent to DMARC, the domain of the<br class=""> RFC7208.MAILFROM must be in alignment with the RFC5322.From header<br class=""> field. Forwarding introduces specific issues to the availability of<br class=""> SPF-based Authenticated Identifiers:<br class=""><br class=""> - If the RFC5321.MailFrom is present and the forwarder maintains the<br class=""> original RFC5321.MailFrom, SPF validation will fail unless the<br class=""> forwarder is an authorized part of the originator's email sending<br class=""> infrastructure. If the forwarder replaces the RFC5321.MailFrom<br class=""> with its own domain, SPF might pass, but Identifier Alignment with<br class=""> the RFC5322.From header field will fail.<br class=""><br class=""> - If the RFC5321.MailFrom is empty (as in the case of Delivery<br class=""> Status Notifications), the RFC5321.HELO/.EHLO domain of the<br class=""> forwarder will likely be in a different Organizational Domain than<br class=""> the original RFC5322.From header field's domain. SPF may pass,<br class=""> but Identifier Alignment with the RFC5322.From header field will<br class=""> fail.<br class=""><br class=""> In both cases, SPF cannot yield relevant Authenticated Identifiers,<br class=""> and DKIM must be relied upon to produce results that are relevant to<br class=""> DMARC.<br class="">-------------------------</div><div><br class=""></div><div>Ich verstehe das so: normalerweise wird für SPF nur der envelope-sender</div><div>angeschaut (= "MAIL FROM" im SMTP-Protokoll). In Verbindung mit DMARC muss</div><div>dieser zusätzlich mit dem "From:" innerhalb der Mail übereinstimmen um einen</div><div>"Authenticated Identifier" zu liefern.</div><div><br class=""></div><div>Die Mailingliste ersetzt den envelope-sender mit <a href="mailto:postfixbuch-users-bounces@listen.jpberlin.de" class="">postfixbuch-users-bounces@listen.jpberlin.de</a>.</div><div>Damit kann der SPF an sich verifiziert werden, fällt aber für DMARC raus.</div><div><br class=""></div><div><br class=""></div><div>Bzgl. DKIM: <a href="https://datatracker.ietf.org/doc/html/rfc6376#section-3.1" class="">https://datatracker.ietf.org/doc/html/rfc6376#section-3.1</a></div><div><div class=""><br class=""></div><div class="">ABNF:</div><div class=""><br class=""></div><div class=""> selector = sub-domain *( "." sub-domain )</div><br class="Apple-interchange-newline">sub-domain ist definiert in <a href="https://datatracker.ietf.org/doc/html/rfc5321" class="">https://datatracker.ietf.org/doc/html/rfc5321</a> als</div><div><br class=""></div><div>sub-domain = Let-dig [Ldh-str]</div><div><div class="">Let-dig = ALPHA / DIGIT</div><div class="">Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig</div><div><br class=""></div><div>ALPHA wiederum in <a href="https://datatracker.ietf.org/doc/html/rfc5234#appendix-B" class="">https://datatracker.ietf.org/doc/html/rfc5234#appendix-B</a></div><div>ALPHA = %x41-5A / %x61-7A ; A-Z / a-z</div><div><br class=""></div><div>Falls ich nichts übersehen hab sollten im Selektor weder "_" noch "." vorkommen:</div><div><br class=""></div>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=<a href="http://syntaxys.de" class="">syntaxys.de</a>;<br class=""> s=<a href="http://2022-02-20_syntaxys.de" class="">2022-02-20_syntaxys.de</a><br class="Apple-interchange-newline"><br class=""></div><div>Probier vielleicht mal s=dkim20220220</div><div><br class=""></div><div>In der Mail gibt es zwei DKIM-Signature Header, einen von der Liste und einen von Dir.</div><div>Falls Deiner wegen der Syntax nicht ausgewertet wird würde das "<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">DKIM not aligned (relaxed)"</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">von </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">DMARC_POLICY_QUARANTINE erklären.</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div>Viele Grüße</div><div>Gerald </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">
</p>
<div class="moz-cite-prefix">Am 21.02.22 um 18:14 schrieb Achim
Lammerts:<br class="">
</div>
<blockquote type="cite" cite="mid:c168d243-3cb9-c7d8-93bc-fc13efd03696@syntaxys.de" class="">Also
inzwischen bin ich mit der Signatur des Headers bei
<br class="">
sign_headers = "from:subject:date:to";
<br class="">
angelangt und trotzdem wird sie von der Liste zerbröselt.
<br class="">
<br class="">
Ich hab mir mal die Header von anderen Emails angesehen, ein paar
mit DKIM-Signatur schaffen's ja ohne Beanstandungen durch die
Liste. Was läuft da anders?
<br class="">
<br class="">
<br class="">
Am 21.02.22 um 15:44 schrieb Gerald Galster:
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Bekomme ich es hin, daß Emails an Listen
nicht signiert werden und bei den Empfängern auch keine
Prüfung gegen DMARC erfolgt – und zwar aus der gleichen
Domain, für die bisher restriktive Einstellungen gut
funktionieren?
<br class="">
Laut diversen Online-Tools passt eigentlich alles prima, bis
auf das Gezicke mit den Listen.
<br class="">
</blockquote>
<br class="">
Man hat keinen Einfluss darauf wie die Empfänger prüfen.
<br class="">
<br class="">
Beispiel aus dem Maillog:
<br class="">
DMARC_POLICY_REJECT:2.00:<a href="http://domain.de" class="">domain.de</a> : SPF not aligned (strict),
No valid DKIM;reject
<br class="">
<br class="">
Rspamd vergibt in dem Fall Spampunkte (standardmäßig), man kann
aber auch einstellen, dass abgelehnt wird.
<br class="">
<a class="moz-txt-link-freetext" href="https://rspamd.com/doc/modules/dmarc.html">https://rspamd.com/doc/modules/dmarc.html</a>
<br class="">
dmarc { actions { reject="reject"; ...
<br class="">
<br class="">
<blockquote type="cite" class="">Eine weitere Frage zum Thema:
<br class="">
Wie wird mit „p=reject“ i. d. R. umgegangen? Angenommen ein
Empfänger lehnt die E-Mail wegen des DKIM-Fails ab,
verschwindet die dann im Nirvana oder wird die gebounced?
Bisher hatte ich immer nur in den Reports gesehen, daß etwas
nicht passt, aber nie einen reject beim Einliefern …
<br class="">
</blockquote>
<br class="">
Verloren gehen Mails bei SMTP so gut wie nie. Wenn abgelehnt
wird ist es Sache des einliefernden Mailservers den Absender zu
benachrichtigen (bounce).
<br class="">
<br class="">
Viele Grüße
<br class="">
Gerald
<br class="">
</blockquote>
</blockquote>
</div>
</div></blockquote></div><br class=""></body></html>