Obejścia dotyczące maksymalnego limitu warunków interaktywnych DNS przekroczone w rekordzie SPF?

16

Jako dostawca usług hostingowych wysyłamy wiadomości e-mail w imieniu naszych klientów, dlatego pomagamy im skonfigurować rekordy wiadomości e-mail DKIM i SPF w ich systemie DNS, aby zapewnić prawidłową dostawę wiadomości e-mail. Doradzamy im, aby korzystali z http://mail-tester.com w celu przetestowania, czy niczego nie przegapili i bardzo podoba mi się to narzędzie.

Jednym z problemów, na który natrafiliśmy kilka razy i nie jestem pewien, jest „limit” DNS rekordu SPF na podstawie nazwy domeny. Więc jeśli masz to:

v=spf1 a include:aspmx.googlemail.com include:campaignmonitor.com include:authsmtp.com include:mail.zendesk.com include:salesforce.com include:_hostedspf.discourse.org ~all

Dostaniesz

example.com ... campaignmonitor.com: Maximum DNS-interactive term limit (10) exceeded

Tak jak:

wyniki testera poczty

Mam kilka pytań na ten temat.

  1. Liczę tutaj sześć nazw domen, a nie 10, więc dlaczego trafia tutaj „dziesięć” żądań DNS? Odpowiedziałem tutaj

  2. Czy ten interaktywny termin 10 DNS ogranicza ostrzeżenie lub prawdziwy błąd? np. czy powinniśmy się tym przejmować? To trochę dokucza naszym klientom i wysyłają do nas e-maile z prośbą o wsparcie. Odpowiedziałem tutaj

  3. Czy ten interaktywny termin 10 DNS jest prawdziwym problemem w dzisiejszej sieci? Jak widać, ten klient ma wiele usług wysyłających za niego wiadomości e-mail i wszystkie są legalne. Być może ten limit DNS został ustalony w 2000 roku, gdy delegowanie takich usług e-mail nie było powszechne?

Tak, możemy zmusić naszych klientów do zmiany uwzględnienia na adresy IP w rekordzie SPF, ale to nas wiąże, jeśli kiedykolwiek zmienimy adresy IP, grupa klientów się załamie. Naprawdę nie chcę tego robić ...

Jakie są obejścia tego?

Jeff Atwood
źródło
Cholera, szukałem komunikatu o błędzie, ale otrzymałem zero trafień.
Jeff Atwood
2
Nie spodziewałbym się, że znajdziesz coś, co by tego szukało. Pochodzi z narzędzia do testowania online, a nie z rzeczywistego problemu (w którym w połączonym pytaniu zobaczysz coś w rodzaju komunikatu PermError).
Michael Hampton
Lubię te inne, ale nie widzę odpowiedzi, które dają obejście? Czy ten limit wyszukiwania 10 faktycznie jest egzekwowany w praktyce?
Jeff Atwood
1
Dodaj dmarcian.com/spf-survey do swojego zestawu narzędzi, upewnij się, że jeśli zapewniasz SPF swoim klientom, to nie jest to samo SPF, którego używasz bezpośrednio (nie dołączaj stron trzecich do dołączonego SPF)
Jacob Evans

Odpowiedzi:

8
  1. Zazwyczaj już udzielono odpowiedzi, należy pamiętać, że podanie Google w ten sposób jest błędne - chcesz użyć _spf.google.comlub ponieść karę za przekierowanie:

    ○ → host -t txt aspmx.googlemail.com
    aspmx.googlemail.com descriptive text "v=spf1 redirect=_spf.google.com"
    
    ○ → host -t txt _spf.google.com
    _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
    

To wyszukiwanie samodzielnie zużyje 5/10 - nadal 4/10 jest do bani, ale o 20% mniej.

  1. Będzie zatrzymać przetwarzanie i powrót stały błąd - to jest do silnika za pomocą SPF zdecydować, jak chce leczyć trwały błąd.

  2. Tak - bez limitów przetwarzania Mechanizmy SPF mogłyby być używane jako wzmacniacz DoS przeciwko stronie trzeciej lub drugiej stronie.

Aby obejść ten problem, wiadomości e-mail mogą pochodzić z subdomeny głównej właściwości - community.largecorporation.comna przykład.

