Ist ein Umschreiben von SRS für einen weiterleitenden Mailserver unbedingt erforderlich?

Ich betreibe einen Postfix-E-Mail-Server für meine Domain, beispielsweise mydomain.com. Meist handelt es sich dabei um einen Weiterleitungs-E-Mail-Server: Benutzer erhalten eine E-Mail-Adresse @ mydomain.com, wählen jedoch in der Regel die Weiterleitung ihrer Adresse an einen externen Posteingang (Google Mail, Yahoo, usw.). Es werden einige Tausend Adressen weitergeleitet, sodass der Server ein relativ hohes E-Mail-Verkehrsaufkommen bewältigt.

In der Vergangenheit verwendete der Server keine SRS-Umschreibung. Dies bedeutete natürlich, dass weitergeleitete E-Mails die SPF-Überprüfungen nicht bestehen, da meine IP-Adresse technisch nicht berechtigt ist, E-Mails im Namen der Domain des ursprünglichen Absenders zu senden. Soweit ich sehen kann, scheint dies jedoch keine wesentlichen Probleme zu verursachen. Im Allgemeinen scheinen keine Beschwerden von Nutzern wie Google Mail, Yahoo usw. klug genug zu sein, um die SPF-Fehler zu ignorieren und die Nachrichten trotzdem zuzustellen.

