Der Office365 SPF-Datensatz enthält zu viele Suchvorgänge

Aus einigen äußerst lächerlichen administrativen Gründen haben wir eine geteilte Domain mit einem Postfach in Office365, die es erforderlich macht, dass wir include:outlook.comunseren SPF-Datensatz ergänzen . Das Problem dabei ist, dass allein diese Regel neun DNS-Lookups von maximal 10 erfordert .

Im Ernst, es ist schrecklich. Schau es dir an:

v=spf1
include:spf-a.outlook.com
include:spf-b.outlook.com
ip4:157.55.9.128/25
include:spfa.bigfish.com
include:spfb.bigfish.com
include:spfc.bigfish.com
include:spf-a.hotmail.com
include:_spf-ssg-b.microsoft.com
include:_spf-ssg-c.microsoft.com
~all

Da wir unser eigenes großes ish - Mail - System haben wir brauchen für Regeln haben a, mx, include:_spf1.mydomain.com, und include:_spf2.mydomain.comdie uns Puts auf 13 DNS - Lookups der Ursachen PERMERRORs mit strengen SPF Validierer und völlig unzuverlässig / unberechenbar Validierung mit nicht-streng / schlecht umgesetzt Validatoren .

Ist es möglich, drei dieser include:Regeln aus dem aufgeblähten Outlook.com-Datensatz zu entfernen, aber dennoch die von O365 verwendeten Server abzudecken?

Bearbeiten:

Kommentatoren haben erwähnt, dass wir einfach den kürzeren spf.protection.outlook.comDatensatz verwenden sollten. Während das ist neu für mich, und es ist kürzer, dann ist es nur ein Datensatz kürzer:

spf.protection.outlook.com
  include:spf-a.outlook.com
  include:spf-b.outlook.com
  include:spf-c.outlook.com
  include:spf.messaging.microsoft.com
    include:spfa.frontbridge.com
    include:spfb.frontbridge.com
    include:spfc.frontbridge.com

Edit²

Ich nehme an, wir können dies technisch auf Folgendes reduzieren:

v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all

Aber die möglichen Probleme, die ich dabei sehe, sind:

Wir müssen uns über Änderungen an den Eltern spf.protection.outlook.comund spf.messaging.microsoft.comAufzeichnungen auf dem Laufenden halten . Wenn etwas geändert oder [Gott bewahre] hinzugefügt wird, müssten wir unsere manuell aktualisieren, um dies widerzuspiegeln.
Bei unserem tatsächlichen Domainnamen beträgt die Länge des Datensatzes 260 Zeichen, was 2 Zeichenfolgen für den TXT-Eintrag erfordern würde, und ich vertraue ehrlich gesagt nicht darauf, dass alle DNS-Clients und SPF-Resolver einen TXT-Eintrag mit mehr als 255 Byte ordnungsgemäß akzeptieren .

email spf microsoft-office-365

— Sammitch
quelle

Können Sie nicht einfach spf.protection.outlook.com für Office365 hinzufügen? technet.microsoft.com/en-us/library/hh852557.aspx

— Cold T

Warum ist der SPF-Datensatz für O365 nicht der einfache aktuelle? include:spf.protection.outlook.com (Neugierig, um ehrlich zu sein, noch nie gesehen, was Sie eingerichtet haben ... hat Ihnen das Portal gesagt, dass Sie all das setzen sollen?)

— TheCleaner

Alle Dokumentationen, die ich gefunden habe, sollen verwendet werden include:outlook.com, und das spf.protection.outlook.comsind Neuigkeiten für mich. Das Problem bleibt jedoch bestehen, da für diesen Datensatz immer noch 8 Suchvorgänge erforderlich sind und ich ihn auf 6 oder weniger reduzieren muss.

— Sammitch

Vergessen Sie nicht, die beiden PTR-Lookups unter 'spfa.frontbridge.com' zu zählen. Laut RFC 7208 zählen sie auch zum Limit von 10 Lookups. :(

— Martijn Heemels

Antworten:

Seit einiger Zeit hat Microsoft dieses Problem "behoben", indem alle Unterdatensätze entfernt und stattdessen 2 oder 3 "ptr" -Datensätze verwendet wurden:

$ dig TXT spf.protection.outlook.com
spf.protection.outlook.com. IN  TXT "v=spf1 ptr:protection.outlook.com ptr:o365filtering.com -all"

$ dig TXT spf.messaging.microsoft.com
spf.messaging.microsoft.com. IN TXT "v=spf1 ptr:protection.outlook.com ptr:messaging.microsoft.com ptr:o365filtering.com -all"

Hier ist das Problem: Dies hilft Office 365-Clients zwar dabei, zu vermeiden, dass der PermError "Zu viele Suchvorgänge" unterschritten wird, indem jedoch jeder Mailserver auf der Welt gezwungen wird, (teure) PTR-Suchvorgänge für jede IP-Adresse durchzuführen, die eine Verbindung zu ihnen herstellt.

Gemäß SPF-Spezifikation :

Wenn möglich, sollten Sie die Verwendung dieses Mechanismus in Ihrem SPF-Eintrag vermeiden, da dies zu einer größeren Anzahl teurer DNS-Suchvorgänge führt.

— John Hart
quelle

@ChrisS - Ich habe auch darüber nachgedacht, aber die SPF-Spezifikation besagt, dass der "ptr:" - Mechanismus für wechselseitiges DNS in beide Richtungen überprüft werden muss - der empfangende Mailserver sollte zuerst eine PTR auf der IP und dann eine A auf durchführen Der resultierende Hostname und die IP müssen im A-Datensatz aufgeführt sein. Ich denke also nicht, dass es eine Sicherheitslücke ist, zumindest nicht für die Anpassung von SPF-Implementierungen.

— John Hart

Ah, guter Fund dort. Ich war mir der Einschränkung nicht bewusst.

— Chris S

Wir haben auch dieses Problem gefunden. Microsoft empfiehlt Ihnen, Office 365 ausschließlich für Ihre E-Mails zu verwenden, da derzeit kein Platz mehr zum Hinzufügen neuer Elemente vorhanden ist.

Wir haben uns in zweifacher Hinsicht darum gekümmert.

Erstens können wir DNS-Lookups reduzieren, indem wir die anderen Einträge als explizite IPv4-Einträge hinzufügen. Auf diese Weise können wir eine Reihe expliziter IPs hinzufügen, bevor wirinclude:outlook.com

Zweitens haben wir unter unserer Hauptdomäne eine separate Unterdomäne für das Office 365-Material eingerichtet. Auf diese Weise erhalten E-Mails @ foo.company.com den Office 365-SPF und E-Mails @ comapny.com unseren normalen SPF. Es ist nicht perfekt, aber glücklicherweise können alle Orte, an denen wir Office 365 verwendet haben, E-Mail-Adressen innerhalb der Subdomain anstelle der Basisdomäne verwenden.

— Steve Shipway
quelle