Czy przepisywanie SRS jest absolutnie konieczne dla serwera poczty z przekazywaniem?

14

Używam serwera pocztowego Postfix dla mojej domeny, powiedzmy mydomain.com. Działa głównie jako serwer poczty e-mail do przekazywania: użytkownicy otrzymują adres e-mail @ mojadomena.com, ale zwykle wybierają przekazywanie swojego adresu do zewnętrznej skrzynki odbiorczej (Gmail, Yahoo itp.). Przekazywanych jest kilka tysięcy adresów, więc serwer obsługuje dość znaczny ruch pocztowy.

W przeszłości serwer nie korzystał z przepisywania SRS. To oczywiście oznaczało, że przesyłana poczta nie przejdzie kontroli SPF, ponieważ mój adres IP nie jest technicznie upoważniony do wysyłania wiadomości e-mail w imieniu domeny pierwotnego nadawcy. Jednak z tego, co widzę, nie powoduje to żadnych znaczących problemów. Zasadniczo nie ma żadnych skarg od użytkowników, ponieważ Gmail, Yahoo itp. Wydają się być wystarczająco inteligentni, aby zignorować błędy SPF i mimo to dostarczyć wiadomości.

Mając to na uwadze, czy naprawdę konieczne jest włączenie przepisywania SRS? Zastanawiam się, czy to włączyć, ale moim głównym problemem jest to, że moja domena zostanie umieszczona na czarnej liście za wysyłanie spamu, gdy spam nieuchronnie zostanie przekierowany. Czy przepisywanie nie sprawiłoby, że wyglądałoby na to, że jestem pomysłodawcą spamu? (Przynajmniej tak rozumiem po przeczytaniu najlepszych praktyk Gmaila dotyczących przekazywania serwerów poczty ).

To prawda, że ​​już podejmuję niektóre zalecane środki ostrożności, takie jak używanie SpamAssassin, aby dodać „SPAM” do tematu o podejrzanym spamie przed przekazaniem dalej, nie przesyłanie spamu o wysokim poziomie ufności (ocena 15+) i używanie listy blokowania spamhaus, ale te środki nie są jest doskonały, a spam nadal może przechodzić przez nieoznaczony.

Czy włączenie przepisywania SRS jest tego warte, jeśli zwiększa ryzyko niewłaściwego oznaczenia jako spamera? A może bezpieczniej byłoby po prostu zostawić go takim, jakim jest i zignorować awarie SPF?

tlng05
źródło
Wiem z doświadczenia, że ​​niektórzy dostawcy usług internetowych w Wielkiej Brytanii odrzucą przychodzące wiadomości e-mail, które rzekomo pochodzą od ich własnych klientów, ale nie zostały wysłane z ich własnych listów. To samo może się stać również w przypadku Gmaila, Yahoo i AOL. Takie sytuacje można rozwiązać tylko poprzez przepisanie adresu nadawcy.
roaima

Odpowiedzi:

9

Wydaje mi się, że pytanie sprowadza się do tego: „ ile serwerów pocztowych sprawdza rekordy SPF na przychodzących wiadomościach e-mail? ”. Jeśli jest ich większość, SRS jest absolutnym wymogiem dla serwera przekazującego; jeśli to żaden z nich, nie potrzebujesz SRS.

Niestety nie mogę od razu położyć ręki na żadnej pracy naukowej w tej sprawie. Ponieważ jednak sprawdzam SPF na przychodzących wiadomościach e-mail, mogę z całą pewnością stwierdzić, że niektóre serwery pocztowe to sprawdzają. Każdy z Twoich klientów, którzy przekazują Twój serwer do kont na moim serwerze, straci wiadomości e-mail wysłane od nadawców, którzy reklamują SPF, który kończy się (tak jak wszyscy powinni) -all, chyba że używasz SRS. Mogę więc z całą pewnością stwierdzić, że bez SRS część e-maili Twoich klientów nie zostanie dostarczona .

