Werden Mailinglisten "kaputt", wenn SPF zu restriktiv ist?

Ich habe kürzlich meinen eigenen Mailserver konfiguriert (Linux-basiertes Postfix + Dovecot-Szenario). Dies ist nur für den persönlichen Gebrauch - ich habe keine Massenpost, keine automatisch generierte Post, die vom Host ausgeht, nichts dergleichen. Ich habe mir die Mühe gemacht, alle zusätzlichen E-Mail-DNS-Einträge zu konfigurieren, die Spaß beim Debuggen machen:

@                 IN  TXT  v=spf1 +mx -all
_domainkey        IN  TXT  o=-; r=dkim@example.com
mail._domainkey   IN  TXT  v=DKIM1; h=sha256; k=rsa; s=email; p=deadbeef
_adsp._domainkey  IN  TXT  dkim=all
_dmarc            IN  TXT  adkim=s; aspf=s; fo=1; p=none; pct=100; rf=afrf; ri=86400; rua=mailto:aggrep@example.com; ruf=mailto:authfail@example.com; sp=none; v=DMARC1;

Ich habe eine IP, die nicht auf einer schwarzen Liste steht, eine korrekt konfigurierte PTR, DKIM-Signaturen werden perfekt validiert. Ich dachte, alles ist korrekt eingerichtet.

Aber jetzt kann ich nicht zu Mailinglisten beitragen. Wenn ich an die Listenadresse sende, geht die Nachricht manchmal in ein schwarzes Loch, manchmal erhalte ich eine E-Mail an meine authfail@Adresse, und in anderen Fällen sehe ich Einträge, von denen ich glaube, dass sie mit Berichten zusammenhängen, an die gesendet wird aggrep@.

Meine Theorie ist, dass die SPF-Politik zu restriktiv ist. Der Mailman (oder ein anderer) Listenserver fungiert als SMTP-Relay für meine Nachrichten, oder? Also habe ich mich verändert

@                 IN  TXT  v=spf1 +mx -all

zu

@                 IN  TXT  v=spf1 +mx ~all

Die Standardaktion wird zu einem Softfail anstelle eines Hardfails. Das Problem ist, dass ich Spam-Listen nicht ohne guten Grund umgehen möchte, um diese Änderung zu testen. War noch jemand hier und kann meine Theorie verifizieren / widerlegen?

EDIT 1:

Wenn ich zurückdenke und @Alex danke, dass er mich klargestellt hat, habe ich wirklich nicht genug Daten bereitgestellt, um eine genaue Einschätzung vorzunehmen. Hier ist ein Beispiel für eine Benachrichtigung, die ich an meine authfail@Adresse erhalten habe, als ich versucht habe, auf einer Mailingliste zu posten:

This is a spf/dkim authentication-failure report for an email message received from IP 66.211.214.132 on Thu, 10 Jul 2014 20:58:52 +0800.
Below is some detail information about this message:
 1. SPF-authenticated Identifiers: archlinux.org;
 2. DKIM-authenticated Identifiers: none;
 3. DMARC Mechanism Check Result: Identifier non-aligned, DMARC mechanism check failures;

For more information please check Aggregate Reports or mail to abuse@126.com.



Feedback-Type: auth-failure
User-Agent: NtesDmarcReporter/1.0
Version: 1
Original-Mail-From: <arch-general-bounces@archlinux.org>
Arrival-Date: Thu, 10 Jul 2014 20:58:52 +0800
Source-IP: 66.211.214.132
Reported-Domain: example.com
Original-Envelope-Id: w8mowEA5UUwMjr5TlWQfBA--.250S2
Authentication-Results: 126.com; dkim=fail (signature error: RSA verify failed) header.d=example.com; spf=pass smtp.mailfrom=arch-general-bounces@archlinux.org
DKIM-Domain: example.com
Delivery-Result: delivered

Sieht für mich so aus, als wäre dies ein DKIM-Signaturfehler, aber ich habe keine Ahnung warum. Versucht der empfangende Server, meine DKIM-Signatur anhand des Schlüssels des Mailinglisten- Servers zu überprüfen , oder umgekehrt? Aus irgendeinem Grund würde ich nicht damit rechnen - ich erinnere mich, dass ich irgendwo gelesen habe, dass in solchen Fällen Relais und dergleichen manchmal solche Header entfernen / munge, um sicherzustellen, dass diese Arten von Fehlern nicht auftreten?

EDIT 2:

Vielen Dank an @Christopher Karel für die Referenzierung eines DMARC-Tools zum Parsen von Berichten auf dmarcian.com. Der Löwenanteil der Einträge wird als Weiterleitung aufgeführt (was sinnvoll ist). Es gibt einen Server (* .mailhop.org), der als "DKIM beibehalten" aufgeführt ist. Ich habe erfolgreich E-Mails über eines der funktionierenden Ruby-Foren gesendet, und ich weiß aus meinen Recherchen, dass sie mailhop.org verwenden.

