Wysyłka maili z aplikacji self-hosted przez SMTP relay

Jakie aplikacje self-hosted wymagają wysyłki poczty

Do wysyłki poczty z aplikacji self-hosted nie jest potrzebny własny serwer pocztowy. Wymagany jest przekaźnik (relay): jedno uwierzytelnione konto SMTP, skonfigurowane raz na hoście, któremu każda aplikacja na serwerze przekazuje wychodzącą korespondencję. Prowadzenie własnej skrzynki pocztowej to trudne zadanie i zupełnie inny problem.

Odbieranie poczty oznacza akceptowanie połączeń z całego Internetu na porcie 25, filtrowanie spamu, przechowywanie i tworzenie kopii zapasowych skrzynek oraz dbanie o reputację adresu IP przez cały czas działania serwera. To zadanie stało się znacznie trudniejsze. Wysyłanie poczty obejmuje powiadomienia o zresetowaniu hasła, potwierdzenia rejestracji, alerty o nieudanej kopii zapasowej czy powiadomienia o odpowiedziach na forum. Są to krótkie wiadomości o niskim wolumenie, wysyłane pojedynczo. Przekaźnik obsługuje je bez problemu, a jego konfiguracja zajmuje jedno popołudnie.

Należy zdecydować, który z tych dwóch problemów faktycznie wymaga rozwiązania. Czy prowadzenie własnej skrzynki pocztowej nadal ma sens to realne pytanie, na które istnieje konkretna odpowiedź, a dla większości osób brzmi ona: nie. Jeśli odpowiedź brzmi tak, pełny serwer pocztowy Mailcow na VPS jest właściwą drogą. Druga część, czyli wysyłka, jest tym, czego potrzebuje niemal każdy, a o czym prawie nikt nie myśli zawczasu.

Najpierw dwa terminy. SMTP (simple mail transfer protocol) to protokół używany w każdym z tych procesów. Przekaźnik, nazywany również smarthost, to serwer, który przyjmuje uwierzytelnioną pocztę i dostarcza ją dalej, używając własnych adresów oraz własnej reputacji.

Dlaczego Twój VPS nie może wysyłać poczty na porcie 25

Prawie każdy dostawca VPS domyślnie blokuje wychodzący port TCP 25. Port 25 jest używany przez serwery pocztowe do komunikacji między sobą, więc przejęty serwer VPS z otwartym portem 25 może wysyłać spam bezpośrednio do każdego serwera pocztowego odbiorcy. Dostawcy odrzucają takie pakiety zamiast odmawiać ich przyjęcia, dlatego objawem jest połączenie, które zawiesza się, a następnie przekracza limit czasu, zamiast zwracać błąd.

Przetestuj to z poziomu serwera:

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.relay.example 587

Jeśli pierwsze polecenie oczekuje przez pełne pięć sekund, podczas gdy drugie odpowiada natychmiast, blokada jest potwierdzona. Niektórzy dostawcy zdejmują ją po weryfikacji konta. Większość tego nie robi.

Blokada nie jest głównym powodem korzystania z przekaźnika (relay). Nawet przy otwartym porcie 25, poczta wysłana bezpośrednio z nowego adresu IP serwera VPS trafia do spamu lub jest od razu odrzucana, ponieważ ten adres nie ma historii wysyłkowej i znajduje się w puli traktowanej przez odbiorców jako przestrzeń hostingowa. Wytyczne Google dla nadawców wymagają poprawnego rekordu DNS typu forward i reverse dla adresu IP nadawcy, a wiele adresów VPS posiada ogólny rekord PTR (pointer), którego nie można zmienić. Przekaźnik zapewnia adresy, które posiadają już wyrobioną historię.

Porty zgłoszeniowe (submission ports) są rozwiązaniem tego problemu. Port 587 obsługuje STARTTLS, gdzie sesja rozpoczyna się tekstem jawnym i jest następnie szyfrowana. Port 465 obsługuje implicit TLS (transport layer security), gdzie sesja jest szyfrowana od pierwszego bajtu. Oba są przeznaczone dla uwierzytelnionych klientów, oba są otwarte w sieciach VPS, a Twój przekaźnik obsługuje przynajmniej jeden z nich.

Wybór przekaźnika i subdomeny nadawczej

Istnieje wielu dostawców poczty transakcyjnej, a wszyscy wykonują to samo zadanie. Należy oceniać ich pod kątem czterech kryteriów:

• portu przesyłania, 587 lub 465, z obsługą SMTP AUTH
• podpisywania DKIM przy użyciu własnej domeny i własnego selektora, a nie tylko danych dostawcy
• danych o zwrotach (bounce) i skargach, które można odczytać za pomocą panelu lub webhooka
• planu cenowego dopasowanego do wolumenu. Według stanu na sierpień 2026 r. kilku dostawców nadal oferuje kilka tysięcy wiadomości miesięcznie bezpłatnie, a warunki te często ulegają zmianie, dlatego należy zapoznać się z aktualną stroną cennika, zamiast polegać na wpisach na blogach

Wysyłaj pocztę z aplikacji z subdomeny. Użyj czegoś w rodzaju notify.example.com zamiast example.com. Odbiorcy oceniają reputację w podziale na domeny, więc nieudana wysyłka z aplikacji nie wpłynie na domenę, z której wysyłane są faktury i poczta zespołu. Należy mieć świadomość ograniczeń: niektórzy odbiorcy agregują sygnały z subdomen do domeny głównej, więc subdomena jedynie ogranicza skalę problemu, a nie izoluje go całkowicie.

Skonfiguruj przekaźnik raz dla każdej własnej aplikacji

Kuszącym podejściem jest otwarcie strony ustawień każdej aplikacji i wklejenie tam hosta SMTP, nazwy użytkownika oraz hasła. Nextcloud, forum, Grafana, Vaultwarden i monitor dostępności posiadają takie formularze. Jeśli to zrobisz, poświadczenia znajdą się w sześciu miejscach, w sześciu formatach, z czego kilka wewnątrz bazy danych, którą tworzysz jako kopię zapasową danych, a nie konfiguracji. Przy zmianie hasła będziesz musiał zaktualizować pięć z nich. Szóste przestanie wysyłać wiadomości i zrobi to po cichu, ponieważ większość aplikacji loguje błąd SMTP po stronie serwera, a użytkownikowi nadal wyświetla stronę sukcesu.

Zamiast tego skonfiguruj przekaźnik raz na hoście i pozwól aplikacjom wysyłać pocztę lokalnie. Dwa narzędzia radzą sobie z tym dobrze, a wybór między nimi zależy od kolejkowania.

msmtp to klient zgodny z sendmail, który nie posiada demona. Łączy się, wysyła i kończy działanie. Nie posiada kolejki, więc jeśli przekaźnik jest nieosiągalny, wiadomość przepada, a aplikacja wywołująca otrzymuje niezerowy kod wyjścia.

Postfix skonfigurowany jako satelita to pełnoprawny agent transferu poczty (MTA) z prawdziwą kolejką. Przyjmuje wiadomość natychmiast, w razie awarii ponawia próby przez wiele dni i przechowuje poświadczenia przekaźnika w pliku dostępnym tylko dla root. Użyj go, gdy utrata powiadomienia podczas awarii przekaźnika jest istotna lub gdy kilka aplikacji działa jako różni użytkownicy systemowi.

msmtp, opcja lekka

sudo apt update
sudo apt install -y msmtp msmtp-mta ca-certificates

msmtp-mta instaluje dowiązanie symboliczne /usr/sbin/sendmail, więc wszystko, co wywołuje sendmail, trafia do msmtp, nawet o tym nie wiedząc.

Utwórz /etc/msmtprc:

defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          on

account         relay
host            smtp.relay.example
port            587
from            apps@notify.example.com
set_from_header on
user            <relay username>
password        <relay password>

account default : relay

set_from_header on zawsze ustawia nagłówek From i nadpisuje każdy istniejący, więc zastępuje wszystko, co wygenerowała aplikacja, adresem w from. Bez tego zadanie cron wysyła pocztę jako root@your-hostname, a przekaźnik odrzuci ją, ponieważ nie jest to zweryfikowany adres. syslog on wysyła logi przez syslog, więc odczytasz je za pomocą journalctl -t msmtp. Alternatywą jest współdzielona ścieżka logfile, która wymaga uprawnień do zapisu dla każdego użytkownika wysyłającego pocztę, co na systemie wieloużytkownikowym jest pułapką.

Ustaw uprawnienia samodzielnie. msmtp wymusza uprawnienia dla konfiguracji użytkownika (~/.msmtprc), odmawiając działania przy contains secrets and therefore must have no more than user read/write permissions. Nie wymusza niczego dla /etc/msmtprc, ponieważ po prostu ładuje ten plik, jeśli jest czytelny.

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc
printf 'Subject: relay test\n\nsent from the host\n' | sudo sendmail -v you@example.com