Przepraszam Marca, że ​​nie umiem czytać po niemiecku, więc nie mogę powiedzieć, czy cytowany przez niego plik PDF wysuwa przekonujące argumenty, ale mogę powtórzyć, że bez SRS część wiadomości e-mail twoich klientów nie zostanie dostarczona. Nie mogę powiedzieć, co to za frakcja, ale nie jest zero - i biorąc pod uwagę, nie sądzę, że masz jakąś alternatywę do uruchomienia SRS.

Zgadzam się, że twój serwer nie pomoże sobie, przekazując SPAM, ale z mojego doświadczenia wynika, że ​​większość szkód związanych z reputacją jest wyrządzana jego adresowi IP, a nie domenie koperty Od; zostanie to zrobione niezależnie od użycia SRS.

Głębszą odpowiedzią na twoje pytanie jest to, że między SPF i jego (nieprzemyślane i łamanie Internetu) DMARC wydaje mi się, że usługi przesyłania poczty miały swój dzień. Wymagałem już, aby wszyscy oprócz jednego z moich użytkowników otrzymali ostateczną dostawę na mój serwer, a ten jeden użytkownik będzie musiał zmienić lub odejść w 2016 r. Obecnie wiele systemów poczty internetowej pozwoli na integrację z wieloma skrzynkami pocztowymi poprzez zbieranie poczty poza serwerem za pomocą IMAP lub POP, a wiele klientów poczty pozwala na prezentowanie wielu kont IMAP lub POP jako jednej zintegrowanej skrzynki INBOX, więc przekazywanie nie jest dobrodziejstwem dla scentralizowanego czytania, jakim było kiedyś.

Krótko mówiąc, powiedziałbym, że potrzebujesz SRS w perspektywie krótkoterminowej i nowego modelu biznesowego w perspektywie długoterminowej.

Szalony Kapelusznik
źródło
Chodzi o to, że SRS jest rozwiązaniem problemu z przesyłaniem SPF. SRS przepisuje np. Użytkownik @ A na A = użytkownik @ B, a wtedy zapisy SPF B są odpowiedzialne. Problem: B nadal może sfałszować adresy! Dlatego niektórzy dodają skróty kryptograficzne i znaczniki czasu do przepisanego adresu. Aby działało to na dużą skalę, wymaga globalnej adopcji, której nie ma. Działa również tylko wtedy, gdy coś jest przesyłane raz, ale nie więcej. Problem stanowią także odpowiedzi. Pamiętaj również, że SPF to technika chroniąca Twoją własną domenę nadużyć, nic więcej.
Marc Stürmer,
@ MarcStürmer „ SRS to rozwiązanie problemu z przekazywaniem SPF ”: tak, właśnie to jest. SPF jest znany z łamania uproszczonego przekazywania; jeśli nie uważasz, że SRS jest ceną, którą warto zapłacić, nie reklamuj rekordu SPF. „ Problem: B nadal może sfałszować adresy ”: nie do domeny A ani żadnej innej domeny chronionej porządnym rekordem SPF, w przeciwnym razie poczta zostanie odrzucona na podstawie SPF; ale poza tym tak, może i nie uważam tego za problem. „ SPF to technika chroniąca twoją domenę nadużyć, nic więcej ”: zgadzam się.
MadHatter
@ MarcStürmer: „Działa to również tylko wtedy, gdy coś jest przesyłane raz, ale nie więcej.” jest źle. SRS działa całkowicie dobrze na kilku serwerach przekierowujących. Cierpi tylko wtedy, gdy w linii znajduje się serwer bez tagowania. Jest to jednak ten sam problem, co w przypadku dowolnego serwera bez tagowania, niezależnie od tego, czy jest to pierwszy, czy później skok do przodu. W świecie SPF nie potrzebujesz SRS, musisz jedynie przejąć odpowiedzialność za przesyłaną pocztę i upewnić się, że możesz dostarczyć ewentualne odesłanie. SRS to tylko jedna technika, która to robi, Google np. Używa czegoś innego.
Adrian Zaugg,
Problem polega na tym, że użycie SRS przerywa sprawdzanie wyrównania DMARC (tj. Nadawca koperty! = From:-Header) i powoduje, że Gmail odrzuca wiadomości, jeśli domena w From:nagłówku ma p=rejectswoje zasady DMARC. Jeśli przepiszesz From:również, poczta zostanie sprawdzona zgodnie z regułami Twojej domeny. Ale sprawdzenie DKIM nie powiedzie się, a nadawca pokazany w kliencie pocztowym jest zniekształcony.
poród
@ poród afaik, masz rację. Ale osobiście uważam DMARC za całkowitą katastrofę, zwłaszcza, że ​​jednostronnie złamał listy mailingowe i (jako administrator dużej listy społeczności) po prostu odradzam ludziom korzystanie z usług jakiegokolwiek dostawcy usług internetowych, który publikuje p=rejectzasady. Jeśli SRS złamie DMARC, to jest po prostu trudne dla DMARC.
MadHatter
9

