Przejdź do głównej zawartości

3 posty z tagiem "spam"

Wyświetl wszystkie tagi

ULTIMATE GUIDE: Konfiguracja serwera dla prawidłowej dostawy poczty. CZĘŚĆ 2: Jak zapobiec trafianiu wysyłanych wiadomości do SPAM-u

· 7 min aby przeczytać
Customer Care Engineer

konfiguracja-rekordow-dns-spf-dkim-dmarc-ptr-mx-przewodnik-zapobiegania-spamowi-email

informacja

Rekordy DNS to zestaw technicznych parametrów domeny, które określają, gdzie kierować różne typy ruchu: WWW, pocztę, FTP itd.

Łączą nazwę domeny z adresami IP i innymi serwerami, dzięki czemu przeglądarki oraz systemy pocztowe wiedzą, dokąd się odwoływać podczas obsługi twojej strony lub poczty.

W pierwszej części tego poradnika skonfigurowaliśmy zaporę sieciową i otworzyliśmy niezbędne porty do obsługi poczty. Teraz, gdy upewniliśmy się, że wiadomości są wysyłane z Twojego serwera, musimy sprawdzić, czy rekordy DNS są poprawnie skonfigurowane. Gmail, Outlook i inne duże serwisy pocztowe skrupulatnie sprawdzają rekordy MX, SPF, DKIM, DMARC oraz PTR, zanim dostarczą wiadomości do głównej skrzynki odbiorczej. Prawidłowe wpisy znacząco zwiększają szansę, że twoje maile trafią do „Odebranych”, a nie do SPAM-u (lub nie zostaną całkowicie odrzucone).

W kolejnych krokach pokażemy, jak sprawdzić aktualne rekordy DNS każdego typu i jak poprawnie je skonfigurować.

warning

W tej części artykułu przykładowo używamy domeny example.com, adresu IPv4 1.2.3.4 i adresu IPv6 2001:db8:1:11::1. Pamiętaj, aby zawsze zastąpić je prawdziwym adresem twojej domeny i realnymi IP serwera.

Etap wstępny

Krok 1. Sprawdzenie dostawcy DNS

W tej części poradnika będziemy wielokrotnie edytować rekordy DNS. Wszystkie zmiany wprowadza się w panelu aktualnego dostawcy DNS twojej domeny. Aby zrobić to poprawnie, musisz dokładnie wiedzieć, kto pełni tę funkcję w tej chwili. W przeciwnym razie modyfikacje pozostaną bez efektu.

Najczęściej dostawcą DNS jest:

  • twój hostingodawca,

  • rejestrator domeny,

  • dostawca ochrony DDoS.

Jednak nie zawsze.

Aby sprawdzić, kto aktualnie zarządza DNS dla twojej domeny, możesz użyć polecenia whois. Dla przykładu sprawdźmy domenę kodu.cloud:

whois kodu.cloud | grep -i "Name Server" | awk '{print $3}'

W wyniku otrzymasz listę serwerów NS:

art.ns.cloudflare.com
isla.ns.cloudflare.com

Oznacza to, że w tym przypadku DNS należy edytować w panelu Cloudflare.

W większości przypadków sam prefiks domeny serwera NS pozwala zorientować się, kto jest dostawcą DNS, ale nie zawsze. Na przykład w ramach naszej darmowej usługi DNS nazwy mogą wyglądać tak:

birman.nameserver.red.
rex.nameserver.red.
korat.nameserver.blue.
toybob.nameserver.blue.

W takiej sytuacji najlepiej skontaktować się z pomocą techniczną twojego hostingodawcy, aby dokładnie ustalić, gdzie edytować rekordy.

Gdy już pewnie ustalisz dostawcę DNS, zaloguj się do jego panelu i przejdź do sekcji dotyczącej edycji rekordów DNS dla twojej domeny. Większość kolejnych zmian będziemy wprowadzać właśnie tam. Ponieważ każdy panel wygląda inaczej, nie da się przygotować uniwersalnej instrukcji krok po kroku.

Jeżeli napotkasz trudności, skorzystaj z pomocy technicznej twojego dostawcy.

warning

Po zmianie rekordów DNS odświeżenie pamięci podręcznej może potrwać od 20 minut do nawet 24 godzin. Dodatkowo duże systemy pocztowe potrzebują czasu na zaktualizowanie reputacji domeny i serwera. Aby zapewnić stabilną dostawę wiadomości, zaleca się odczekać około 48 godzin, chociaż zwykle pierwsze efekty widoczne są już po 2-3 godzinach.

Krok 2. Sprawdzenie obecności IPv6

Do poprawnej konfiguracji musimy dokładnie ustalić, czy serwer posiada adres IPv6. Aby to sprawdzić, wykonaj polecenie:

ip a | grep inet6

Jeśli zobaczysz wynik podobny do tego:

inet6 ::1/128 scope host noprefixroute
inet6 2001:db8:1:11::1/120 scope global
inet6 fe80::1/64 scope link