-v drukuje całą konwersację SMTP, dzięki czemu widzisz każdą odpowiedź przekaźnika. Udane wysłanie kończy się odpowiedzią 250 akceptującą wiadomość. Linia authentication failed oznacza, że nazwa użytkownika lub hasło są błędne, albo przekaźnik oczekuje klucza API zamiast hasła do konta.

Oto haczyk, który sprawia, że wiele osób wybiera Postfix. Przy trybie 600 i właścicielu root, tylko root może wysyłać pocztę. Aplikacja działająca jako www-data nie może odczytać pliku, msmtp pomija go, a aplikacja kończy się błędem o braku domyślnego konta. Rozwiązaniem jest grupa:

sudo chgrp mail /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo usermod -aG mail www-data

Powiedzmy to jasno: każdy członek grupy mail może odczytać hasło przekaźnika i wysyłać pocztę jako Twoja domena z tego serwera. Na VPS, którym zarządzasz samodzielnie, jest to akceptowalne. Tam, gdzie kilka aplikacji, których nie napisałeś, działa jako różni użytkownicy, nie jest to bezpieczne i Postfix jest lepszą odpowiedzią, ponieważ te aplikacje nigdy nie widzą poświadczeń.

Postfix jako satelita

sudo debconf-set-selections <<'EOF'
postfix postfix/main_mailer_type select Satellite system
postfix postfix/mailname string notify.example.com
postfix postfix/relayhost string [smtp.relay.example]:587
EOF
sudo DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules

libsasl2-modules nie jest opcjonalne. Bez tego Postfix loguje warning: SASL authentication failure: No worthy mechs found, ponieważ biblioteki mechanizmów PLAIN i LOGIN nie są zainstalowane w /usr/lib/sasl2.

Ustaw resztę za pomocą postconf -e, który edytuje /etc/postfix/main.cf w miejscu:

sudo postconf -e 'relayhost = [smtp.relay.example]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'inet_interfaces = loopback-only'

Nawiasy kwadratowe wokół nazwy hosta przekaźnika powstrzymują Postfix przed wyszukiwaniem rekordu MX dla tej nazwy i zmuszają go do połączenia bezpośrednio z nią. Niektóre nazwy hostów przekaźników publikują rekordy MX wskazujące gdzie indziej, a bez nawiasów poczta podąży za nimi na niewłaściwy serwer.

smtp_tls_security_level = encrypt czyni TLS obowiązkowym, więc wiadomość nigdy nie jest wysyłana otwartym tekstem. Nie weryfikuje certyfikatu. Dokumentacja Postfix jest w tej kwestii jednoznaczna: na tym poziomie dostarczanie trwa nawet wtedy, gdy certyfikat serwera jest niezaufany lub ma błędną nazwę. Jeśli chcesz sprawdzić certyfikat, użyj verify lub secure i zachowaj ustawienie smtp_tls_CAfile.

Poświadczenia trafiają do jednego pliku dostępnego tylko dla root:

echo '[smtp.relay.example]:587 relay-username:relay-password' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap hash:/etc/postfix/sasl_passwd
sudo systemctl restart postfix

postmap buduje indeksowaną kopię, którą Postfix faktycznie odczytuje. Jeśli edytujesz plik tekstowy i zapomnisz o postmap, Postfix będzie nadal używał starej bazy danych, nie informując o tym w logach. W Postfix 3.9 i nowszych domyślnym typem mapy jest lmdb, więc wpisz lmdb: zarówno w parametrze, jak i w argumencie postmap, jeśli wolisz ten format. Nazwanie typu w obu liniach zapewnia ich zgodność.

Aplikacje nadal adresują swoją pocztę jako root@hostname. Przepisz nadawcę:

echo '/.+/    apps@notify.example.com' | sudo tee /etc/postfix/sender_canonical
sudo postconf -e 'sender_canonical_classes = envelope_sender, header_sender'
sudo postconf -e 'sender_canonical_maps = regexp:/etc/postfix/sender_canonical'
sudo systemctl reload postfix