Unter der Kategorie „Server , die Pause DKIM - Signaturen (oder gefälschte Signaturen erstellen)“ aufgeführt sind *.archlinux.org, *.google.com, *.mailhop.org(Keine Ahnung , warum dies scheint hier, vielleicht eine andere Liste Ich bin auf nutzen sie auch in einer anderen Konfiguration), unter anderem und den Listen I Am aktivsten waren Arch und einige von Google Groups gehostete, daher ist dies sinnvoll. Insgesamt ungefähr 400 Nachrichten - ich habe nicht annähernd so viele Nachrichten gesendet, also denke ich, dass es sich um Wiederholungsversuche handelt.

Ich werde depressiv - im Moment scheinen meine Entscheidungen wie folgt zu sein:

1. Behalten Sie SPF, DKIM, DMARC und ADSP bei und geben Sie die Verwendung von Mailinglisten auf, oder
2. Löschen Sie diese DNS-Sicherheits- / Berichtsebene und lassen Sie meine normalen ausgehenden E-Mails von Google, Yahoo! Live usw. ablehnen.

E-Mail-Sicherheit ist scheiße. Am Ende werden Sie wahrscheinlich vor einer Entscheidung stehen, bei der alle Ihre Optionen schrecklich sind und verschiedene Dinge aus verschiedenen Gründen brechen.

Was SPF betrifft, verursacht eine Mailingliste einen Fehler, wenn sie eine Nachricht weiterleitet, ohne die Header neu zu schreiben . Eine Liste kann sich so konfigurieren, dass sie funktioniert, wie es ihnen gefällt, daher gibt es keine gute allgemeine Antwort. Wenn jedoch Nachrichten aus einer Liste aus der Liste selbst stammen, werden die Header neu geschrieben. Wenn es vom Absender zu kommen scheint, wahrscheinlich nicht. Im Allgemeinen Mailinglisten sollte gut mit SPF auf seinem eigenen. Regelmäßige Mail-Weiterleitung hingegen nicht.

Wenn es um DKIM geht, führen Änderungen an der Nachricht zu einem Fehler. Dies tritt fast immer bei einer Mailingliste auf. Daher bombardiert DKIM normalerweise mit Mailinglisten. Die Weiterleitung von E-Mails sollte jedoch in Ordnung sein.

Darüber hinaus haben Sie DMARC implementiert . Dies ist im Wesentlichen eine Berichtsinfrastruktur, die sich um DKIM und SPF dreht. Es funktioniert am besten, wenn Sie beide Authentifizierungsmaßnahmen implementieren, aber auch mit nur einer. Sie können DMARC so konfigurieren, dass eine Drop-Anforderung für Ihre Nachrichten übermittelt wird. Noch wichtiger ist jedoch, dass Sie eine Adresse angeben, um Erfolgs- / Fehlerberichte zu erhalten. Diese werden von den meisten großen E-Mail-Empfängern unterstützt. (GMail, Hotmail, Yahoo) Dies kann Ihnen einen Einblick geben, welche Nachrichten die SPF-Prüfung nicht bestehen und warum. Verwenden Sie dies, um Ihre -allvs ~allEntscheidung zu informieren .

Leider erfordert die DMARC-Spezifikation eine Ausrichtung zwischen der Absenderdomäne und dem SPF-Datensatz, der überprüft wird. In Ihrem Fall wird der SPF der Mailingliste überprüft und bestanden, stimmt jedoch nicht mit Ihrer Domain überein. Also DMARC-Bomben. Hier ist eine Referenz von einem Mailinglisten-Administrator, der sich um so viel kümmert.

Die Schlussfolgerung ist die gleiche wie in meinem Eröffnungssatz: E-Mail-Sicherheit ist zum Kotzen. Und alle Ihre Optionen saugen auch. IMHO, Mailinglisten saugen auch, und das Leben wäre besser, wenn wir sie ersetzen würden. ;-);

Ich habe mir den DKIM-Teil nicht angesehen.

In Bezug auf den SPF-Datensatz sehe ich Folgendes, das in den meisten Beispielen verwendet wird:

v = spf1 mx -all

Dies ist hier dokumentiert: http://www.openspf.org/SPF_Record_Syntax

"+ Mx" sollte jedoch auch gemäß RFC 7208 korrekt sein (Danke Chris für den Hinweis). Vielleicht ist es noch einen Versuch wert ...

Ich weiß wirklich nicht, was ich sonst vorschlagen soll ... Überprüfen Sie Ihren gesamten DNS-Eintrag (A / PTR / MX). Sie haben es wahrscheinlich schon getan. Die Kenntnis des tatsächlichen Domainnamens kann bei der Fehlerbehebung hilfreich sein - zumindest wenn dies mit DNS zusammenhängt.

Es stellt sich heraus, dass an meiner Konfiguration nichts falsch zu sein scheint. Was passiert ist, dass meine Nachrichten vom Postboten korrekt verarbeitet und an die Liste weitergeleitet werden. Es gibt jedoch einige Empfänger, die (aus welchen Gründen auch immer) die Nachricht ablehnen. Da ich SPF tatsächlich korrekt konfiguriert habe, wird die Ablehnungsnachricht von diesen Ziel-SMTP-Servern angezeigt, nicht vom Mailinglisten-Relay selbst.

Einige großartige Leute in der Arch-Community haben mir geholfen, diesen zu jagen, da sie Zugriff auf diesen ML-Server hatten.