Nie otrzymuję wiadomości e-mail od niektórych nadawców z powodu konfiguracji DNS


9

Zauważyłem szczególne zachowanie mojej domeny Google Apps. Większość wiadomości przychodzi tak, jak można się spodziewać, ale z biegiem czasu doszedłem do wniosku, że wiadomości od niektórych nadawców nie przychodzą. Po zidentyfikowaniu jednego z takich nadawców, którego wiadomości nie dotrą, poprosiłem go, aby spróbował wysłać mi wiadomość e-mail i przekazać odpowiedź „niepowodzenie dostarczenia” na moją zwykłą wiadomość Gmail.

Odpowiedź na niepowodzenie dostarczenia zawierała następujący fragment:

----- Zapis sesji następuje -----
<myusername@GHS.L.GOOGLE.COM>... Odroczony: Przekroczono limit czasu połączenia z ghs.l.google.com.

Pomogło mi to zidentyfikować problem, przeprowadzając szybkie wyszukiwanie, które doprowadziło mnie do tej strony na Forum pomocy Google Apps. Rzeczywiście sprawdziłem rekord DNS dla mojej domeny i @ustawiłem go na ghs.google.com. (CNAME), co nie powinno być. Zmiana na @ 74.125.93.121 (A)* rozwiązała problem.

Rozumiem, że w przypadkach, w których poczta nie przychodziła, moja nazwa domeny została zastąpiona nazwą kanoniczną poprzez wyszukiwanie CNAME, więc poczta została wysłana myusername@ghs.l.google.comzamiast myusername@mydomain.com. Ale dlaczego zadziałało u zdecydowanej większości nadawców? Czy nadawcy, których poczta nie przychodziła, używali innego rodzaju protokołu pocztowego, dziwnych ustawień DNS lub co to może być?

Z tego, co mogłem zobaczyć, badając problem w Google, wydaje się, że jest to szeroko rozpowszechniony problem (wiele osób narzeka na e-maile z Battle.net, które nie przychodzą, byłyby popularnym przykładem), tylko że ludzie nie wydają się należy pamiętać, że problem leży w ich własnych ustawieniach DNS, a nie po stronie nadawcy.

Jak to można wyjaśnić?

* Użyłem tego adresu IP z powodu tego, co tutaj przeczytałem , ale myślę, że każdy adres IP by zadziałał. Czy ktoś może to potwierdzić? Pamiętaj, że samo usunięcie @rekordu nie rozwiązało problemu, trzeba go było zmienić.

Odpowiedzi:


12

Z RFC 2821 „Prosty protokół przesyłania poczty”, sekcja 5 „Rozpoznawanie adresów i obsługa poczty”:

Wyszukiwanie najpierw próbuje zlokalizować rekord MX powiązany z nazwą. Jeśli zamiast tego zostanie znaleziony rekord CNAME, wynikowa nazwa jest przetwarzana tak, jakby była nazwą początkową.

Ogólnie tak działa CNAME. Często są niewłaściwie używane, źle rozumiane i źle wdrażane. :-)

Jeśli Twoja domena to example.com, prawdopodobnie masz istniejące rekordy MX wskazujące zwykłych hostów Google Apps.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

Wygląda na to, że miałeś również taki wpis:

example.com. CNAME ghs.l.google.com.

RFC 1034 „Pojęcia i udogodnienia związane z domenami” w sekcji 3.6.2 „Aliasy i nazwy kanoniczne” zaleca się przeciw tej konfiguracji:

Jeśli CNAME RR jest obecny w węźle, żadne inne dane nie powinny być obecne; zapewnia to, że dane dla nazwy kanonicznej i jej aliasów nie mogą się różnić.

W przypadku wklejenia błędu serwer pocztowy i / lub serwer DNS po stronie wysyłającej próbowali wyszukać rekordy MX dla Twojej domeny, example.com, i znaleźli CNAME wskazujący na ghs.l.google. com. Następnie próbował wyszukać rekordy MX dla ghs.l.google.com. Ta domena nie ma obecnie żadnych rekordów MX, więc serwer pocztowy przejdzie do rekordu A dla ghs.l.google.com. Ten adres IP nie nasłuchuje na porcie SMTP, więc wynikiem jest błąd „Upłynął limit czasu połączenia z ghs.l.google.com”.

Usunięcie rekordu CNAME rozwiązało problemy z pocztą. Możesz napotkać problemy, jeśli adres IP zdefiniowany na jego miejscu zostanie zmieniony po stronie Google.

Zamiast tego możesz zdefiniować nazwę dla www.example.com:

www.example.com. CNAME ghs.l.google.com.

I uruchom mały serwer WWW na dowolnym adresie IP, na który wskazuje example.com, który po prostu przekierowuje HTTP na http://www.example.com/

To dość zaskakujące, że działało tak samo dobrze, jak działało. Wydaje mi się, że prawo Postela ma tu jakieś uznanie. :-)

Powrót do RFC 1034 2.6.2:

Zalecenia CNAME powodują specjalne działanie w oprogramowaniu DNS. Gdy serwer nazw nie znajdzie żądanego RR w zestawie zasobów powiązanym z nazwą domeny, sprawdza, czy zestaw zasobów składa się z rekordu CNAME z pasującą klasą. Jeśli tak, serwer nazw dołącza do odpowiedzi rekord CNAME i ponownie uruchamia zapytanie przy nazwie domeny określonej w polu danych rekordu CNAME. Jedynym wyjątkiem od tej reguły jest to, że zapytania pasujące do typu CNAME nie są restartowane.

W takim przypadku można argumentować, że serwer DNS podążałby za CNAME podczas wyszukiwania MX, chyba że nie znaleziono rekordów MX.

Podczas wysyłania poczty Sendmail i qmail (i prawdopodobnie inni) domyślnie podejmą próbę przepisania nazwy CNAME użytej po prawej stronie adresu e-mail na nazwę kanoniczną.

Rzeczywiście, niektóre strony polegały na tym zachowaniu. djb szczegółowo wyjaśnia, dlaczego uważa, że ​​ludzie powinni przestać na nim polegać w swoim dokumencie „Rekordy CNAME w poczcie” .


Dziękuję za tę wyczerpującą odpowiedź! :) Podsumowując, można powiedzieć, że powodem, dla którego działało u niektórych nadawców, ale nie dla innych nadawców, jest to, że używają różnych MTA następujących po CNAME, mimo że istnieją tam rekordy MX, które zgodnie z RFC 1034 2.6.2 mogą być uważane za nieprawidłowe zachowanie?
0sh

Nie jestem pewien, czy nazwałbym to zachowanie „wadliwym”. Konfiguracja CNAME z innymi rekordami (MX, NS itp.) Jest czymś, co zostało zepsute / niezalecane, a różni gospodarze interpretowali to na różne sposoby.
jeff

Czy to „ogólnie tak”, ale nie jesteś pewien, czy nazwałbyś to zachowanie niewłaściwym, czy też całkowicie nie zrozumiałem sensu?
0sh

Specyfika to bałagan, więc „ogólnie tak” :-)
Jeff

MTA powinien sprawdzać domenę po @adresie e-mail w poszukiwaniu rekordów MX i nic więcej. Jeśli się pojawi, powinien natychmiast podjąć próbę dostarczenia do jednego z najniższych rekordów MX. Jeśli wszystkie serwery MX nie mogą się połączyć lub nie znaleziono rekordów MX, powinien spróbować połączyć się z samą domeną. MTA, o którym mowa, zdecydowanie posuwa się zbyt daleko w zakresie rozwiązywania informacji lub nie przestrzega zasad określania, z którym serwerem pocztowym się połączyć. Nie powinno być nic złego w tym, że domena wskazuje CNAME - ale potrzebujesz rekordów MX, aby e-mail działał.
Eli Sand

1

@Symbol w rekordzie BIND jest tylko sposobem skrótem pisania domenę. Jeśli tworzysz rekord dla example.com, @jest to tylko alias dla example.com. Mówienie, że @rekord musiał być adresem IP, jest stwierdzeniem, w którym brakuje krytycznych informacji - nie powiedziałeś nam, jaki to typ rekordu.

Z raportu dostarczenia wynika, że ​​być może zrobiłeś coś ze swoim DNS, aby zdalny serwer pocztowy przepisał domenę na ghs.l.google.com - bardzo dziwnie (PS, rekord A musi być adresem IP, rekord CNAME musi nie być IP lub inny rekord CNAME).

Dlaczego serwer pocztowy tych osób przepisuje Twój adres jest dziwny - nie powinno, chyba że ta osoba zrobi coś, co wyraźnie powie mu, żeby przepisał. Nie powinno też w ogóle obchodzić, jaki jest adres IP domeny, chyba że nie może znaleźć żadnych rekordów MX, ponieważ rekordy MX to sposób, w jaki serwery pocztowe ustalają, dokąd trafia poczta.

Wydaje mi się, że biorąc pod uwagę bardzo mało podanych informacji, nie zastosowałeś się do instrukcji Google, jak w ogóle poprawnie skonfigurować DNS dla poczty e-mail. Prawdopodobnie masz nawet jakieś błędy w pliku strefy - poproś o sprawdzenie przez kompetentnego administratora strefy.


Po pierwsze wspomniałem, że @rekord był typu CNAME. Po drugie, DNS, którego używam, to ten dostarczany przez Google przy zakupie, dlatego nie mam nawet dostępu do pliku strefy. Użyłem ustawień domyślnych dostarczonych przez Google. Wreszcie „bardzo mało dostarczonych informacji” najwyraźniej wystarczyło komuś kompetentnemu do udzielenia pomocnej, satysfakcjonującej i (w przeciwieństwie do własnej) serdecznej odpowiedzi.
0sh

Najwyraźniej nie rozumiesz DNS, a opinia zwrotna była całkowicie nieuzasadniona. Edytowałeś również swoje pytanie po tym, jak opublikowałem moją odpowiedź, dodając dodatkowe informacje. Nigdy też nie wspominasz raz, że nie masz dostępu do pliku strefy, mimo że wyraźnie wspomniałeś, że je zmieniłeś.
Eli Sand
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.