Ist es in diesem Sinne wirklich erforderlich, das Umschreiben von SRS zu aktivieren? Ich denke darüber nach, es zu aktivieren, aber meine Hauptsorge ist, dass meine Domain für das Versenden von Spam auf die schwarze Liste gesetzt wird, wenn Spam unvermeidlich weitergeleitet wird. Würde das Umschreiben nicht den Anschein erwecken, als wäre ich der Urheber des Spam? (Zumindest ist dies mein Verständnis aus dem Lesen von Gmail's Best Practices zum Weiterleiten von Mailservern ).

Zugegeben, ich treffe bereits einige der empfohlenen Vorsichtsmaßnahmen, z. B. die Verwendung von SpamAssassin zum Hinzufügen von "SPAM" zur Betreffzeile von vermutetem Spam, bevor ich Spam mit hoher Vertrauenswürdigkeit (Punktzahl 15+) und mit der Spamhaus-Blockliste weitergebe nicht perfekt und Spam kann trotzdem unmarkiert durchrutschen.

Lohnt es sich, das SRS-Umschreiben zu aktivieren, wenn es das Risiko erhöht, als Spammer falsch gekennzeichnet zu werden? Oder wäre es sicherer, es einfach so zu belassen und SPF-Fehler zu ignorieren?

postfix spam spamassassin

— tlng05
quelle

Ich weiß aus Erfahrung, dass einige ISPs in Großbritannien eingehende E-Mails ablehnen, die angeblich von ihren eigenen Kunden stammen, die jedoch nicht von ihren eigenen Mailern gesendet wurden. Gleiches gilt möglicherweise auch für Google Mail, Yahoo und AOL. Solche Situationen können nur durch Umschreiben der Absenderadresse gelöst werden.

— Roaima

Antworten:

Mir scheint, Ihre Frage lautet: " Wie viele Mailserver prüfen SPF-Einträge auf eingehende E-Mails? ". Wenn es die meisten sind, ist SRS eine absolute Voraussetzung für einen Weiterleitungsserver. Wenn es keiner von ihnen ist, brauchen Sie kein SRS.

Leider kann ich hier keine akademische Arbeit sofort in die Hände bekommen. Aber da ich SPF auf eingehende E-Mails überprüfe, kann ich mit Sicherheit sagen, dass einige Mailserver dies überprüfen. Jeder Ihrer Kunden, bei dem Ihr Server an Konten auf meinem Server weitergeleitet wird, verliert E-Mails von Absendern, die für einen SPF werben, der endet (wie sie alle sollten) -all, es sei denn, Sie verwenden SRS. Daher kann ich mit Sicherheit sagen, dass einige der E-Mails Ihrer Kunden ohne SRS nicht zugestellt werden .

Ich entschuldige mich bei Marc, dass ich kein Deutsch lesen kann. Ich kann also nicht sagen, ob das PDF, das er zitiert, überzeugende Argumente enthält, aber ich kann wiederholen, dass ohne SRS ein Teil der E-Mails Ihrer Kunden nicht zugestellt wird. Ich kann nicht sagen, was dieser Bruchteil ist, aber er ist nicht Null - und ich denke, Sie haben keine andere Alternative, als SRS zu betreiben.

Ich bin damit einverstanden, dass Ihr Server sich nicht selbst hilft, indem er SPAM weiterleitet, aber meiner Erfahrung nach wird der größte Teil des Reputationsschadens an seiner IP-Adresse und nicht an der Umschlag-From-Domain verursacht. Dies erfolgt unabhängig von der SRS-Nutzung.

Die tiefere Antwort auf Ihre Frage ist, dass zwischen SPF und seinem (unüberlegten und das Internet unterbrechenden) Follow-up DMARC meiner Meinung nach die Postweiterleitungsdienste ausgedient haben. Ich habe bereits verlangt, dass alle bis auf einen meiner Benutzer die endgültige Zustellung auf meinem Server haben. Dieser eine Benutzer muss 2016 geändert oder verlassen werden. Heutzutage ermöglichen viele Webmail-Systeme die Integration über mehrere Postfächer, indem er E-Mails außerhalb des Servers mithilfe von sammelt IMAP oder POP und viele E-Mail-Clients ermöglichen die Darstellung mehrerer IMAP- oder POP-Konten als eine integrierte INBOX. Die Weiterleitung ist also nicht mehr der Segen für das früher übliche zentrale Lesen.

Kurz gesagt, ich würde sagen, Sie brauchen kurzfristig SRS und langfristig ein neues Geschäftsmodell.

— MadHatter
quelle

Die Sache ist, dass SRS eine Lösung ist, um Weiterleitungsprobleme von SPF zu beheben. SRS schreibt zB Benutzer @ A auf A = Benutzer @ B und die SPF-Datensätze von B sind dann verantwortlich. Problem: B kann noch Adressen fälschen! Daher fügen einige der umgeschriebenen Adresse Krypta-Hashes und Zeitstempel hinzu. Damit dies in großem Maßstab funktioniert, ist eine globale Akzeptanz erforderlich, die es nicht gibt. Es funktioniert auch nur, wenn etwas einmal weitergeleitet wird, aber nicht mehr. Auch Antworten sind ein Problem. Denken Sie auch daran, dass SPF eine Technik zum Schutz Ihrer eigenen Missbrauchsdomäne ist, mehr nicht.

— Marc Stürmer

@ MarcStürmer " SRS ist eine Lösung zur Behebung von Weiterleitungsproblemen von SPF ": ja, genau das ist es. SPF ist dafür bekannt, die vereinfachte Weiterleitung zu unterbrechen. Wenn Sie nicht glauben, dass SRS einen Preis wert ist, machen Sie keine Werbung für einen SPF-Datensatz. " Problem: B kann noch Adressen fälschen ": Nicht zu A's Domain oder einer anderen Domain, die durch einen anständigen SPF- Eintrag geschützt ist, oder die Mail wird unter SPF abgelehnt; aber anders als das, ja, es kann und ich sehe es nicht als ein Problem. " SPF ist eine Technik zum Schutz Ihrer eigenen Missbrauchsdomäne, mehr nicht ": Ich stimme zu.

— MadHatter

@ MarcStürmer: "Es funktioniert auch nur, wenn etwas einmal weitergeleitet wird, aber nicht mehr." ist falsch. SRS funktioniert über mehrere Weiterleitungsserver einwandfrei. Es leidet nur, wenn sich ein Server in der Leitung befindet, der nicht mit Tags versehen ist. Dies ist jedoch das gleiche Problem wie bei allen anderen Servern ohne Tag, sei es ein erster oder ein späterer Forward-Hop. In einer SPF-Welt benötigen Sie kein SRS. Sie müssen lediglich die Verantwortung für die weitergeleitete Mail übernehmen und sicherstellen, dass Sie einen möglichen Bounce-Back zustellen können. SRS ist nur eine Technik, die dies tut, google benutzt zB etwas anderes.

— Adrian Zaugg

Das Problem ist, dass die Verwendung von SRS die DMARC-Ausrichtungsprüfung (dh Briefumschlagsender! = From:-Header) unterbricht und Google Mail dazu veranlasst, Nachrichten abzulehnen, wenn die Domain im From:Header die p=rejectDMARC-Richtlinie enthält. Wenn Sie das ebenfalls umschreiben From:, wird die E-Mail nach den Regeln Ihrer eigenen Domain geprüft. Eine DKIM-Prüfung schlägt jedoch fehl und der im Mail-Client angezeigte Absender wird entstellt.

— Geburt

@mbirth afaik, du hast recht. Ich persönlich betrachte DMARC jedoch als eine völlige Katastrophe, nicht zuletzt, weil es Mailinglisten einseitig zerstört hat, und (in meiner Eigenschaft als Administrator einer großen Community-Liste) rate ich einfach von der Verwendung eines ISP ab, der eine veröffentlichtp=reject Richtlinie veröffentlicht. Wenn SRS DMARC bricht, ist das für DMARC einfach schwierig.

— MadHatter

SRS scheint auf dem Papier eine gute Idee zu sein, funktioniert aber in der Praxis nach Angaben des Heinlein-Supports nicht sehr gut (sie betreiben einen mittelgroßen Mail-Service mit über 100000 Konten.)

Details sind in ihrem Vortrag, wenn auch auf Deutsch, warum: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

Der Hauptgrund ist, dass SRS ein kleiner Patch für schwerwiegende Probleme bei der Implementierung von SPF in der Realität ist, da SPF einige gängige E-Mail-Anwendungsfälle nicht sehr gut abdeckt. Damit SRS sinnvoll ist, muss es auf einer großen Anzahl von Servern bereitgestellt werden, was jedoch unwahrscheinlich ist. Solange es nicht auf dieser großen Anzahl von Servern bereitgestellt wird, ergibt es überhaupt keinen Sinn.

Das Problem bei den großen Mail-Providern ist jedoch, dass sie heutzutage eine wirklich große Anwenderbasis haben und immer mehr Techniken implementieren (der Nachfolger von DMARC ist bereits in der Pipeline), was es für einen Normalen immer schwieriger macht Mail-Server-Setup zum zuverlässigen Versenden von E-Mails.

Wenn Sie möchten, dass Ihre E-Mails besser an große E-Mail-Anbieter wie Google Mail, Hotmail usw. gesendet werden, sollten Sie mindestens DKIM und DMARC implementieren, sie jedoch bestenfalls auf "soft fail" einstellen und möglicherweise einige Mechanismen zur Geschwindigkeitsbegrenzung für die E-Mail-Zustellung implementieren würde Wunder für dich wirken.

Dieses Problem bei den großen Anbietern ist der Grund, warum es heutzutage Dienste wie Mailchimp, Mandrill oder Returnpath gibt. Diese Anbieter zahlen Geld an Google & Co. für eine bessere Zustellqualität.

— Marc Stürmer
quelle

Das Problem ist hier SPF nicht SRS. Solange einige ISP SPF verwenden, müssen Sie SRS (oder etwas Ähnliches) implementieren, damit die Weiterleitung mit allen von ihnen funktioniert. Das Problem mit dem Greylisting ist anders. Sie sollten SRS-markierte Absenderadressen für das Greylisting "entpacken" (sowie BATV-markierte E-Mails).

— Adrian Zaugg

Ich bin mit jedem Wort von @MadHatter einverstanden, ABER wichtige Tatsache über Google!

Wenn Sie einen Weiterleitungsdienst für Google Mail bereitstellen, besteht eine gute Chance, dass Sie auch SMTP-Zugriff bereitstellen, sodass Ihre Google Mail-Benutzer E-Mails von Google Mail im Namen der von Ihnen gespeicherten Adresse senden können.

In diesem Fall weiß Google Mail, dass Sie eine Weiterleitung für diese E-Mail sind, und kennzeichnet Ihre Weiterleitungen nicht als Spam, obwohl die SPF-Prüfung fehlgeschlagen ist.

Sie können Ihren Kunden E-Mails von bill@microsoft.com senden. Die Nachricht kommt ohne Vorwarnung in ihren Posteingang! (Microsoft hat -all im SPF-Datensatz)

Geprüft und verifiziert. Beispiel beigefügt.

Diese Nachricht ging in den Posteingang.

— yeya
quelle