SRS wydaje się być dobrym pomysłem na papierze, ale nie działa zbyt dobrze w praktyce według ludzi z Heinlein Support (prowadzą oni średniej wielkości usługę pocztową z ponad 100 000 kont).

Szczegóły są w ich rozmowie, choć w języku niemieckim, dlaczego: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

Głównym powodem jest to, że SRS to mała łatka na poważne problemy z implementacją SPF w rzeczywistości, ponieważ SPF nie obejmuje bardzo często niektórych typowych przypadków użycia wiadomości e-mail. Aby SRS miał sens, należy go jednak wdrożyć na dużej bazie serwerów, co jest mało prawdopodobne. Więc dopóki nie zostanie wdrożony na tak dużej bazie serwerów, nie ma to żadnego sensu.

Problem z dużymi dostawcami poczty polega na tym, że obecnie mają oni naprawdę dużą bazę użytkowników i wdrażają coraz więcej technik (następca DMARC jest już w przygotowaniu), co sprawia, że ​​normalne staje się coraz trudniejsze konfiguracja serwera pocztowego do wysyłania do nich wiadomości e-mail w niezawodny sposób.

Jeśli chcesz, aby twoja poczta była lepiej dostarczana do dużych dostawców poczty, takich jak Gmail, Hotmail itp., Powinieneś wdrożyć przynajmniej DKIM i DMARC, ale także ustawić w najlepszym wypadku na miękką awarię i być może zaimplementować pewne mechanizmy ograniczające szybkość dostarczania poczty czyniłoby dla ciebie cuda.

Ten problem z dużymi dostawcami jest przyczyną, dla której istnieją obecnie takie usługi jak Mailchimp, Mandrill czy Returnpath. Dostawcy ci płacą pieniądze na rzecz Google & Co. dla lepszej jakości dostawy.

Marc Stürmer
źródło
1
Problemem jest tutaj SPF, a nie SRS. Tak długo, jak niektórzy usługodawcy internetowi używają SPF, musisz zaimplementować SRS (lub coś podobnego), aby przekazywanie działało z nimi wszystkimi. Problem z szarą listą jest inny, należy „rozpakować” adresy nadawców oznaczone tagami SRS do szarych list (podobnie jak wiadomości oznaczone tagami BATV).
Adrian Zaugg,
3

Zgadzam się z każdym słowem @MadHatter, ALE ważny fakt o Google!

Jeśli udostępniasz usługę przesyłania dalej do Gmaila, istnieje duża szansa, że ​​zapewnisz również dostęp SMTP, aby użytkownicy Gmaila mogli wysyłać wiadomości e-mail z Gmaila w imieniu podanego przez Ciebie adresu.

W takim przypadku - gmail wie, że jesteś spedytorem tego e-maila i nie oflaguje swoich wiadomości jako spam, nawet jeśli nie powiedzie się sprawdzanie SPF.

Możesz wysyłać klientom wiadomości e-mail z adresu [email protected]. Wiadomość trafi do skrzynki odbiorczej bez ostrzeżenia! (Microsoft ma -all w rekordzie SPF)

Sprawdzone i zweryfikowane. Przykład w załączeniu.

ta wiadomość trafiła do skrzynki odbiorczej.Gmail Pokaż oryginał

Yeya
źródło