To znaczy, że twój serwer ma adres IPv6. Znajdziesz go w wierszu kończącym się na scope global do znaku /.

Zapisz go, bo przyda się w dalszych krokach.

Jeśli w wyniku będzie pusto albo pojawi się tylko jedna linia tego typu:

inet6 fe80::1c2:3dff:fe4a:5b6c/64 scope link

To znaczy, że twój serwer nie posiada IPv6. W takim przypadku w dalszej konfiguracji pomijaj IPv6.

Konfiguracja rekordów DNS

Krok 3. Sprawdzenie rekordu MX

Rekord MX określa, na który serwer ma trafiać przychodząca poczta dla twojej domeny. Sprawdzisz go poleceniem:

dig MX example.com +short

Przykładowy poprawny wynik:

10 mail.example.com.

Jeśli wynik będzie nieprawidłowy lub wskazuje na niewłaściwy serwer, edytuj rekord MX u swojego dostawcy DNS.

  • Typ: MX
  • Nazwa: @
  • Adres: mail.example.com
  • Priorytet: 10

Jeśli rekordu nie ma, zobaczysz pusty wynik:

~ dig MX badexample.com +short
~

W takim przypadku musisz utworzyć rekord DNS, używając przykładu powyżej.

Pamiętaj, że rekordów MX może być kilka. W takim przypadku poczta będzie najpierw wysyłana na serwer o niższej wartości priorytetu (np. 10 ma wyższy priorytet niż 20).

Jeśli główny serwer jest niedostępny, dostawa zostanie zrealizowana na serwerze o następnym priorytecie.

Krok 4. Sprawdzenie rekordów A i AAAA

Teraz upewnij się, że mail.example.com oraz example.com wskazują na adres serwera, z którego wysyłana jest poczta:

dig A example.com +short
dig A mail.example.com +short
dig AAAA example.com +short
dig AAAA mail.example.com +short

Adresy IP w wynikach obu poleceń powinny być takie same jak prawdziwe adresy IPv4 i IPv6 twojego serwera.  Jeśli się różnią lub nie ma takich wpisów, edytuj je/utwórz w swoim koncie u dostawcy DNS:

  1. example.com (А):
  • Typ: A
  • Nazwa: @
  • Adres: 1.2.3.4
  1. example.com (АAAA):
  • Typ: AAAA
  • Nazwa: @
  • Adres: 2001:db8:1:11::1
  1. mail.example.com (A):
  • Typ: A
  • Nazwa: mail
  • Adres: 1.2.3.4
  1. mail.example.com (AAAA):
  • Typ: AAAA
  • Nazwa: mail
  • Adres: 2001:db8:1:11::1

Krok 5. Sprawdzenie rekordu SPF

Rekord SPF określa, które serwery mogą wysyłać pocztę w imieniu twojej domeny.

Sprawdzenie:

dig TXT example.com +short

Przykładowy poprawny rekord SPF:

example.com. TXT "v=spf1 ip4:1.2.3.4 ip6:2001:db8:1:11::1 a mx ~all"

Bardzo ważne: domena może mieć tylko jeden rekord SPF. Więcej niż jeden prawie zawsze powoduje błędy w weryfikacji.

Jeśli adres IP różni się od aktualnego adresu twojego serwera lub taki wpis nie istnieje, edytuj/utwórz go w osobistym koncie swojego dostawcy DNS:

Jeśli masz IPv6:

  • Typ: TXT
  • Nazwa: @
  • Wartość: v=spf1 ip4:1.2.3.4 ip6:2001:db8:1:11::1 a mx ~all

Jeśli nie masz IPv6:

  • Typ: TXT
  • Nazwa: @
  • Wartość: v=spf1 ip4:1.2.3.4 a mx ~all

SPF oferuje wiele dodatkowych możliwości, ale taki zestaw w pełni wystarcza, by poczta była poprawnie akceptowana przez większość usług.

Krok 6. Sprawdzenie rekordu DKIM

DKIM to cyfrowy podpis wiadomości, który potwierdza, że e-mail został wysłany z określonej domeny i nie został po drodze zmodyfikowany. Do weryfikacji podpisu używany jest rekord DNS typu TXT z kluczem publicznym: najpierw podpis jest tworzony na serwerze, a następnie klucz jest publikowany w DNS.

Istnieje wiele sposobów uzyskania DKIM dla domeny pocztowej, ale w tej części artykułu skupiamy się na najprostszym, czyli wykorzystaniu FASTPANEL. W FASTPANEL podpis DKIM tworzony jest automatycznie dla każdego dodanego domenowego konta pocztowego.

FASTPANEL to bardzo wygodne narzędzie do pracy z serwerem pocztowym - nie musisz niczego instalować ani konfigurować ręcznie. Otrzymujesz gotowy serwer pocztowy do obsługi poczty przychodzącej i wychodzącej oraz wygodny webmail.

