Bardzo często mamy do czynienia z potrzebą wysyłania mailingu z naszej aplikacji. Zwykłe potwierdzenie maila, czy też obsługa powiadomień, wymaga posłania przez automat wiadomości na skrzynkę odbiorcy. Często nasze maile zostają oznaczone jako spam. Zabezpieczenia przed podszywaniem się pod odbiorcę to broń obusieczna i warto się z nimi zaznajomić, by wszystko działało jak potrzeba. Większość instytucji państwowych ma problemy ze skonfigurowaniem swojej domeny, więc newsy w tym stylu, nie są niczym niezwykłym 😉
Podstawowa sprawa, jak sprawdzać co powoduje, że dany mail trafił do spamu? W większości skrzynek mailowych, istnieje opcja „pokaż oryginał”. Widać wtedy oryginalny mail, ze wszystkimi nagłówkami. Nas interesują między innymi:
Authentication-Results: Received-SPF: DKIM-Signature: X-Spam-Score:
Drugi sposób, to weryfikacja przez serwisy internetowe, na przykład DKIMValidator.com. Wysyła się wiadomość na wygenerowany adres, a potem serwis sprawdza, co jest nie tak.
SPF – Sender Policy Framework
Najprostsze i najczęściej stosowane zabezpieczenie przeciwko podszywaniu się pod skrzynkę mailową. Polega na sprawdzaniu, które adresy/domeny mogą wysyłać maile spod konkretnej domeny. Aktywacja zabezpieczenia to wpisanie odpowiedniego rekordu TXT w domenie. Jest on często automatycznie generowany przy konfiguracji strefy DNS, więc jeśli jest błędny, powoduje odrzucanie maili (Received-SPF: fail).
Pełna składnia wygląda tak, ale zazwyczaj stosuje się coś takiego
v=spf1 a mx -all
Taka składnia informuje, że wszystko, na co nakierowują rekordy A i MX jest dozwolone, a pozostałe mają być odrzucane. Innej konfiguracji wymagają przypadki, gdy pozostawiamy mailing w innej domenie niż ta, na której stoi serwer, który te maile wysyła. Tutaj jest wiele opcji, począwszy od „include”, powodującej przeszukanie rekordu SPF w innej domenie.
Większość serwerów mailowych na świecie obsługuje SPF, więc to jest ten standard, który stosuje się zawsze.
DKIM – DomainKeys Identified Mail
Poziom wyżej od SPF, wymagający czegoś więcej niż tylko rekordu w domenie. Wprowadza podpis cyfrowy dla maila wraz z nagłówkiem. Po stronie domeny wymaga klucza TXT o zawartości
v=DKIM1; k=rsa; h=sha256; p=klucz_publiczny;
Klucz publiczny i prywatny możemy wygenerować przy pomocy openssl.
openssl genrsa -out private.key.pem openssl rsa -inform PEM -in private.key.pem -pubout
Klucz publiczny musimy zapisać w DNS w formie zakodowanej w Base64.
Wychodzące maile musimy podpisywać zgodnie z DKIM. Podpis wygląda np. tak
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1435065553; s=domena.com; d=domena.com; i=@domena.com; h=From:To:Message-ID:Subject:MIME-Version:Content-Type:Date; l=2017; bh=bqDxw/sdX8jexNVJMXv/7hc+yW9SK7FobXRzFdCV44o=; b=k/wm4G5VKSyxtIZs8ho4+3pqmD5iL09Mu/OwjxNgJe0zSQTn7Tby6xblxTQ2zd0S 6His99oU1Fm6lKkiHw1WmFjsF6NKT8tlJelN47t87vCLLxt2+0itsbI79B8445m8oKO +0XIqOdy6ihg+DmAB0ad7QLssRnCr9h/HknjHQFM=
Oczywiście implementacji algorytmu podpisywania DKIM jest cała masa i warto ich użyć. Ja sam nieco odświeżyłem starą implementację z agitos.de dla standardu JavaMail. Całość znajduje się w repozytorium. Użycie ogranicza się do stworzenia proxy dla wysyłania maili, by szły przez maszynkę do podpisywania, zanim trafią do wysyłki. Zawarłem przykładową implementację dla Spring Framework.
DMARC
Ostatni z rozpowszechnionych rozszerzeń DNS dla mailingu. Decyduje o tym, co dzieje się z mailami, które nie przechodzą walidacji DKIM/SPF. Możemy tutaj zadecydować o tym, czy maile trafiają do spamu, czy też mają być automatycznie odrzucane. Można także generować raport na ten temat na jakąś skrzynkę mailową.
v=DMARC1; p=reject; rua=mailto:postmaster@domena.com
W tym przypadku maile zostaną odrzucone, a dzienny raport trafi na postmaster@domena.com. Jest to najmniej rozpowszechniony standard, więc polskie darmowe skrzynki, na znanych portalach, zapewne go oleją. Ważniejsi gracze na rynku, np. Google i Yahoo wspierają ten standard.
SpamAssassin
Ostatnią rzeczą jaką warto zrobić z przykładowym mailingiem, to przepuścić go przez zestaw filtrów SpamAssassin, który jest opensource’owym standardem filtrowania maili. Pomoże to osiągnąć lepszy wynik, który zmniejszy ryzyko odrzucania maili. Zestaw domyślnych testów, który musi przejść każdy mail jest dość długi, ale warto poprawić te rzeczy, które powodują zawyżanie naszego wyniku. Przykładowo, zawyżenie wyniku, w mailu typu „multipart”, powoduje rozbieżność treści w części „text/plain” i „text/html”. W antycznych czasach nie wszystkie klienty pocztowe interpretowały html, więc tekst w obu wypadkach powinien być zgodny.
Sporo filtrów sprawdza, czy wasz mailing jest zgodny ze standardami, niekoniecznie aktualnymi. W celu osiągnięcia „najlepszego wyniku”, należy spełniać je wszystkie.