L'enregistrement SPF Office365 comporte trop de recherches

Pour des raisons administratives tout à fait ridicules, nous avons un domaine divisé avec une boîte aux lettres sur Office365 qui nous oblige à ajouter include:outlook.comà notre enregistrement SPF. Le problème est que cette règle à elle seule nécessite neuf recherches DNS sur un maximum de 10.

Sérieusement, c'est horrible. Regardez-le:

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

Étant donné que nous avons notre propre système de messagerie grand-ish nous avons besoin d'avoir des règles pour a, mx, include:_spf1.mydomain.comet include:_spf2.mydomain.comqui nous met à 13 recherches DNS qui cause PERMERRORs avec validateurs strictes SPF et validation totalement fiable / imprévisible non stricte / validateurs mal mis en œuvre .

Est-il possible d'éliminer d'une manière ou d'une autre 3 de ces include:règles de l'enregistrement Outlook.com gonflé, mais de couvrir toujours les serveurs utilisés par O365?

Éditer:

Les commentateurs ont mentionné que nous devrions simplement utiliser l' spf.protection.outlook.comenregistrement le plus court . Bien que ce soit nouveau pour moi, et qu'il soit plus court, ce n'est qu'un enregistrement de moins:

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

Modifier²

Je suppose que nous pouvons techniquement réduire cela à:

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

mais les problèmes potentiels que je vois avec ceci sont:

Nous devons nous tenir au courant de toute modification apportée au parent spf.protection.outlook.comet aux spf.messaging.microsoft.comenregistrements. Si quelque chose est changé ou [Dieu nous en préserve] ajouté, nous devrons mettre à jour manuellement le nôtre pour refléter cela.
Avec notre nom de domaine réel, la longueur de l'enregistrement est de 260 caractères, ce qui nécessiterait 2 chaînes pour l'enregistrement TXT, et je n'ai honnêtement pas confiance que tous les clients DNS et les résolveurs SPF acceptent correctement un enregistrement TXT de plus de 255 octets. .

email spf microsoft-office-365

— Sammitch
source

Ne pouvez-vous pas simplement ajouter spf.protection.outlook.com pour l'ensemble d'Office365? technet.microsoft.com/en-us/library/hh852557.aspx

— Cold T

Pourquoi l'enregistrement SPF pour O365 n'est-il pas simple? include:spf.protection.outlook.com (curieux pour être honnête, jamais vu ce que vous avez configuré ... le portail vous a-t-il dit de mettre tout cela?)

— TheCleaner

Toute la documentation que j'ai trouvée était censée être utilisée include:outlook.com, les spf.protection.outlook.comnouvelles sont donc pour moi. Le problème demeure cependant, car cet enregistrement nécessite toujours 8 recherches, et je dois le réduire à 6 ou moins.

— Sammitch

N'oubliez pas de compter les deux recherches PTR sous 'spfa.frontbridge.com'. Selon la RFC 7208, elles comptent également dans la limite de 10 recherches. :(

— Martijn Heemels

Réponses:

À une date récente, Microsoft a «résolu» ce problème en supprimant tous les sous-enregistrements et en utilisant à la place 2 ou 3 enregistrements «ptr»:

$ 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"

Voici le problème: bien que cela aide les clients Office 365 à éviter de rester en dessous du PermError "Trop de recherches" ... il le fait en forçant tous les serveurs de messagerie du monde à effectuer des recherches PTR (coûteuses) pour chaque adresse IP qui se connecte à eux.

Selon la spécification SPF :

Dans la mesure du possible, vous devez éviter d'utiliser ce mécanisme dans votre enregistrement SPF, car cela entraînera un plus grand nombre de recherches DNS coûteuses.

— John Hart
source

@ChrisS - J'y ai pensé aussi, mais la spécification SPF stipule que le mécanisme "ptr:" doit être vérifié dans les deux sens pour le DNS réciproque - le serveur de messagerie destinataire doit d'abord faire un PTR sur l'IP, puis faire un A sur le nom d'hôte résultant et l'adresse IP doivent être répertoriés dans l'enregistrement A. Je ne pense donc pas que ce soit une faille de sécurité, du moins pas pour les implémentations SPF conformes.

— John Hart

Ah, bonne trouvaille là-bas. Je n'étais pas au courant de la mise en garde.

— Chris S

Nous avons également trouvé ce problème. Microsoft vous `` encourage '' à utiliser Office 365 exclusivement pour votre courrier électronique car il n'y a plus de place maintenant pour ajouter de nouveaux éléments.

La façon dont nous nous sommes déplacés était double.

Tout d'abord, nous pouvons réduire les recherches DNS en ajoutant les autres entrées en tant qu'entrées IPv4 explicites. Cela nous permet d'ajouter un certain nombre d'adresses IP explicites avant deinclude:outlook.com

Deuxièmement, nous avons configuré un sous-domaine distinct sous notre domaine principal pour les éléments Office 365. De cette façon, les e-mails @ foo.company.com obtiennent le SPF Office 365 et les e-mails @ comapny.com obtiennent notre SPF normal. Ce n'est pas parfait, mais heureusement, les endroits où nous avons utilisé Office 365 sont tous capables d'utiliser des adresses e-mail dans le sous-domaine plutôt que dans le domaine de base.

— Steve Shipway
source