Twoim jedynym zadaniem jest skopiowanie wartości otwartego klucza i dodanie go do DNS. Aby to zrobić, przejdź w panelu do sekcji “Management” → “Mail” i kliknij przycisk “DKIM” na końcu wiersza odpowiadającego twojej domenie pocztowej.

konfiguracja-rekordow-dns-spf-dkim-dmarc-ptr-mx-przewodnik-zapobiegania-spamowi-email

Następnie skopiuj wyświetlony klucz publiczny:

konfiguracja-rekordow-dns-spf-dkim-dmarc-ptr-mx-przewodnik-zapobiegania-spamowi-email

Po stronie dostawcy DNS utwórz następujący rekord DNS:

  • Typ: TXT
  • Nazwa: dkim._domainkey
  • Wartość: skopiowany wcześniej klucz publiczny

Jeśli rekord już istnieje, najlepiej nadpisać go nowym kluczem, żeby mieć pewność, że używasz aktualnego.

DKIM może mieć wiele rekordów, o ile nazwy są różne. Na przykład, jednoczesna obecność dkim._domainkey oraz mail._domainkey nie spowoduje żadnych konfliktów.

Po dodaniu rekordu i odświeżeniu cache DNS możesz zweryfikować DKIM poleceniem:

dig TXT dkim._domainkey.example.com +short

Krok 7. Sprawdzenie rekordu DMARC

DMARC określa, co powinno się wydarzyć z wiadomościami, które nie przechodzą SPF lub DKIM.

Sprawdzenie:

dig TXT _dmarc.example.com +short

Przykładowy wynik:

"v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"

DMARC ma sporo opcji, ale w większości przypadków wystarczy prosty rekord:

  • Typ: TXT
  • Nazwa: _dmarc
  • Wartość: v=DMARC1; p=reject

Krok 8. Sprawdzenie zmiennej sendmail_path (opcjonalnie)

Ten krok jest szczególnie pomocny, jeśli wiadomości są wysyłane bezpośrednio ze strony WWW - np. przez formularz kontaktowy, system zamówień itp.

Aby wszystkie niezbędne rekordy DNS były brane pod uwagę podczas wysyłki, ustaw w konfiguracji PHP wartość zmiennej sendmail_path:

/usr/sbin/sendmail -t -i -f "[email protected]"

W FASTPANEL zrobisz to w ustawieniach danej strony, w sekcji “PHP Settings”.

Konfiguracja hostname i PTR

PTR (lub rDNS) to odwrotny rekord DNS, który przypisuje adres IP do nazwy domeny.

Hostname to po prostu nazwa twojego serwera w sieci.

Jeśli rekord PTR nie zgadza się z hostname serwera, wiadomości niemal na pewno trafią do spamu.

Najlepszą praktyką jest ustawienie zarówno hostname, jak i PTR na wartość mail.example.com (oczywiście zawsze zamieniamy example.com na własną domenę).

Krok 9. Hostname

Aby sprawdzić aktualny hostname, wykonaj polecenie:

hostname

Aby zmienić hostname, użyj:

sudo hostnamectl set-hostname mail.example.com

Następnie ponownie wykonaj polecenie hostname, aby upewnić się, że wszystko działa poprawnie.

Krok 10. PTR

Z rekordem PTR sytuacja wygląda inaczej: zmienić go może tylko właściciel adresu IP, czyli twój dostawca usług hostingowych. Więcej szczegółów na temat przyczyn tego stanu rzeczy można znaleźć w tym artykule.

Niektórzy dostawcy usług hostingowych umożliwiają edycję PTR w osobistym koncie.  Możesz spróbować zrobić to samodzielnie. Jeśli nie uda się, skontaktuj się z pomocą techniczną i poproś o ustawienie wartości PTR na:

mail.example.com

Pamiętaj, że wartość tę należy zawsze zmienić na rzeczywistą nazwę twojej domeny.

Zmiany są zazwyczaj wprowadzane natychmiastowo, nie ma potrzeby oczekiwania na aktualizację pamięci podręcznej DNS w tym przypadku. Obecny rekord PTR możesz sprawdzić poleceniem:

dig -x 1.2.3.4 +short

Końcowa weryfikacja

Jeśli dotarłeś do tego miejsca - gratulacje! Jesteśmy już na ostatniej prostej. Teraz pozostaje tylko sprawdzić, czy wszystko zostało skonfigurowane poprawnie i czy wiadomości wysyłane z twojego serwera rzeczywiście będą trafiać do folderu „Odebrane” u dowolnego adresata. Zanim rozpoczniesz testy, koniecznie poczekaj na odświeżenie cache DNS. Najlepiej odczekać co najmniej 1–2 godziny od ostatniej zmiany rekordów DNS.

Istnieje wiele zewnętrznych narzędzi, które umożliwiają przeprowadzenie kompleksowych testów poczty. Możesz skorzystać z dowolnego z nich. W ramach tego poradnika użyjemy serwisu mail-tester.com.