Tabela regexp: jest odczytywana bezpośrednio, więc nie wymaga postmap. Każda wiadomość opuszcza teraz serwer z tym samym nadawcą koperty i tym samym nagłówkiem From, czego wymaga przekaźnik. Kosztem jest to, że odpowiedzi trafiają w jedno miejsce, więc ustaw nagłówek Reply-To wewnątrz każdej aplikacji, jeśli odpowiedzi powinny docierać do konkretnej osoby.

Wyślij test i odczytaj log:

printf 'Subject: postfix relay test\n\nsent through the queue\n' | sendmail you@example.com
sudo tail -n 20 /var/log/mail.log

Dostarczona wiadomość loguje status=sent, a po niej odpowiedź przekaźnika w nawiasach. Wszystko inne wskazuje przyczynę błędu. status=deferred z Connection timed out oznacza, że coś nadal jest skierowane na port 25. Host or domain name not found. Name service error for name=smtp.relay.example type=A oznacza, że nazwa hosta przekaźnika jest błędna lub DNS na serwerze nie działa. mailq wyświetla listę zablokowanych wiadomości, a sudo postqueue -f ponawia ich wysyłkę natychmiast.

Dostęp do przekaźnika hosta z kontenerów Docker

Kontener nie może wywołać sendmail hosta, ponieważ plik binarny nie znajduje się w obrazie, a kolejka nie jest współdzielona. Należy wskazać kontenerom cel sieciowy. Postfix może nasłuchiwać na adresie mostka Docker.

ip -4 addr show docker0
sudo postconf -e 'inet_interfaces = 127.0.0.1, 172.17.0.1'
sudo postconf -e 'mynetworks = 127.0.0.0/8 172.17.0.0/16'
sudo systemctl restart postfix

Odczytaj własny adres mostka za pomocą pierwszego polecenia, zamiast kopiować poniższe, ponieważ projekt Compose tworzy własną sieć w innej podsieci, a docker network inspect <name> wyświetla ją. Użyj restart, a nie reload w tym miejscu: dokumentacja Postfix wskazuje, że po zmianie inet_interfaces należy zatrzymać i uruchomić usługę, a polecenie reload nie uwzględni tej zmiany. Każda aplikacja otrzymuje wtedy host SMTP 172.17.0.1, port 25, bez uwierzytelniania i bez TLS, ponieważ ten ruch nigdy nie opuszcza hosta. Jeśli usługi znajdują się w sieci Compose, uruchamianie Docker Compose na VPS wyjaśnia, skąd pochodzi ta podsieć.

To jest krok, który może być ryzykowny. Postfix nasłuchujący na publicznym adresie z szerokim zakresem mynetworks staje się otwartym przekaźnikiem (open relay): osoby niepowołane wysyłają pocztę przez Twoje konto, dostawca zawiesza usługę, a reputacja domeny zostaje uszkodzona na miesiące. Po każdej zmianie sprawdź obie strony.

ss -tlnp | grep ':25'

Dane wyjściowe muszą zawierać wyłącznie adres pętli zwrotnej (loopback) oraz adres mostka. Z innej maszyny polecenie nc -vz your.server.ip 25 musi zakończyć się niepowodzeniem.

SPF, DKIM oraz DMARC dla domeny wysyłającej

Opublikuj wszystkie trzy rekordy przed pierwszą rzeczywistą wysyłką. Są one darmowe, stanowią część DNS i są sprawdzane przez odbiorców w pierwszej kolejności.

SPF (sender policy framework) określa, kto może umieścić Twoją domenę w polu nadawcy koperty (envelope sender). Opublikuj go dla subdomeny wysyłającej:

notify.example.com.  IN  TXT  "v=spf1 include:_spf.relay.example -all"

Skopiuj wartość include: ze strony konfiguracji swojego przekaźnika (relay), ponieważ dyrektywa include, która nie ulega rozwiązaniu, powoduje błąd permanentny zamiast pozytywnej weryfikacji. Ewaluacja SPF kończy się po dziesięciu mechanizmach wymagających zapytania DNS i zwraca permerror, co odbiorcy traktują jako błąd, dlatego ogranicz liczbę wpisów include. Opublikuj dokładnie jeden rekord v=spf1 dla danej nazwy: posiadanie dwóch rekordów również skutkuje błędem permerror.

DKIM (domainkeys identified mail) podpisuje każdą wiadomość kluczem prywatnym przechowywanym przez przekaźnik, a odbiorcy pobierają pasujący klucz publiczny z DNS. Twój przekaźnik udostępni Ci selektor oraz rekord TXT lub CNAME do publikacji:

sel1._domainkey.notify.example.com.  IN  CNAME  sel1.dkim.relay.example.

DKIM jest ważniejszy niż SPF, ponieważ DKIM przetrwa przekierowanie wiadomości. Gdy lista mailingowa lub reguła .forward przekazuje Twoją wiadomość dalej, dociera ona z adresu IP serwera przekazującego, przez co SPF kończy się niepowodzeniem, podczas gdy podpis nadal jest weryfikowany poprawnie.

DMARC (domain-based message authentication, reporting and conformance) informuje odbiorców, co należy zrobić, gdy żadna z weryfikacji nie jest zgodna, oraz prosi o przesyłanie raportów. Opublikuj go dla domeny organizacyjnej:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Zacznij od p=none i analizuj raporty przez dwa tygodnie. p=none nie zmienia niczego w dostarczalności, jedynie aktywuje raportowanie, co pozwala zidentyfikować systemy, o których zapomniałeś, a które wysyłają wiadomości w imieniu Twojej domeny. Następnie przejdź do p=quarantine, a docelowo do p=reject. Publikacja p=reject pierwszego dnia to najczęstszy sposób, w jaki administratorzy odkrywają, że ich system fakturowania wysyłał wiadomości jako domena, dowiadując się o tym od klienta, który nie otrzymał faktury.

Sprawdź, co widzi świat, a nie to, co wyświetla Twój panel DNS:

dig +short TXT notify.example.com
dig +short TXT sel1._domainkey.notify.example.com
dig +short TXT _dmarc.example.com

Pusty wynik oznacza, że rekord nie został jeszcze rozpropagowany lub nazwa jest błędna. Rekord poprawiony pięć minut temu może pozostawać błędny w pamięciach podręcznych przez czas trwania poprzedniego TTL (time to live), dlatego sprawdź wartość TTL przed wyciągnięciem wniosków.

Zapewnienie zgodności pól From oraz Return-Path

Każda wiadomość zawiera dwa adresy nadawcy, które są weryfikowane w odmienny sposób. Nadawca koperty (envelope sender) jest przekazywany w poleceniu SMTP MAIL FROM i pojawia się w dostarczonej wiadomości jako Return-Path. Nagłówek From to adres widoczny dla odbiorcy.

Mechanizm SPF sprawdza domenę nadawcy koperty względem adresu IP nawiązującego połączenie. DKIM wskazuje domenę, która podpisała wiadomość, jako d=. DMARC przechodzi pomyślnie tylko wtedy, gdy przynajmniej jedna z tych dwóch domen jest zgodna z domeną w nagłówku From. Przy zgodności typu relaxed (adkim=r, aspf=r, co jest ustawieniem domyślnym), subdomena jest uznawana za zgodną, więc nadawca koperty w notify.example.com jest zgodny z nagłówkiem From w example.com. Przy zgodności typu strict taka relacja nie występuje.

Praktyczna zasada jest krótka: należy używać tej samej domeny w nagłówku From oraz dla nadawcy koperty, co eliminuje problem. Dokładnie to robi set_from_header on w msmtp oraz sender_canonical_maps w Postfix.

