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

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ć.}

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” .

@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.