Rekord SPF Office365 ma zbyt wiele wyszukiwań

Z bardzo absurdalnych powodów administracyjnych mamy podzieloną domenę z jedną skrzynką pocztową na Office365, która wymaga dodania include:outlook.comdo naszego rekordu SPF. Problem polega na tym, że sama reguła wymaga dziewięciu wyszukiwań DNS z maksymalnie 10.

Poważnie, to okropne. Spójrz na to:

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

Biorąc pod uwagę, że mamy własny duży-owski system poczty musimy mieć zasady a, mx, include:_spf1.mydomain.com, i include:_spf2.mydomain.comktóry stawia nas w wyszukiwań 13 DNS, który powoduje PERMERRORs ścisłych walidatorami SPF i całkowicie niewiarygodne / nieprzewidywalna walidacji z nie-ścisłych / źle realizowanych walidatorami .

Czy można w jakiś sposób wyeliminować 3 z tych include:reguł z rozdętego rekordu outlook.com, ale nadal obejmować serwery używane przez O365?

Edytować:

Komentatorzy wspomnieli, że powinniśmy po prostu użyć krótszego spf.protection.outlook.comzapisu. Mimo, że to dla mnie nowość, a to jest krótszy, to tylko jeden rekord krócej:

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

Edytuj²

Przypuszczam, że możemy technicznie sprowadzić to do:

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

ale potencjalne problemy z tym związane to:

Musimy być na bieżąco z wszelkimi zmianami w rodzicu spf.protection.outlook.comi spf.messaging.microsoft.comdokumentacji. Jeśli cokolwiek zostanie zmienione lub dodane [nie daj Boże], będziemy musieli ręcznie zaktualizować nasze, aby to odzwierciedlić.
Przy naszej rzeczywistej nazwie domeny długość rekordu wynosi 260 znaków, co wymagałoby 2 ciągów dla rekordu TXT, i szczerze mówiąc, nie ufam, że wszyscy klienci DNS i resolwery SPF poprawnie przyjmą rekord TXT dłuższy niż 255 bajtów .

email spf microsoft-office-365

— Sammitch
źródło

Czy nie możesz po prostu dodać spf.protection.outlook.com dla wszystkich Office365? technet.microsoft.com/en-us/library/hh852557.aspx

— Cold T

Dlaczego rekord SPF dla O365 nie jest prosty? include:spf.protection.outlook.com (ciekawi, szczerze mówiąc, nigdy nie widziałem, co skonfigurowałeś ... czy portal kazał ci to wszystko umieścić?)

— TheCleaner

Cała dokumentacja, o której istnieniu mówiłem, że ma być używana include:outlook.com, więc spf.protection.outlook.comsą dla mnie wiadomości. Problem jednak pozostaje, ponieważ ten rekord wciąż wymaga 8 odnośników i muszę go zmniejszyć do 6 lub niżej.

— Sammitch,

Nie zapomnij policzyć dwóch wyszukiwań PTR w „spfa.frontbridge.com”. Zgodnie z RFC 7208 liczą się one również do limitu 10 wyszukiwań. :(

— Martijn Heemels,

Odpowiedzi:

Od niedawnej daty Microsoft „naprawił” ten problem, pozbywając się wszystkich pod-rekordów i stosując zamiast tego 2 lub 3 rekordy „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"

Oto problem: chociaż pomoże to klientom Office 365 uniknąć pozostawania poniżej Permerror „Zbyt wielu wyszukiwań” ... robi to, zmuszając każdy serwer pocztowy na świecie do (drogich) wyszukiwania PTR dla każdego adresu IP, który się z nimi łączy.

Zgodnie ze specyfikacją SPF :

Jeśli to w ogóle możliwe, należy unikać używania tego mechanizmu w rekordzie SPF, ponieważ spowoduje to większą liczbę kosztownych wyszukiwań DNS.

— John Hart
źródło

@ChrisS - Też o tym myślałem, jednak specyfikacja SPF stwierdza, że mechanizm „ptr:” musi zostać zweryfikowany w obie strony dla wzajemnego DNS - serwer poczty odbierającej powinien najpierw wykonać PTR dla adresu IP, a następnie zrobić A na wynikowa nazwa hosta i adres IP muszą być wymienione w rekordzie A. Więc nie sądzę, że jest to dziura w zabezpieczeniach, przynajmniej nie dla zgodnych implementacji SPF.

— John Hart,

Ach, dobre znalezisko. Nie wiedziałem o zastrzeżeniu.

— Chris S

Znaleźliśmy również ten problem. Microsoft „zachęca” Cię do korzystania z Office 365 wyłącznie do obsługi poczty e-mail, ponieważ nie ma już miejsca na dodawanie nowych elementów.

Sposób, w jaki udało nam się to obejść był dwojaki.

Po pierwsze, możemy ograniczyć wyszukiwanie DNS, dodając inne wpisy jako jawne wpisy IPv4. To pozwala nam dodać kilka wyraźnych adresów IP przed namiinclude:outlook.com

Po drugie, skonfigurowaliśmy osobną subdomenę w naszej głównej domenie dla Office 365. W ten sposób e-maile @ foo.company.com otrzymują SPF Office 365, a e-maile @ comapny.com otrzymują nasz normalny SPF. To nie jest idealne, ale na szczęście miejsca, w których korzystaliśmy z Office 365, mogą używać adresów e-mail w subdomenie, a nie w domenie podstawowej.

— Steve Shipway
źródło