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

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?

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.

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.

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 bill@microsoft.com. 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.