Reverse DNS i Państwa serwer wysyłający

Moduł 5: Reputacja i najwięksi dostawcy poczty · Czas czytania: 9 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili wyjaśnić, dlaczego adres IP serwera wysyłającego Państwa pocztę musi mieć poprawny reverse DNS, ustalić, który serwer to w Państwa przypadku jest, oraz sprawdzić, czy zgadzają się zapisy w obu kierunkach.

Kluczowe pojęcia: serwer wysyłający, rekord PTR, forward-confirmed reverse DNS (FCrDNS), nazwa HELO/EHLO, nazwa generyczna, hosting współdzielony, własny serwer (VPS), właściciel puli adresów IP

Który serwer właściwie wysyła Państwa pocztę?

W module 4 mowa była o Państwa domenie: SPF, DKIM i DMARC znajdują się w DNS domeny example.com. W tym module przyjrzymy się czemuś innemu: serwerowi, który dostarcza Państwa pocztę do odbiorcy. Ten serwer ma adres IP, a odbiorcy oceniają ten adres niezależnie od Państwa domeny.

Który to serwer, zależy od sposobu wysyłania poczty:

Adres IP serwera wysyłającego znajdą Państwo w nagłówkach wiadomości wysłanej do siebie lub na inny adres (lekcja 1.5). Proszę spojrzeć na najwyższą linię Received:, dodaną przez serwer odbierający. Znajdzie się tam coś takiego:

Received: from smtp.hosting.example (smtp.hosting.example [192.0.2.25])
        by mx.example.net with ESMTPS id 4f2a...

Adres w nawiasach kwadratowych, 192.0.2.25, to adres IP, z którego nawiązano połączenie z serwerem wysyłającym. Nazwa przed nim (smtp.hosting.example) to nazwa, jaką odbiorca znalazł dla tego adresu przez reverse DNS.

Reverse DNS w skrócie

Reverse DNS wiąże adres IP z nazwą, za pomocą rekordu PTR. Podstawy poznali Państwo w kursie DNS (lekcja 4.6): rekord ten nie znajduje się w strefie Państwa domeny, lecz w strefie odwrotnej (reverse zone) danego adresu IP, którą zarządza podmiot administrujący daną pulą adresów IP.

Dla poczty elektronicznej istotne są trzy rzeczy:

1. Istnieje rekord PTR. Adres IP bez reverse DNS wygląda jak przypadkowa maszyna w internecie. Gmail odrzuca taką pocztę z komunikatem 550 5.7.25 ... the sending IP address doesn't have a PTR record.
2. Nazwa wskazuje z powrotem na ten sam adres. Adres IP 192.0.2.25 ma rekord PTR smtp.hosting.example, a smtp.hosting.example ma rekord A 192.0.2.25. Nazywa się to forward-confirmed reverse DNS (FCrDNS). Gmail, Yahoo i T-Online wprost wymieniają to w swoich wymaganiach.
3. Nazwa wygląda jak serwer pocztowy. Nazwa typu 192-0-2-25.dsl.provider.example czy host25.dynamic.provider.example zdradza łącze domowe lub abonenckie. Filtry antyspamowe naliczają za to punkty karne albo od razu odrzucają połączenie.

Dla IPv6 obowiązują te same zasady. Jeśli serwer wysyła przez IPv6, to adres IPv6 również musi mieć rekord PTR i musi on wskazywać z powrotem za pomocą rekordu AAAA. Serwer, który jest poprawnie skonfigurowany pod kątem IPv4, ale nie pod kątem IPv6, napotyka problemy zwłaszcza w Gmailu: Google wymienia brakujący PTR dla IPv6 jako przyczynę błędu "IPv6 authorization error".

Nazwa HELO

Gdy serwer nawiązuje połączenie, przedstawia się poleceniem EHLO (lub starszym HELO) oraz nazwą (lekcja 1.2). RFC 5321 mówi, że powinna to być pełna nazwa serwera. W praktyce odbiorcy sprawdzają, czy ta nazwa:

• jest prawdziwą, istniejącą nazwą (nie localhost, nie goły adres IP, nie nazwa, której nie ma w DNS);
• pasuje do reverse DNS, a przynajmniej należy do tej samej domeny.

Przy pakiecie hostingowym lub usłudze pocztowej zajmuje się tym administrator. Jeśli prowadzą Państwo własny serwer pocztowy, nazwę HELO ustawia się w oprogramowaniu pocztowym (w Postfiksie nazywa się to myhostname) i należy zadbać, by ta nazwa, PTR oraz rekord A były ze sobą zgodne.

Hosting współdzielony: PTR nie musi być Państwa domeną

Często zadawane pytanie: "Czy reverse DNS nie powinien brzmieć mail.example.com, skoro to moja domena?" Nie. Przy hostingu współdzielonym i u dużych usług pocztowych jeden serwer wysyła pocztę dla setek lub tysięcy domen. Adres IP może mieć tylko jeden rekord PTR, więc zawiera on nazwę samego serwera, na przykład server12.hosting.example.