Aby przeprowadzić weryfikację, wejdź na stronę i skopiuj nazwę testowej skrzynki pocztowej:

konfiguracja-rekordow-dns-spf-dkim-dmarc-ptr-mx-przewodnik-zapobiegania-spamowi-email

Wyślij na nią wiadomość z dowolnej skrzynki w twojej domenie i kliknij przycisk „Then check your score”. Pamiętaj, aby wpisać temat oraz coś napisać w treści wiadomości.

Serwis pokaże wynik sprawdzenia DKIM, SPF, DMARC, obecność PTR oraz ogólną ocenę „reputacji” wiadomości, a także wskaże, czy twój serwer znajduje się na listach SPAM.

Jeżeli dokładnie i konsekwentnie wykonałeś wszystkie kroki opisane w artykule, wynik powinien wynosić 10/10. Jeśli będzie niższy, zapoznaj się z zaleceniami serwisu mail-tester. Znajdziesz tam szczegółowe informacje o problemach i sposobach ich rozwiązania.

Dodatkowo możesz sprawdzić obecność swojego serwera na listach SPAM przy pomocy serwisu:

 https://mxtoolbox.com/blacklists.aspx

Jeżeli któraś z kontroli wykaże, że adres IP twojego serwera trafił na listę, skontaktuj się z dostawcą hostingu, aby pomógł ci rozwiązać problem.

Po wykonaniu tych kroków konfiguracja serwera jest zakończona. Jeżeli nie chcesz tracić czasu na samodzielne testy lub napotkałeś trudności, możesz zawsze zgłosić się do pomocy technicznej kodu.cloud. Dla naszych klientów wykonujemy wszystkie opisane czynności szybko, w dowolnym czasie i bezpłatnie.

ULTIMATE GUIDE: Konfiguracja serwera dla prawidłowej dostawy poczty. CZĘŚĆ 1: Firewall

· 9 min aby przeczytać
Customer Care Engineer

konfiguracja-zapory-serwera-pocztowego-linux-przewodnik-instalacji-SMTP-IMAP

informacja

Firewall (zapora sieciowa) - to sprzęt z oprogramowaniem lub samo oprogramowanie, które kontroluje, jakie połączenia z serwerem są dozwolone, a jakie powinny zostać zablokowane. W zdecydowanej większości współczesnych dystrybucji serwerowych Linux firewall jest dostępny od razu po instalacji systemu, choć może wymagać dodatkowej konfiguracji.

Prawidłowe dostarczanie poczty do adresata zależy nie tylko od działania serwera pocztowego, ale także od prawidłowej konfiguracji rekordów DNS i firewall. Jeśli coś jest z nimi nie tak, wiadomości mogą trafiać do folderu SPAM albo w ogóle nie zostać doręczone.

W tym artykule omawiamy kluczowe kroki, które pozwolą zwiększyć skuteczność dostarczania poczty praktycznie do 100%. W pierwszej części skupimy się na problemach związanych z konfiguracją zapory sieciowej, a w drugiej podamy instrukcje dotyczące konfiguracji rekordów DNS. 

Informacje zawarte w poradniku dotyczą serwerów pocztowych działających na systemach z rodziny Linux. W przykładach wykorzystano Debian 12 oraz Rocky Linux 8.10 z panelem sterowania FASTPANEL.

Etap wstępny

Krok 1. Instalacja oprogramowania potrzebnego do diagnostyki

Do sprawdzenia wpisów i portów będą potrzebne następujące narzędzia:

  • dig - do analizy rekordów DNS.

  • lsof - do sprawdzania stanu serwera pocztowego.

  • netcat - do testowania dostępności portów.

  • whois - do sprawdzania aktualnego operatora DNS.

Instalacja w Debian/Ubuntu:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd lsof whois

W CentOS/AlmaLinux/Rocky Linux:

sudo yum install -y bind-utils nmap-ncat lsof whois

Dostępność portów pocztowych

informacja

Port to numeryczny identyfikator używany do adresowania usług działających na serwerze. Każdy serwis lub aplikacja „nasłuchuje” na określonym porcie, aby móc odbierać i wysyłać dane przez sieć (np. HTTP działa na porcie 80, a SMTP na porcie 25).

Aby wykonać dalsze kroki, połącz się z serwerem przez SSH jako użytkownik root, albo korzystaj z sudo tak jak w przedstawionych poleceniach. Jeśli potrzebujesz pomocy z połączeniem przez SSH, odsyłamy do naszego poradnika.

Krok 2. Sprawdzenie stanu serwerów pocztowych.

Zanim przejdziemy do testowania dostępności portów z sieci, trzeba upewnić się, że serwery pocztowe działają poprawnie. Za pocztę wychodzącą odpowiada zwykle Exim albo Postfix, natomiast za odbiór wiadomości - Dovecot.