Werdykt można odczytać w dostarczonej wiadomości. W Gmailu opcja "Show original" wyświetla nagłówek zapisany przez odbiorcę:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@notify.example.com;
       spf=pass (google.com: domain of apps@notify.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=apps@notify.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Wszystkie trzy testy kończą się tam powodzeniem. Każdy inny wynik wskazuje nazwę nieudanego testu oraz zazwyczaj przyczynę, co stanowi najszybszą metodę debugowania w tym zakresie.

Odrzucenia i skargi przed zwiększeniem wolumenu wysyłki

Odrzucenie (bounce) występuje, gdy odbiorca odmawia przyjęcia wiadomości. Odrzucenie typu hard bounce jest trwałe, a Gmail określa je jako 550 5.1.1 The email account that you tried to reach does not exist. Odrzucenie typu soft bounce jest tymczasowe, kod 4xx oznacza pełną skrzynkę lub greylisting, a przekaźnik (relay) ponowi próbę automatycznie.

Przekaźniki mierzą wskaźnik odrzuceń typu hard bounce i zawieszają konta, które wysyłają wiadomości na nieistniejące adresy, ponieważ taki schemat jest typowy dla zakupionych baz mailingowych. Skargi mają większe znaczenie. Skarga to sytuacja, w której użytkownik naciska przycisk zgłoszenia spamu. Wytyczne Google dla nadawców (stan na sierpień 2026) zalecają utrzymywanie wskaźnika spamu poniżej 0,30% według raportów w Postmaster Tools, przy czym rekomendowana wartość to poniżej 0,10%.

Cztery elementy, które należy wdrożyć przed zwiększeniem wolumenu wysyłki:

• webhook lub cotygodniowy przegląd listy suppression list przekaźnika, aby monitorować odrzucenia
• adres From, który jest aktywną skrzynką pocztową, z ustawionym nagłówkiem Reply-To wskazującym miejsce odbioru odpowiedzi
• potwierdzenie przed dodaniem jakiegokolwiek adresu do bazy, aby uniknąć wysyłki na adresy, których właściciele nie wyrazili na to zgody
• limit szybkości (rate limit) dla każdego formularza wyzwalającego wysyłkę wiadomości

Dwa ostatnie punkty są miejscami, w których najczęściej zawodzą aplikacje hostowane samodzielnie. Niezabezpieczony formularz rejestracyjny pozwala każdemu wpisać adres osoby trzeciej; serwer wysyła potwierdzenie, a odbiorca oznacza je jako spam. Zatrzymywanie ataków typu subscription bombing w formularzu rejestracyjnym to zadanie z zakresu dostarczalności poczty, tak samo ważne jak ochrona przed nadużyciami.

Nie należy wysyłać masowej korespondencji tą samą ścieżką. Newslettery wymagają zarządzania listami i nagłówków rezygnacji z subskrypcji, których nie posiada poczta transakcyjna, dlatego należy je obsługiwać przez samodzielnie hostowaną instancję Listmonk w osobnej subdomenie z własną reputacją. Powiadomienia z samodzielnie hostowanego forum znajdują się pomiędzy tymi kategoriami – mają charakter transakcyjny, ale duży wolumen i zazwyczaj jako pierwsze pokazują, czy konfiguracja jest poprawna.

Dla celów referencyjnych: zasady Gmaila dla masowych nadawców mają zastosowanie powyżej 5000 wiadomości dziennie do adresów w domenie Gmail i wymagają SPF, DKIM, DMARC oraz opcji rezygnacji z subskrypcji jednym kliknięciem w przypadku poczty marketingowej. Większość samodzielnie hostowanych aplikacji nigdy nie osiąga tego progu. Uwierzytelnianie jest obecnie wymagane od każdego nadawcy bez względu na wolumen.

Przetestuj, zanim zaufasz

swaks jest narzędziem przeznaczonym do tego celu. Obsługuje protokół SMTP i wyświetla pełną komunikację, co pozwala zidentyfikować etap, na którym wystąpił błąd.

sudo apt install -y swaks
swaks --to you@example.com --from apps@notify.example.com --server smtp.relay.example --port 587 --tls --auth-user '<relay username>' --auth-password '<relay password>'

Powyższa komenda testuje poświadczenia bezpośrednio względem przekaźnika. Aby przetestować ścieżkę, z której faktycznie korzystają aplikacje, należy wskazać hosta przekaźnika:

swaks --to you@example.com --from apps@notify.example.com --server 127.0.0.1

Następnie należy sprawdzić wynik w modelu end-to-end, z poziomu serwera, wysyłając rzeczywistą wiadomość. Poprawności nie można potwierdzić wyłącznie na podstawie plików konfiguracyjnych, dlatego należy przeprowadzić testy samodzielnie:

• wyślij wiadomość do serwisu oceniającego, takiego jak mail-tester.com, który analizuje rekordy SPF, DKIM, DMARC oraz treść wiadomości i przedstawia przyczyny przyznanej punktacji
• wyślij wiadomość na skrzynki u dwóch dostawców, z których faktycznie korzystają użytkownicy, a następnie sprawdź Authentication-Results w surowej treści wiadomości
• przeanalizuj wiadomość w serwisie learndmarc.com, jeśli wynik wyrównania (alignment) nie jest jednoznaczny
• wyzwól wysyłkę z poziomu samej aplikacji, a nie tylko z wiersza poleceń, ponieważ to aplikacja definiuje nagłówek From

Na zakończenie jedno szczere ostrzeżenie. Nowa domena, nawet z poprawnie skonfigurowanymi wszystkimi trzema rekordami, czasami trafia do spamu. Wynika to z braku historii, przez co odbiorcy zachowują ostrożność wobec domen zarejestrowanych niedawno. Należy zacząć od niewielkiej liczby wiadomości, których odbiorcy faktycznie oczekują. Reputacja budowana jest stopniowo i żadna konfiguracja nie zastąpi tego procesu.

FAQ

Dlaczego wychodzący port 25 jest zablokowany na moim VPS?

Prawie każdy dostawca domyślnie blokuje wychodzący port TCP 25, ponieważ przejęty serwer z otwartym tym portem może wysyłać spam bezpośrednio do serwerów pocztowych odbiorców. Pakiety są odrzucane, a nie odsyłane z informacją o odmowie, dlatego objawem jest zawieszenie połączenia i przekroczenie czasu oczekiwania, a nie komunikat o błędzie. Można to potwierdzić, uruchamiając nc -vz -w 5 gmail-smtp-in.l.google.com 25 obok nc -vz -w 5 smtp.relay.example 587: pierwsze polecenie zawiesi się, drugie odpowie natychmiast. Rozwiązaniem nie jest prośba o zdjęcie blokady. Należy korzystać z przekaźnika (relay) na porcie 587 lub 465, które pozostają otwarte i są przeznaczone dla uwierzytelnionych klientów.

Czy potrzebuję SPF, DKIM i DMARC tylko do wysyłania kilku powiadomień z aplikacji?

Tak, a wolumen wysyłki nie ma tu znaczenia. Odbiorcy stosują te same kontrole do pojedynczego resetu hasła, co do kampanii obejmującej pięćdziesiąt tysięcy wiadomości. Bez SPF i DKIM poczta jest nieuwierzytelniona, a obecne wytyczne Google dla nadawców wymagają przynajmniej jednego z tych mechanizmów od każdego nadawcy. Bez DMARC nie otrzymuje się raportów, więc pierwszym sygnałem problemu jest informacja od użytkownika, że link do resetowania hasła nie dotarł. Wszystkie trzy to rekordy DNS, ich wdrożenie nic nie kosztuje, a publikacja zajmuje około dziesięciu minut.

Czy powinienem użyć msmtp czy Postfix jako klienta przekaźnika?

Użyj msmtp, gdy jedna osoba administruje serwerem, a utrata wiadomości podczas awarii przekaźnika jest akceptowalna. Jest to pojedynczy plik konfiguracyjny bez demona, a ponieważ nie posiada kolejki, niedostępność przekaźnika oznacza utratę wiadomości. Użyj Postfix w trybie satelitarnym, gdy potrzebujesz kolejki, która ponawia próby przez wiele dni, lub gdy kilka aplikacji działa jako różni użytkownicy systemowi. Postfix przechowuje hasło do przekaźnika w pliku dostępnym tylko dla root, którego aplikacje nigdy nie odczytują, podczas gdy msmtp wymaga, aby konfiguracja była czytelna dla każdego użytkownika wysyłającego pocztę.

Dlaczego poczta z mojej aplikacji jest odrzucana, ponieważ pochodzi z root?

Zadania cron i wiele aplikacji tworzy adres nadawcy na podstawie lokalnego użytkownika i nazwy hosta, generując adres typu root@srv1.localdomain. Nie jest to adres zweryfikowany w przekaźniku, więc przekaźnik odrzuca wiadomość z odpowiedzią 553 lub 554, wskazującą na adres nadawcy. Należy to naprawić na poziomie hosta, a nie w każdej aplikacji z osobna: set_from_header on wraz z adresem from w /etc/msmtprc lub sender_canonical_maps z sender_canonical_classes = envelope_sender, header_sender w Postfix. Ustaw Reply-To wewnątrz każdej aplikacji, jeśli odpowiedzi mają docierać do konkretnej osoby.

Czy oddzielna subdomena dla poczty aplikacji faktycznie chroni moją główną domenę?

Częściowo, i nadal warto to robić. Odbiorcy śledzą reputację w podziale na domeny, więc skargi na notify.example.com w dużej mierze pozostają przypisane do notify.example.com, podczas gdy główna domena nadal dostarcza pocztę. Ograniczenie jest realne: niektórzy odbiorcy agregują sygnały z subdomen do domeny organizacyjnej, a polityka DMARC opublikowana na poziomie organizacyjnym ma zastosowanie do subdomen, chyba że ustawisz sp= osobno. Traktuj subdomenę jako ograniczenie szkód, a nie jako gwarancję.