Tak powinno być. Odbiorcy sprawdzają, czy PTR istnieje, czy wskazuje z powrotem i czy nie jest generyczny. Nie sprawdzają, czy znajduje się w nim nazwa Państwa własnej domeny. Powiązanie między Państwa domeną a serwerem tworzy się za pomocą SPF (serwer znajduje się w Państwa SPF) oraz DKIM (serwer podpisuje wiadomości w imieniu Państwa domeny).

W WebOké jest to zorganizowane na przykład w ten sposób: serwery pakietu hostingowego mają reverse DNS z nazwą samego serwera, w domenie webawere.nl, który z kolei wskazuje z powrotem. U innych firm hostingowych i usług pocztowych działa to w podobny sposób, z ich własnymi nazwami serwerów.

Własny serwer: co trzeba zorganizować samodzielnie?

Jeśli wysyłają Państwo pocztę bezpośrednio z własnego serwera, na przykład z VPS-a ze sklepem internetowym lub z własnego serwera pocztowego, są Państwo wtedy samodzielnym nadawcą i trzeba zorganizować więcej rzeczy:

1. Proszę wybrać nazwę, na przykład mail.example.com.
2. Proszę utworzyć rekord A (i rekord AAAA) dla tej nazwy, wskazujący na adres IP serwera, w DNS Państwa domeny.
3. Proszę poprosić o rekord PTR u dostawcy serwera. Zazwyczaj w panelu klienta znajduje się pole "Reverse DNS" lub "rDNS". Tam wpisują Państwo tę samą nazwę.
4. Proszę ustawić nazwę HELO w oprogramowaniu pocztowym na tę samą nazwę.
5. Proszę umieścić adres IP w swoim SPF (ip4: i ip6:) oraz włączyć DKIM w oprogramowaniu pocztowym.
6. Proszę sprawdzić, czy port 25 wychodzący jest otwarty. Wielu dostawców domyślnie go blokuje, aby zapobiec nadużyciom; w takim przypadku trzeba poprosić o jego otwarcie albo wysyłać przez przekaźnik (relay) swojego dostawcy lub usługę wysyłkową.

Serwer pocztowy na zwykłym łączu internetowym w domu lub w biurze to niemal zawsze zły pomysł. Takie adresy często znajdują się na listach "adresów użytkowników końcowych" (jak Policy Block List Spamhaus, lekcja 5.2), rekordu PTR zwykle nie można samodzielnie wybrać, a T-Online wprost zastrzega, że takie systemy muszą wysyłać pocztę przez przekaźnik odpowiedniego dostawcy.

Sprawdzanie

Za pomocą wiersza poleceń (kurs DNS, lekcja 8.2):

dig -x 192.0.2.25 +short
smtp.hosting.example.

dig A smtp.hosting.example +short
192.0.2.25

Jeśli w drugim zapytaniu otrzymają Państwo ten sam adres, FCrDNS się zgadza. W przypadku IPv6 wykonuje się to samo za pomocą dig -x 2001:db8::25 i dig AAAA.

Mogą Państwo też sprawdzić, jak widział to odbiorca. W nagłówkach serwer odbierający umieszcza znalezioną nazwę w nawiasach po from. Jeśli widnieje tam unknown, nie znalazł on rekordu PTR. Niektóre serwery dodają też własną weryfikację, np. iprev=pass w linii Authentication-Results: (RFC 8601).

Podsumowanie

• Serwer wysyłający to serwer, który dostarcza Państwa pocztę do odbiorcy. Odbiorcy oceniają jego adres IP niezależnie od Państwa domeny.
• Ten adres IP musi mieć rekord PTR, który wskazuje z powrotem na ten sam adres (FCrDNS), zarówno dla IPv4, jak i IPv6, z nazwą, która nie jest generyczna.
• Nazwa HELO powinna być istniejącą nazwą pasującą do rekordu PTR.
• Przy hostingu współdzielonym i usługach pocztowych w rekordzie PTR znajduje się nazwa serwera, a nie Państwa domena. To jest poprawne.
• Przy własnym serwerze samodzielnie organizują Państwo nazwę, rekordy A/AAAA, PTR (za pośrednictwem dostawcy), HELO, SPF i DKIM.

Quiz

Zadanie

Zadanie Z5.1: Serwer wysyłający Państwa własnej domeny. Proszę wysłać wiadomość z własnego adresu na inny własny adres (na przykład adres Gmail lub Outlook.com) i otworzyć nagłówki. Proszę znaleźć adres IP serwera, który dostarczył wiadomość, nazwę PTR tego adresu, oraz wpisać, czy nazwa wskazuje z powrotem na ten sam adres (tak/nie). Jeśli nie mają Państwo własnej domeny, proszę użyć adresu IP serwera pocztowego mx00.t-online.de. Program na żywo pobiera rekord PTR oraz rekord A/AAAA i porównuje je.

Więcej informacji

Kroki opisane w tych artykułach dotyczą paneli WebOké; u innych dostawców działa to w podobny sposób.

• Wysyłanie poczty z Państwa VPS i konfiguracja reverse DNS
• Bezpłatny kurs DNS 4.6: Reverse DNS (PTR): od numeru z powrotem do nazwy
• Jak działa wysyłanie wiadomości e-mail / SMTP
• RFC 5321 (SMTP), paragraf 4.1.1.1 o nazwie EHLO; RFC 8601 o nagłówku Authentication-Results