MikeyB
źródło
Uważam, że użycie subdomeny psuje DKIM? Wiem, że mieliśmy z tym problem w przeszłości. Wydaje się, że to jedyne rozwiązanie.
Jeff Atwood
1
@JeffAtwood Zwykle sygnatura DKIM jest podpisana przez wysyłającą domenę. Jeśli używasz subdomeny, zarejestruj się w subdomenie. Jednak podpisanie subdomeny jest legalne, ale przetwarzanie może nie być możliwe. Należy utworzyć rekordy DKIM w odniesieniu do domeny podpisującej. Powszechne jest również, że autor podpisuje dokument, aby umożliwić weryfikację pochodzenia.
BillThor,
1
Tak długo, jak odpowiednie rekordy SPF i DKIM są obecne dla domeny poczty, a nie domeny głównej, a ty się podpisujesz d=subdomain.example.com, wszystko będzie dobrze. W teorii. Lepiej to przetestuj!
MikeyB,
8
  1. Zakładając, że zwolnienia (takie jak wiele odniesień _spf.google.comi rekordy, do których się odnosi) są liczone tylko raz, liczę 17 wyszukiwań od momentu, w którym już przejrzałeś rekord początkowy. (Patrz poniżej.)

  2. Odmawia wyszukiwania wszystkich rekordów niezbędnych do oceny rekordu SPF, ponieważ byłoby to „zbyt dużo pracy”. Prawdopodobnie oznacza to, że będzie traktować Twoją domenę tak, jakby nie miała rekordu SPF (lub prawdopodobnie go odrzuci). Specyfikacja mówi, że skutkuje to permerrorem , który pozostawia odbiorcy dość swobodę decydowania o tym, co robić .

  3. Generalnie myślę, że przemoc rośnie. Wydaje się, że ograniczenie to ma na celu udaremnienie niewłaściwych domen nadawców, które w przeciwnym razie mogłyby przytłoczyć odbiorcę ogromnymi łańcuchami SPF, potencjalnie prowadząc do DoS.

Myślę, że chociaż outsourcing poczty e-mail jest powszechny, tak naprawdę nie jest tak często outsourcing wiadomości e-mail do sześciu różnych dostawców. Musisz jakoś zoptymalizować rekord SPF.
(Po pierwsze, odniesienie do aspmx.googlemail.comwydaje się marnotrawstwem, ponieważ natychmiast przekierowuje do innej nazwy).

<lookup of example.com A>                   #1
$ dig aspmx.googlemail.com TXT +short       #2
"v=spf1 redirect=_spf.google.com"
$ dig _spf.google.com TXT +short            #3
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig _netblocks.google.com TXT +short      #4
"v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig _netblocks2.google.com TXT +short     #5
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig _netblocks3.google.com TXT +short     #6
"v=spf1 ~all"
$ dig campaignmonitor.com TXT +short        #7
"google-site-verification=HcHoB67Mph6vl5_x4gK5MN9YwN5gMgfZYdNmsP07tIg"
"v=spf1 mx ptr ip4:23.253.29.45/29 ip4:203.65.192.250 include:cmail1.com include:_spf.google.com include:stspg-customer.com ~all"
$ dig cmail1.com TXT +short                 #8
"google-site-verification=HSJ8sL4AxQo0YHHNk9RwDqs0p3lJPGmc1nCrSsmous8"
"mailru-verification: 95d4c6eb0645b43c"
"v=spf1 ip4:103.28.42.0/24 ip4:146.88.28.0/24 ip4:163.47.180.0/22 ip4:203.55.21.0/24 ip4:204.75.142.0/24 ~all"
$ dig stspg-customer.com TXT +short         #9
"v=spf1 ip4:166.78.68.221 ip4:166.78.69.146 ip4:23.253.182.103 ip4:192.237.159.42 ip4:192.237.159.43 ip4:167.89.46.159 ip4:167.89.64.9 ip4:167.89.65.0 ip4:167.89.65.100 ip4:167.89.65.53 -all"
$ dig authsmtp.com TXT +short               #10
"v=spf1 include:spf-a.authsmtp.com include:spf-b.authsmtp.com ~all"
"google-site-verification=skc1TleK4GylDiNZUayfvWWgqZIxmmiRj4KgXlCgB8E"
$ dig spf-a.authsmtp.com TXT +short         #11
"v=spf1 ip4:62.13.128.0/24 ip4:62.13.129.128/25 ip4:62.13.136.0/22 ip4:62.13.140.0/22 ip4:62.13.144.0/22 ip4:62.13.148.0/23 ip4:62.13.150.0/23 ip4:62.13.152.0/23 ~all"
$ dig spf-b.authsmtp.com TXT +short         #12
"v=spf1 ip4:72.52.72.32/28 ip4:64.49.192.16/29 ip4:209.61.188.242 ip4:64.49.192.24 ip4:64.49.192.25 ip4:64.49.210.64/29 ip4:64.49.210.72/30 ip4:64.49.210.76 ip4:64.49.210.77 ip4:64.49.210.78 ~all"
$ dig mail.zendesk.com TXT +short           #13
"v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ~all"
$ dig salesforce.com TXT +short             #14
"adobe-idp-site-verification=898b7dda-16a9-41b7-9b84-22350b35b562"
"MS=749862C9F42827A017A6EA2D147C7E96B3006061"
"MS=ms68630177"
"v=spf1 include:_spf.google.com include:_spfblock.salesforce.com include:_qa.salesforce.com ip4:136.146.208.16/28 ip4:136.146.210.16/28 ip4:136.146.208.240/28 ip4:136.146.210.240/28 ip4:85.222.130.224/28 ip4:136.147.62.224/28 ip4:136.147.46.224/28 mx ~all"
$ dig _spfblock.salesforce.com TXT +short   #15
"v=spf1 ip4:96.43.144.0/20 ip4:182.50.76.0/22 ip4:202.129.242.0/23 ip4:204.14.232.0/21 ip4:62.17.146.128/26 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:68.232.207.20 ip4:207.67.38.45 ip4:198.245.81.1 ip4:198.245.95.4/30 ip4:136.146.128.64/27  ~all"
$ dig _qa.salesforce.com TXT +short         #16
"v=spf1 ip4:199.122.122.176/28 ip4:199.122.121.112/28 ip4:199.122.122.240/28 ip4:66.231.95.0/29 ~all"
$ dig _hostedspf.discourse.org TXT +short   #17
"v=spf1 ip4:64.71.148.0/29 ip6:2001:470:1:3c2::/64 -all"
Håkan Lindqvist
źródło
5

