Warum arbeitet DMARC mit der Absenderadresse und nicht mit dem Briefumschlagsender (Return-Path)?

7

Mehrere E-Mails, die von meinem Webserver an eine Google Mail-Adresse gesendet wurden, an der sich die From:Adresse befindet [email protected], wurden von Google Mail als Spam markiert. Das From:Feld wird aus Formulardaten ausgefüllt und entspricht der tatsächlichen E-Mail-Adresse des Besuchers, bei der es sich häufig um eine Google Mail-Adresse handelt. Das Return-Path:zeigt immer auf eine Adresse [email protected], was bedeutet, dass SPF- und DKIM-Prüfungen funktionieren.

Wenn ich die unformatierten E-Mails im Google Mail-Konto überprüfe, wird Folgendes angezeigt:

Delivered-To: [email protected]
...
Return-Path: <[email protected]>
Received: from mywebserver.com (mywebserver.com. [my:ipv6:address])
        by mx.google.com with ESMTPS id xxx
        for <[email protected]>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 02 Feb 2016 00:40:02 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates my:ipv6:address as permitted sender) client-ip=xxx;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates my:ipv6:address as permitted sender) [email protected];
       dkim=pass [email protected];
       dmarc=fail (p=NONE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mywebserver.com; s=mydkim;
    h=Date:Message-Id:Sender:From:Subject:To; bh=w2snQznwxlVRVACmfQELC7VGmD1dcYdiCXbCIRYFKRs=;
    b=a0Vy3Ky43J5FdiWSuQ4qvTTH47G+Js0W/qtRU5gMlxfesNqrlyaIyExaIZlWvHNL4o0LNOF1GI94w4C41mmH+2JIkMEQZazw0MainP7UyUgsm/RZbAWoRuecPv+k108FlsWMP/l1UttXAdlvBVJmV2UGsYYlSSjKErQEF8tv3K0=;
Received: from apache by mywebserver.com with local (Exim 4.80)
    (envelope-from <[email protected]>)
    id 1aQWVF-00009b-2X
    for [email protected]; Tue, 02 Feb 2016 09:40:01 +0100
To: [email protected]
From: Website User <[email protected]>
Sender: [email protected]
...

Beachten Sie, dass sowohl die SPF- als auch die DKIM-Prüfung bestanden werden, die DMARC-Prüfung jedoch nicht. Nach einigem Suchen habe ich dies anhand der From:Adresse, von der die Referenzdomäne abgerufen wurde, bis zu DMARC aufgespürt. Dies geht aus dieser Antwort beim Stapelüberlauf hervor .

Drei Fragen:

  1. Ist es wahrscheinlich, dass dies tatsächlich die dmarc=failUrsache dafür ist, dass die E-Mail von Google Mail Spam zugewiesen wird?
  2. Warum arbeitet DMARC mit der From:Adresse und nicht mit dem Return-Path(Umschlagsender) wie SPF und DKIM?
  3. Wenn nun auch der From:Header einer Adresse entsprechen muss, @mydomain.comwie sollen wir dann den tatsächlichen (logischen, Fleisch- und Blut-) Absender der Nachricht angeben ?
email smtp email-server gmail dmarc EelkeSpaak
quelle

Antworten:

7

Stellen Sie sich SPF und DKIM als Möglichkeiten zur Überprüfung des E-Mail-Pfads vor und DMARC als Erweiterung, die auch den Absender der Nachricht überprüft. Stellen Sie sich das als Zustellung eines FedEx-Briefes vor. Es ist leicht zu überprüfen, woher der Umschlag verschickt wurde und ob der Kurier legitim war, aber es bietet keine Möglichkeit zu beweisen, dass der Brief im Umschlag wirklich von der Person stammt, deren Name darauf gedruckt ist.

Ihr Webserver ist ein gültiger SMTP-Server für mywebserver.com und Ihre Absenderadresse ist legitim. Dies reicht jedoch nicht aus, damit andere Server darauf vertrauen können, dass Sie die Berechtigung zum Senden als [email protected] haben. Woher weiß GMail, dass Ihr Server nicht gehackt oder anderweitig für böswillige Absichten verwendet wurde? Die Server von Google Mail werden Ihnen nicht blind vertrauen, dass Sie E-Mails als einer ihrer Benutzer senden - es sei denn, Sie werden von ihnen gehostet, und dann hätten Sie wahrscheinlich Probleme beim Senden an Yahoo.

Um Ihren ersten Teil der Frage zu beantworten: Ja, es ist sehr wahrscheinlich, dass GMail dies aus diesem Grund als Spam einstuft. Bei den ältesten Formen von Spam geht es darum, die "Von" -Adresse zu fälschen. Dies sehen die meisten Benutzer, wenn sie eine Nachricht erhalten, und dies ist das primäre Feld, dem sie vertrauen möchten. Wenn eine Nachricht von einem legitimen Mailserver mit einer Absenderadresse gesendet wird, die nicht zu diesem Mailserver gehört, ist dies immer noch eine rote Fahne.

Wie Sie bereits erwähnt haben, verarbeitet DMARC die Absenderadresse als Teil der Spezifikation. Zugegeben, es macht es schwieriger, Web-Apps zu schreiben, die für jemanden gesendet werden, aber genau darum geht es. In Bezug auf , warum sie es tun - na ja, das ist die Designer der Spezifikation, aber es ist ein Kompromiss. Sie nehmen die Hauptstraße und schaffen ein System, das sehr gut funktioniert, wenn Sie innerhalb dieser Grenze bleiben. Vielleicht finden zukünftige Mechanismen einen Weg, dies zu umgehen.

Die unglückliche Lösung besteht darin, nur Adressen zu verwenden, über die Sie die Kontrolle haben. Um Ihre dritte Frage zu beantworten, unterschreiben Sie Ihre Nachrichten mit Ihrem Domain-Namen und geben Sie im Text an, dass sie im Auftrag von [email protected] gesendet wurden. Andernfalls müssen Sie Ihre Empfänger auffordern, die Adresse zu ihrer Whitelist hinzuzufügen. Für einen legitimen Web-App-Entwickler macht es nicht viel Spaß, aber es schützt die Heiligkeit des Posteingangs des Empfängers. Möglicherweise haben Sie Glück, wenn Sie den Header "Antworten an" mit der E-Mail-Adresse des Webbenutzers verwenden.

Diese Einschränkung wird in diesem DMARC-Thread diskutiert .

In der Zwischenzeit können Sie versuchen, sicherzustellen, dass Ihr Server in keiner RBL auf der schwarzen Liste steht. Es könnte sein, dass Sie DMARC nicht bestehen können, aber dennoch einige Spam-Filter durchlaufen, wenn Sie einen guten Ruf haben ... aber ich würde mich nicht darauf verlassen.

GuitarPicker
quelle
2

1) Ja, wahrscheinlich führt der Fehler von dmarc dazu, dass Google Mail Ihre E-Mails verschmutzt