Sprawdzisz to poleceniami:

sudo lsof -i:25
sudo lsof -i:143

Jeśli serwery działają, zobaczysz mniej więcej taki wynik:

Port 25:

COMMAND PID USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
exim    839 exim    4u  IPv6 778199358      0t0  TCP *:smtp (LISTEN)
exim    839 exim    5u  IPv4 778199359      0t0  TCP *:smtp (LISTEN)

Jeśli na twoim serwerze używany jest inny serwer SMTP, na przykład Postfix, w wynikach w pierwszej kolumnie zostanie podana jego dokładna nazwa zamiast exim. W razie potrzeby użyj jej w kolejnych poleceniach.

Port 143:

dovecot 859 root   39u  IPv4 778204692      0t0  TCP *:imap (LISTEN)
dovecot 859 root   40u  IPv6 778204693      0t0  TCP *:imap (LISTEN)

Taki wynik oznacza, że wszystko jest w porządku i możesz przejść dalej.

Jeśli serwery pocztowe nie są uruchomione, zobaczysz pusty wynik:

~ sudo lsof -i:25
~
~ sudo lsof -i:143
~

W takim przypadku wystąpił jakiś problem z serwerami pocztowymi i nie są one dostępne. Możesz spróbować uruchomić je ręcznie, a następnie sprawdzić status:

Debian/Ubuntu:

systemctl restart exim4 dovecot
systemctl status exim4
systemctl status dovecot

CentOS/AlmaLinux/Rocky Linux:

systemctl restart exim dovecot
systemctl status exim
systemctl status dovecot

Po uruchomieniu status usług będzie wyglądał następująco:

Exim:

● exim.service - Exim Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/exim.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2025-11-02 16:38:57 UTC; 57min ago
 Main PID: 839 (exim)
    Tasks: 1
   Memory: 11.0M
   CGroup: /system.slice/exim.service
           └─839 /usr/sbin/exim -bd -q1h

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Dovecot:

● dovecot.service - Dovecot IMAP/POP3 email server
   Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2025-11-02 16:38:58 UTC; 58min ago
     Docs: man:dovecot(1)
           https://doc.dovecot.org/
 Main PID: 859 (dovecot)
    Tasks: 5
   Memory: 9.5M
   CGroup: /system.slice/dovecot.service
           ├─ 859 /usr/sbin/dovecot -F
           ├─ 880 dovecot/anvil
           ├─ 881 dovecot/log
           ├─ 882 dovecot/config
           └─1729 dovecot/stats

W takiej sytuacji wszystko jest w porządku i możesz przejść do kolejnych kroków.

Jeśli jednak coś jest nie tak, zobaczysz to:

Exim:

● exim.service - Exim Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/exim.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2025-11-02 17:38:44 UTC; 3s ago
  Process: 839 ExecStart=/usr/sbin/exim -bd -q${QUEUE} (code=exited, status=0/SUCCESS)
 Main PID: 839 (code=exited, status=0/SUCCESS)

Dovecot:

● dovecot.service - Dovecot IMAP/POP3 email server
   Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2025-11-02 17:39:32 UTC; 3s ago
     Docs: man:dovecot(1)
           https://doc.dovecot.org/
  Process: 2278 ExecStop=/usr/bin/doveadm stop (code=exited, status=0/SUCCESS)
  Process: 859 ExecStart=/usr/sbin/dovecot -F (code=exited, status=0/SUCCESS)
 Main PID: 859 (code=exited, status=0/SUCCESS)

Przyczyny mogą być bardzo różne - błędna konfiguracja, uszkodzone logi, brak miejsca na dysku itd. W tym artykule nie będziemy zagłębiać się w diagnozowanie takich problemów.

Jeśli chcesz spróbować rozwiązać je samodzielnie, polecamy nasz poradnik o pracy z dziennikiem systemowym. Możesz też skontaktować się z pomocą techniczną swojego dostawcy hostingu. W kodu.cloud pracujemy 24/7 i odpowiadamy na zgłoszenia w ciągu kilku minut.

Krok 3. Sprawdzenie dostępności portów pocztowych z sieci publicznej

Aby poczta działała prawidłowo, następujące porty TCP muszą być dostępne z globalnej sieci:

  • 25, 465, 587 - wysyłanie poczty (SMTP)

  • 143, 993 - odbieranie poczty (IMAP)

Dostępność portów możesz sprawdzić za pomocą netcat:

nc -vz 1.2.3.4 25

Zamiast 1.2.3.4 wstaw prawdziwy adres IP swojego serwera.

Jeśli port jest otwarty, zobaczysz:

Debian/Ubuntu:

Connection to 1.2.3.4 25 port [tcp/smtp] succeeded!

CentOS/AlmaLinux/Rocky Linux:

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 1.2.3.4:25.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

Jeśli port jest zamknięty:

Debian/Ubuntu:

nc: connect to 1.2.3.4 port 25 (tcp) failed: Connection refused