Jako zaakceptowana odpowiedź na jedno z powiązanych pytań wyjaśniono , wiele podstawowych narzędzi dla systemów UNIX faktycznie egzekwuje ten limit (choć nie wszystkie w dokładnie taki sam sposób), więc każda implementacja SPF, która ich używa - prawie w UNIX - egzekwuje również te limity. Systemy Windows są dla siebie prawem, a ja nie mogę rzucić na nie żadnego światła.

Obejściem tego problemu jest utworzenie zadania cron, które ocenia łańcuch zewnętrznych rekordów SPF, wyraża je wszystkie jako bloki ipv4 i ipv6 i zapisuje je w twoim rekordzie. Nie zapomnij -all.

W twoim przypadku chcesz, aby klienci mogli publikować rekord SPF, którego nie muszą następnie utrzymywać. Jedną z możliwości może być opublikowanie przez każdego klienta rekordu zawierającego redirect=spf.client1.jeffs-company.example, a następnie wykonanie zadania polegającego na utrzymaniu listy bloków sieciowych na poziomie jeffs-company.example.

Być może ten limit DNS został ustalony w 2000 roku, gdy delegowanie takich usług e-mail nie było powszechne?

Limit utrudnia przekazanie wiadomości e-mail na sześć lub siedem dużych operacji; ale prawdopodobnie robiąc to, straciłeś kontrolę nad pocztą e-mail.

Gdzieś, kiedyś, jakiś podwykonawca, którego istnienie było całkowicie nieświadome i nad którym nie masz kontroli, zgubi średnik, a ton fałszywej wiadomości e-mail zostanie wysłany z SPF imprimatur wprost na niego. Pełna kontrola nad pocztą e-mail wymaga pełnej kontroli nad infrastrukturą poczty e-mail, co moim zdaniem jest całkowicie niezgodne z takim outsourcingiem.

Szalony Kapelusznik
źródło
0

Innym sposobem obejścia tych problemów jest sprawdzenie, które oprogramowanie jest dokładnie używane do sprawdzania ustawień SPF. W moim przypadku jest to cluebringer / PolicyD, który Mail::SPF::Serverw końcu używa i który akceptuje argumenty rozluźniające inaczej zakodowane ograniczenia. Problem polega na tym, że sam cluebringer nie obsługuje obecnie rozluźnienia tych argumentów , ale może to ulec zmianie w przyszłości i można po prostu powiedzieć dostawcom usług o tych możliwościach złagodzenia ich ustawień.

Jeśli zdecydują się to zrobić, to oczywiście poza własną kontrolą, ale to przynajmniej szansa.

Thorsten Schöning
źródło