2) wäre auch an einer Antwort darauf interessiert

3) Ich würde (und wir tun es) das Antwortfeld für die Kundenadresse verwenden. Unsere Mails sehen folgendermaßen aus:

von: [email protected]

an: [email protected]

Betreff: Kontaktformular

Antwort an: [email protected]

Hoffe das hilft

lukester85
quelle
0

Es gibt zwei "Warum" -Fragen:

  1. Warum führt ein empfangender Mailserver die Prüfung auf diese Weise durch?
  2. Warum wurde DMARC so konzipiert?
    • weil die Leute, die es entworfen haben, anscheinend Abschnitt 3.6.2 von RFC 5322 nicht gelesen oder falsch interpretiert oder ignoriert haben.

In diesem Abschnitt wird eindeutig festgelegt, dass ein Sender:Header, sofern vorhanden, Vorrang vor einem From:Header hat, um die für das Senden einer Nachricht verantwortliche Partei zu identifizieren:

Das Feld "Absender:" gibt das Postfach des Agenten an, der für die tatsächliche Übertragung der Nachricht verantwortlich ist. Wenn eine Sekretärin beispielsweise eine Nachricht für eine andere Person senden würde, würde das Postfach der Sekretärin im Feld "Absender:" und das Postfach des tatsächlichen Autors im Feld "Von:" angezeigt. Wenn der Absender der Nachricht durch ein einzelnes Postfach angegeben werden kann und Autor und Sender identisch sind, darf das Feld "Absender:" NICHT verwendet werden. Andernfalls MÜSSEN beide Felder angezeigt werden.

Vergleichen Sie dies mit der Begründung in RFC 7489 :

DMARC authentifiziert die Verwendung der RFC5322.From- Domäne, indem verlangt wird, dass sie mit einer authentifizierten Kennung übereinstimmt (mit dieser ausgerichtet ist). Die Domäne RFC5322.From wurde als zentrale Identität des DMARC-Mechanismus ausgewählt, da es sich um ein erforderliches Nachrichtenkopffeld handelt und daher garantiert in kompatiblen Nachrichten vorhanden ist. Die meisten Mail User Agents (MUAs) repräsentieren das Feld RFC5322.From als Urheber der Nachricht und rendern einige oder den gesamten Inhalt dieses Headerfelds an Endbenutzer.

Ich behaupte, dass diese Logik fehlerhaft ist, da RFC 5322 diesen Fehler explizit ausruft:

Hinweis: Die Senderinformationen sind immer vorhanden. Das Fehlen des Felds "Absender:" bedeutet manchmal fälschlicherweise, dass der für die Übertragung der Nachricht verantwortliche Agent nicht angegeben wurde. Diese Abwesenheit bedeutet lediglich, dass der Sender mit dem Autor identisch ist und daher nicht redundant in das Feld "Absender:" eingefügt wird.

Ich glaube, dass DMARC von Natur aus kaputt ist, weil

  • es bringt die Autorität zum Senden und den Nachweis der Urheberschaft zusammen ;
  • es interpretiert frühere RFCs falsch und
  • Dabei wird jeder zuvor kompatible Listenserver, der sich selbst identifiziert hat, durch Hinzufügen eines eigenen Sender:Headers unterbrochen .

Wenn ein Sender:Feld vorhanden ist, sollte DMARC sagen, dass dieses Feld authentifiziert und das Feld ignoriert From:werden soll. Aber das steht nicht darin, und deshalb halte ich es für kaputt.

RFC 7489 fährt fort:

Daher wird dieses Feld von Endbenutzern verwendet, um die Quelle der Nachricht zu identifizieren, und ist daher ein Hauptziel für Missbrauch.

Dies ist einfach falsch (im Zusammenhang mit der Rechtfertigung, den Sender:Header zu ignorieren ). Zum Zeitpunkt der Entwicklung von DMARC zeigten gängige E-Mail-Clients routinemäßig eine Kombination aus Informationen Sender:und From:Feldern an, z. B. From name-for-mailing-list @ server im Auftrag von [email protected] . So war dem Benutzer immer klar, wer für das Senden der Nachricht verantwortlich war, die er sich ansah.

Vorschläge, Reply-To:die einen angemessenen Ersatz darstellen, sind ebenfalls fehlerhaft, da dieser Header häufig als "zusätzlicher Empfänger" und nicht als "Ersatzempfänger" falsch interpretiert wird und das Ersetzen des ursprünglichen Absenders Reply-To:die Funktionalität für diese Benutzer beeinträchtigen würde .

Martin
quelle