CentOS/AlmaLinux/Rocky Linux:

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connection refused.

Wykonaj to polecenie dla wszystkich portów wymienionych na początku tej sekcji. Jeśli wszystkie są dostępne, przejdź do drugiej części tego artykułu. Jeśli nie, przejdź do kroku 4, aby to naprawić.

Krok 4. Otwarcie dostępu (opcjonalnie).

Na serwerach najczęściej stosuje się iptables lub UFW jako firewall blokujący niepożądane połączenia. Uruchom polecenie:

sudo ufw status

Jeśli zobaczysz:

-bash: ufw: command not found

Oznacza to, że używany jest iptables. Jeśli natomiast wynik zaczyna się od:

Status: active

Używany jest UFW.

Przejdź do odpowiedniego podrozdziału tego kroku zgodnie z wykorzystywanym firewallem.

warning

W systemach Linux istnieją również inne narzędzia do zarządzania firewallem, takie jak nftables czy firewalld, jednak w tym artykule nie będą one omawiane, aby uniknąć nadmiernego rozbudowania treści.

Iptables

warning

Wszystkie przykłady w tym rozdziale dotyczą tylko IPv4. Jeżeli twój serwer ma adres IPv6 i potrzebujesz udostępnić porty pocztowe w tej przestrzeni, powtórz polecenia używając ip6tables zamiast iptables.

Aby wyświetlić aktualne reguły, wpisz polecenie:

sudo iptables -L -v -n --line-numbers

Wynik będzie zależał od tego, jakie reguły zostały dodane wcześniej. Domyślnie firewall może być pusty, jednak wiele paneli hostingowych lub dystrybucji systemowych wprowadza własne ustawienia. Najczęściej spotkasz jeden z dwóch scenariuszy konfiguracji.

  1. Polityka „dozwolone wszystko, co nie jest zabronione” (policy ACCEPT).

W takim trybie firewall przepuszcza cały ruch, dopóki nie pojawi się reguła blokująca. Jest to częsta konfiguracja domyślna.

Przykład zestawu reguł, gdzie zablokowane są porty SSH i porty pocztowe:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       51  5637 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 22
2        0     0 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 25,143,993,587,465

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 25,143,993,587,465

W tym przykładzie:

  • Policy ACCEPT oznacza, że cały ruch jest akceptowany domyślnie,

  • Chain INPUT (połączenia przychodzące): blokowane są nowe połączenia na port 22 (SSH) oraz wszystkie porty pocztowe (SMTP: 25, 465, 587; IMAP: 143; IMAPS: 993).

  • Chain OUTPUT (połączenia wychodzące): blokowane są pakiety wychodzące do tych samych portów.

Numer porządkowy reguły jest podany na początku wiersza (num). Jeśli chcesz usunąć, na przykład, regułę blokującą porty pocztowe w łańcuchu przychodzącym INPUT (numer 2), polecenie będzie wyglądało następująco:

sudo iptables -D INPUT 2

Gdzie:

  • -D — to polecenie służące do usunięcia reguły.

  • INPUT — ciąg, z którego usuwamy regułę (w tym przypadku ruch przychodzący).

  • 2 — numer wiersza, w którym znajduje się reguła, którą należy usunąć.

Analogicznie, aby usunąć blokadę portów wychodzących z tego przykładu, należy wykonać:

sudo iptables -D OUTPUT 1  
warning

Numery wierszy w wynikach iptables -L -v -n --line-numbers mogą się zmieniać, jeśli usuwasz lub dodajesz inne. Dlatego jeśli dodałeś nowe reguły, numery wierszy mogą się przesunąć. Aby uniknąć błędów, przed usunięciem zawsze sprawdzaj aktualne numery wierszy.

Następnie, aby upewnić się, że wszystko jest w porządku, ponownie wykonaj polecenie:

iptables -L -v -n --line-numbers

W wynikach nie powinno być reguł blokujących działanie portów pocztowych:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       51  5637 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Jeśli reguły nadal są obecne, sprawdź poprawność wprowadzonych poleceń oraz numery linii.

Po każdej modyfikacji reguł firewalla koniecznie zapisz zmiany, w przeciwnym razie zostaną utracone po restarcie systemu. Aby zapisać aktualny zestaw reguł w iptables, wykonaj polecenie:

Debian/Ubuntu:

iptables-save > /etc/iptables/rules.v4

CentOS/AlmaLinux/Rocky Linux:

iptables-save > /etc/sysconfig/iptables

Po zapisaniu sprawdź ponownie dostępność portów, tak jak w kroku 3. Jeśli dalej są zablokowane, przejdź do kroku 5. Jeśli są otwarte, przejdź do drugiej części tego artykułu.

2. Polityka „blokowanie wszystkiego, co nie jest dozwolone” (policy DROP).

Ten typ konfiguracji jest znacznie bardziej rygorystyczny. Wszystkie porty i protokoły są domyślnie blokowane, a ruch może przejść wyłącznie wtedy, gdy konkretny port został jawnie dopuszczony. To bezpieczniejsze i często zalecane podejście, szczególnie, jeśli zależy ci na maksymalnym ograniczeniu ryzyka.

Przykład reguł dla takiej konfiguracji:

Chain INPUT (policy DROP 306 packets, 17962 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       92 12474 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2      466 32947 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 197 packets, 29192 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       44 10332 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

W tym przykładzie:

  • Chain INPUT (połączenia przychodzące): obowiązuje polityka DROP, czyli wszystkie pakiety są domyślnie blokowane, z wyjątkiem tych, które mają dodane reguły zezwalające.

Reguła 1: ACCEPT state RELATED,ESTABLISHED - zezwala na pakiety przychodzące powiązane z już istniejącymi połączeniami. To ważne, bo umożliwia serwerowi prawidłowe odbieranie odpowiedzi na nawiązane wcześniej połączenia (np. SSH, poczta, zapytania DNS). Reguła 2: ACCEPT tcp dpt:22 - zezwala na nowe połączenia przychodzące na port 22 (SSH).

  • Chain OUTPUT (połączenia wychodzące): polityka DROP, czyli blokada całego ruchu wychodzącego.

Reguła 1: ACCEPT state RELATED,ESTABLISHED — zezwala na pakiety wychodzące związane z już istniejącymi połączeniami. Dzięki temu serwer może odpowiadać klientom (np. SSH, połączenia pocztowe) i utrzymywać stabilny ruch sieciowy.

Naturalnie więc, w tej konfiguracji nie ma żadnych reguł zezwalających na ruch dotyczący portów pocztowych. Aby je dodać, wykonaj następujące polecenia:

sudo iptables -A INPUT -p tcp -m multiport --dports 25,465,587,143,993 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp -m multiport --dports 25,465,587,143,993 -m state --state NEW,ESTABLISHED -j ACCEPT

Następnie zapisz konfigurację:

Debian/Ubuntu:

iptables-save > /etc/iptables/rules.v4

CentOS/AlmaLinux/Rocky Linux:

iptables-save > /etc/sysconfig/iptables

Po zapisaniu sprawdź ponownie dostępność portów, tak jak w kroku 3. Jeśli dalej są zablokowane, przejdź do kroku 5. Jeśli są otwarte, przejdź do drugiej części tego artykułu.

UFW (Uncomplicated Firewall)

Na niektórych serwerach zamiast iptables używany jest UFW - uproszczony interfejs do konfiguracji firewalla. Świetnie nadaje się do podstawowej konfiguracji serwera pocztowego i często spotyka się go na Ubuntu oraz Debianie.

Aby sprawdzić, czy UFW jest włączony i jakie reguły są aktywne, wykonaj:

sudo ufw status verbose

Przykładowy wynik:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip

Gdzie:

  • Default: deny (incoming) - domyślnie wszystkie połączenia przychodzące są blokowane.

  • Default: allow (outgoing) - domyślnie wszystkie połączenia wychodzące są dozwolone.

Aby serwer pocztowy działał prawidłowo, musisz otworzyć standardowe porty. Wykonaj kolejno:

sudo ufw allow 25/tcp
sudo ufw allow 465/tcp
sudo ufw allow 587/tcp
sudo ufw allow 143/tcp
sudo ufw allow 993/tcp

Jeśli masz również ograniczenia dla ruchu wychodzącego, to dla poczty wychodzącej trzeba zezwolić na porty SMTP:

sudo ufw allow out 25/tcp
sudo ufw allow out 465/tcp
sudo ufw allow out 587/tcp

Po dodaniu reguł możesz ponownie je zweryfikować:

sudo ufw status numbered

Zobaczysz listę reguł ponumerowanych kolejno. Jeśli potrzebujesz jakąś usunąć, użyj numeru z listy:

sudo ufw delete 3

W UFW reguły są zapisywane automatycznie, więc po restarcie serwera nadal będą aktywne.

Po zapisaniu sprawdź ponownie dostępność portów, tak jak w kroku 3. Jeśli dalej są zablokowane, przejdź do kroku 5. Jeśli są otwarte, przejdź do drugiej części tego artykułu.

Krok 5. W firewall wszystko działa, ale porty pocztowe nadal są zablokowane (opcjonalnie)

Jeśli porty wciąż są niedostępne mimo prawidłowych reguł na serwerze, oznacza to, że blokada jest zastosowana na poziomie infrastruktury hostingodawcy. W takiej sytuacji utwórz zgłoszenie do pomocy technicznej z prośbą o odblokowanie portów pocztowych. Jeśli nie ma takiej możliwości, jedynym rozwiązaniem jest zmiana dostawcy.

W kodu.cloud nie blokujemy portów pocztowych. Zakazane są jedynie masowe wysyłki, natomiast zwykła poczta działa bez ograniczeń. Nie musisz nawet konfigurować serwera pocztowego, ponieważ wszyscy nasi klienci mają bezpłatny dostęp do panelu sterowania FASTPANEL z rozszerzoną licencją. Zamów serwer i już po kilku minutach zacznij korzystać z poczty na własnej domenie.

Następne kroki dotyczące konfiguracji rekordów DNS znajdziesz w drugiej części tego artykułu.

Czym jest rekord PTR i dlaczego nie można ustawić go samodzielnie?

· 2 min aby przeczytać
Customer Care Engineer

ptr-record-co-to-jest-i-jak-skonfigurować

Wprowadzenie

Jeśli kiedykolwiek konfigurowałeś serwer pocztowy lub miałeś do czynienia z odwrotną weryfikacją DNS, prawdopodobnie spotkałeś się z rekordami PTR. Ale czym one właściwie są? Dlaczego często nie można samodzielnie skonfigurować rekordów PTR? Przyjrzyjmy się temu bliżej!

Co to jest rekord PTR?

PTR (Pointer) — to typ rekordu DNS, który umożliwia konwersję adresu IP na odpowiadającą mu nazwę domeny. W przeciwieństwie do standardowych rekordów A, które mapują domenę na adres IP, rekordy PTR wskazują, do jakiej domeny przypisany jest dany adres IP.

Jak działa rekord PTR?

Gdy serwer odbiera połączenie przychodzące, może zapytać odwrotny DNS (rDNS) o adres IP nadawcy. Jeśli rekord PTR jest skonfigurowany, otrzyma odpowiednią nazwę domeny. Jest to ważne dla:

  • Konfigurowania serwerów pocztowych (serwery SMTP często wymagają PTR, aby poprawnie wysyłać wiadomości e-mail i nie zostać wrzuconym do spamu);
  • Rozpoznawania adresów IP w logach i zwiększenia bezpieczeństwa;
  • poprawnego działania niektórych usług zależnych od rDNS.

Dlaczego nie mogę samodzielnie skonfigurować rekordu PTR?

Wielu użytkowników, którzy mają dostęp do zarządzania rekordami DNS, oczekuje, że będą w stanie utworzyć rekord PTR, tak jak rekord A lub CNAME. Jednak tu pojawia się kluczowy problem: Rekordy PTR nie są konfigurowane w hostingu DNS, lecz u dostawcy adresu IP (ISP, centrum danych lub dostawcy usług hostingowych).

Główne powody:

  1. Kontrola nad adresem IP – Rekordy PTR należą do właściciela puli adresów IP. Jeśli korzystasz z serwera dedykowanego lub VPS, właścicielem adresu IP jest twój dostawca hostingu, który powinien skonfigurować rekord PTR.
  2. Brak dostępu do zarządzania rDNS – Nawet jeśli masz pełną kontrolę nad DNS swojej domeny, odwrotna strefa DNS (in-addr.arpa) jest zarządzana przez właściciela zakresu IP.
  3. Wymagania dostawcy – Niektórzy dostawcy hostingu pozwalają na konfigurację PTR wyłącznie poprzez zgłoszenie do pomocy technicznej, a nie poprzez panel sterowania.
  4. Dynamiczne adresy IP – Jeśli twój adres IP jest dynamiczny (np. w domowym połączeniu internetowym), twój dostawca prawdopodobnie nie pozwoli ci ustawić własnego rekordu PTR.

Jak skonfigurować rekord PTR?

1. Skontaktuj się z dostawcą

Aby stworzyć lub zmienić rekord PTR, należy skontaktować się z dostawcą hostingu lub ISP, który przypisał ci adres IP. Zwykle robi się to poprzez zgłoszenie do pomocy technicznej.

2. Podaj odpowiednią domenę

Zazwyczaj dostawca wymaga, aby rekord PTR wskazywał na rzeczywistą domenę, która jest już skonfigurowana i rozwiązana w rekordzie A.

3. Sprawdź konfigurację

Po zmianie rekordu PTR warto sprawdzić jego działanie za pomocą poniższej komendy:

Windows:

nslookup 123.123.123.123

Linux i MacOS:

dig -x 123.123.123.123
notatka

Powyższe adresy IP są przykładowe. W celu weryfikacji należy użyć rzeczywistego adresu IP, dla którego zmieniono rekord PTR.

Podsumowanie

Rekord PTR jest kluczowym elementem DNS, zwłaszcza dla serwerów pocztowych. Niemniej jednak, nie można go skonfigurować bez zgody właściciela adresu IP. Jeśli potrzebujesz utworzyć rekord PTR, skontaktuj się ze swoim dostawcą usług hostingowych, aby sprawdzić, czy istnieje możliwość jego konfiguracji. Prawidłowe ustawienie rekordu pomoże uniknąć problemów z dostarczaniem wiadomości e-mail i zwiększy wiarygodność twojego serwera.