Wzmocnienie bezpieczeństwa poczty elektronicznej: Stop Sender Fraud with SPF, DKIM, and DMARC

Nie da się odfiltrować prawdy: Musisz chronić firmową pocztę elektroniczną.

W 2013 roku każdego dnia wysyłano i odbierano ponad 100 miliardów biznesowych wiadomości e-mail. Zaledwie jedna na pięć wszystkich wiadomości e-mail wysłanych w 2013 r. była zgodna z prawem, a 92% wszystkich nielegalnych wiadomości e-mail zawierało łącza do potencjalnie złośliwych treści.

Są jednak oznaki poprawy; ten miesiąc jest pierwszym w ciągu ostatnich 12 lat, w którym mniej niż połowa wiadomości e-mail klientów firmy Symantec była spamem.

Za zmniejszenie ilości spamu można podziękować trzem standardom bezpieczeństwa poczty elektronicznej (i innym inicjatywom): SPF, DKIM i DMARC. Mimo to, zagrożenia bezpieczeństwa są powszechne. Ostatnio usłyszałem historię o dyrektorze finansowym, który był obiektem próby phishingu. Próba nie powiodła się, ale gdyby się powiodła, kosztowałaby organizację 50 000 dolarów.

Jeśli chodzi o te standardy poczty elektronicznej, nadal jest wiele zamieszania wokół nich. Mam nadzieję, że mogę zapewnić trochę jasności w tym poście, jak również przeprowadzić Cię przez to, jak wdrożyć SPF, DKIM i DMARC.

Sender Policy Framework (RFC 4408)

Sender Policy Framework, lub SPF, jest starym człowiekiem na imprezie uwierzytelniania emaili. SPF jest otwartym standardem, który określa metodę zapobiegania fałszowaniu adresów nadawcy, zgodnie z openspf.org. Nie chodzi o powstrzymanie spamu; chodzi o kontrolowanie i powstrzymanie prób fałszowania nadawcy.

SPF umożliwia identyfikację legalnych źródeł poczty w Twojej domenie i zapobiega nieautoryzowanym źródłom wysyłania tysięcy, a nawet milionów nielegalnych e-maili z Twojej domeny.

Istnieją cztery typy nadużyć poczty elektronicznej powszechnie związane z fałszowaniem nadawcy poczty elektronicznej:

• Spam (niechciana masowa &niechciana komercyjna poczta elektroniczna)
• Oszuści (oszustwa 419)
• Malware (adware, zero-day, wirusy, trojany itp.)
• Phishers (spear-phishing)

Nie chcesz, aby domena Twojej organizacji była powiązana z którymkolwiek z nich z oczywistych powodów. SPF pomoże upewnić się, że emaile Twojej organizacji rzeczywiście pochodzą od Ciebie.

DomainKeys Identified Mail (RFC 6376, zastępuje RFC 4871 i RFC 5672, które są obecnie przestarzałe)

DKIM, lub DomainKeys Identified Mail, jest rekordem TXT publikowanym w systemie nazw domen (DNS). Obejmuje on coś, co wszyscy administratorzy IT powinni nauczyć się kochać: klucze – konkretnie klucze publiczne.

Zanim zagłębimy się w DKIM, ważne jest, abyśmy zrozumieli, czym są klucze i jak działają. Klucze, w tym przypadku, kryptografia klucza publicznego, składa się z klucza publicznego (znanego wszystkim) i prywatnego (często nazywanego tajnym). Klucze publiczne i prywatne są matematycznie powiązane ze sobą, dzięki czemu możliwa jest bezpieczna komunikacja przez kanały publiczne.

Klucze te są jak plomba zabezpieczająca na przezroczystej kopercie. Niekoniecznie ukrywasz wiadomość; jedynie uwierzytelniasz ze 100% pewnością zarówno nadawcę, jak i wiadomość.

Teraz, wracając do DKIM.

„Technicznie DKIM zapewnia metodę walidacji tożsamości nazwy domeny, która jest związana z wiadomością poprzez uwierzytelnianie kryptograficzne”, zgodnie z dkim.org. Innymi słowy, DKIM używa kluczy, aby upewnić się, że nadawca wiadomości e-mail jest tym, za kogo się podaje.

Z DKIM, pary kluczy publicznych i prywatnych są generowane, aby utrzymać serwery pocztowe i komunikację uwierzytelnioną. Każdy wychodzący serwer SMTP (Simple Mail Transfer Protocol) potrzebuje odpowiedniego klucza prywatnego i prefiksu, aby dopasować się do publicznego rekordu DNS, który następnie weryfikuje otrzymujący serwer pocztowy.

Czy zastanawiałeś się, dlaczego ikona kłódki pojawia się w Gmailu, gdy dostajesz wiadomości z eBaya, Paypala lub swojego banku? To jest DKIM i trochę DMARC (o którym za chwilę). Poniżej, mailed-by pokazuje dopasowanie SPF, a signed-by pokazuje dopasowanie DKIM. DKIM i DMARC nie są jeszcze niezbędne, ale podobnie jak IPv6, szybko przechodzą z laboratorium testowego do lepszego stanu posiadania.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

DMARC, lub Domain-based Message Authentication, Reporting, and Conformance, pomaga nadawcom i odbiorcom współpracować w celu stworzenia bezpieczniejszej komunikacji e-mailowej. DMARC został stworzony przez grupę organizacji w celu ograniczenia nadużyć opartych na poczcie elektronicznej „poprzez rozwiązanie kilku długotrwałych problemów operacyjnych, wdrożeniowych i sprawozdawczych związanych z protokołami uwierzytelniania poczty elektronicznej”, zgodnie z dmarc.org.

DMARC umożliwia nadawcy wiadomości wskazanie, że jego wiadomości są chronione za pomocą SPF i/lub DKIM. Polityka DMARC stosuje jasne instrukcje dla odbiorcy wiadomości, aby postępował zgodnie z nimi, jeśli wiadomość e-mail nie przejdzie uwierzytelnienia SPF lub DKIM – na przykład, odrzuć lub wyrzuć ją.

Również, DMARC wysyła raport z powrotem do nadawcy o wiadomościach, które PASUJĄ i/lub FAIL oceny DMARC.

Jak wdrożyć SPF, DKIM, i DMARC

Teraz, gdy mamy lepsze zrozumienie każdego z tych trzech standardów (i dlaczego są ważne), spójrzmy jak można poprawić bezpieczeństwo poczty elektronicznej poprzez ich wdrożenie.

Uwaga: Dla celów tego przewodnika krok po kroku, udawajmy, że jesteś szefem IT w 301 Moved, małej firmie projektującej strony internetowe, która używa Google Apps.

Ostatnio miałeś pewne problemy z rosyjskimi botami spamowymi. Twoi użytkownicy końcowi skarżyli się na otrzymywanie powiadomień o odrzuceniu wiadomości e-mail z adresów, których nigdy nie widzieli ani do których nie wysyłali wiadomości. Zdajesz sobie sprawę, że ktoś wyraźnie wysyła oszukańcze e-maile z twojej domeny.

Jak więc ich powstrzymać?

Uwaga: Załączam standardowy format BIND w zwykłym tekście i zrzut ekranu, jak rekord wygląda w GoDaddy DNS. W GoDaddy, wszystkie rekordy dla domeny najwyższego poziomu 301Moved.com używają hosta „@”, Twój host będzie prawdopodobnie inny. Dla celów tego ćwiczenia, będę omawiał tylko pocztę wychodzącą, a nie to jak traktujemy te standardy w odniesieniu do poczty przychodzącej od zewnętrznych nadawców.

Wdrażanie SPF

Krok pierwszy: Przewodnik Google dotyczący konfiguracji rekordów SPF do pracy z Google Apps jest dobrym miejscem aby zacząć. Postępując zgodnie z tymi instrukcjami, dodajemy nowy rekord TXT do naszego publicznego DNS.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 Moved używa również Zendesk, systemu biletowego, który wysyła wiadomości e-mail bezpośrednio z Twojej domeny. Musisz upewnić się, że spam nie jest wysyłany również stamtąd.

Krok drugi: Znajdź i dodaj rekord SPF Zendesk.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

Ważne jest, aby zauważyć, że nie dodajemy drugiego rekordu SPF, który zepsułby wszystko; zamiast tego łączymy je w jeden rekord, wydłużając go w miarę dodawania kolejnych nadawców.

Uwaga: Możesz dodać tylko jeden rekord SPF na domenę lub subdomenę.

Wiesz również, że 301 Moved ma starą bramę email na terenie firmy, która obsługuje niektóre starsze rzeczy, więc dodajmy ich blok IP również. 301 Moved używa mechanizmu „IP4” aby zdefiniować blok IP, który posiada-198.51.100.0/24 (192.51.100.0-254).

Użyj SPF Surveyor firmy Dmarcian aby zobaczyć swoje rekordy SPF.

Krok trzeci: Dodaj pojedyncze adresy IPv4 oraz bloki sieci w notacji Classless Inter-Domain Routing (CIDR). 198.51.100.0 dla pojedynczego adresu IP (nie potrzebujemy /32) i 198.51.100.0/24 dla podsieci.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

Dodanie starej bramy e-mail zapewni, że wychodzące z niej wiadomości e-mail będą autoryzowane SPF.

Powyższe mechanizmy są najczęściej używane, ale jest ich w sumie osiem – w tym dziwne i zdeprecjonowane. Mechanizmy te definiują jedynie zakres dopasowania, a nie same akcje.

Kwalifikatory w następnej sekcji to miejsca, w których można zdefiniować PASS, SOFTFAIL i FAIL – dopasowanie spowoduje uruchomienie jednej z trzech akcji (PASS, SOFTFAIL i FAIL).

• ALL: Dopasowuje wszystko, co nie zostało już zdefiniowane przez inny mechanizm, będzie dopasowane do mechanizmu all
• A: Jeśli nazwa domeny ma rekord adresu (A lub AAAA), który można rozwiązać do adresu nadawcy, zostanie dopasowana.
• IP4: Jeśli nadawca znajduje się w danym zakresie adresów IPv4, zostanie dopasowana.
• IP6: Jeśli nadawca znajduje się w danym zakresie adresów IPv6, zostanie dopasowana.
• MX: Jeśli nazwa domeny ma rekord MX rozwiązujący do adresu nadawcy, to będzie pasować (tzn. poczta pochodzi z jednego z serwerów poczty przychodzącej domeny).
• PTR: Jeśli nazwa domeny (rekord PTR) dla adresu klienta jest w danej domenie i ta nazwa domeny rozwiązuje do adresu klienta (forward-confirmed reverse DNS), to dopasuj. Ten mechanizm jest przestarzały i nie powinien być już używany.
• EXISTS: Jeśli podana nazwa domeny rozwiązuje się do dowolnego adresu, będzie pasować (bez względu na adres, do którego się rozwiązuje). Jest to rzadko używane. Wraz z językiem makr SPF oferuje bardziej złożone dopasowania, takie jak DNSBL-queries.
• INCLUDE: Jeśli dołączona (błędne określenie) polityka przejdzie test ten mechanizm dopasowuje się. Jest to zazwyczaj używane do włączania polityk więcej niż jednego ISP.

Następnie są kwalifikatory. Istnieje milion sposobów, aby połączyć je z modelem czarnej listy i/lub białej listy, ale dla naszych celów tutaj, będziemy zawierać tylko trzy mechanizmy wyszukiwania, które wymieniliśmy powyżej z pojedynczym kwalifikatorem na końcu, aby stworzyć białą listę. Nasze cztery kwalifikatory to:

• + dla wyniku PASS. Można to pominąć; np., +mx jest tym samym co mx.
• ? dla wyniku NEUTRAL, interpretowanego jako NONE (brak polityki).
• ~ (tylda) dla SOFTFAIL, pomoc w debugowaniu pomiędzy NEUTRAL a FAIL. Zazwyczaj wiadomości, które zwracają SOFTFAIL są akceptowane, ale oznaczone.
• – (minus) dla FAIL, poczta powinna być odrzucona (zobacz poniżej).

Krok czwarty: Zastosuj politykę SOFTFAIL.

Na razie, 301 Moved używa tyldy dla SOFTFAIL. Przez użycie tyldy, cała poczta nie pasująca do Google, Zendesk lub wspomnianego bloku IP będzie SOFTFAIL. Poczta nadal będzie dostarczona, ale prawdopodobnie zostanie wysłana do folderu Spam lub Junk. Jest to jednak całkowicie zależne od serwera pocztowego odbiorcy. Nie jest to zdefiniowane przez żadne standardy.

A „-” (minus) w tej sytuacji będzie FAIL (i prawdopodobnie odrzuci) niepasującą pocztę całkowicie. Możesz to włączyć gdy zaczniesz mieć większą widoczność na pocztę wychodzącą (czekaj na DMARC), i gdy będziesz się czuł bardziej komfortowo ze swoją infrastrukturą pocztową.

SPF jest świetny ponieważ nie ma żadnych modyfikacji samych serwerów pocztowych. Nagłówki pozostają takie same. Wystarczy prosty rekord TXT (rzeczywisty, dedykowany rekord SPF nigdy nie był tak popularny i obecnie jest już przestarzały) i możesz poinstruować większość serwerów pocztowych na świecie, kto powinien migać twoim nazwiskiem.

Na koniec dnia, odbierający serwer SMTP sprawdza IP nadawcy w stosunku do twojego rekordu SPF, o który zapytał, a następnie stosuje politykę opartą na twoich instrukcjach. Innymi słowy, upoważniasz siebie i swoich dostawców do wysyłania (głównie) zaufanej poczty, ponieważ publikujesz listę kontroli dostępu (ACL) do wiadomości publicznej.

Jednakże, wiadomości mogą być nadal modyfikowane w tranzycie, a przebiegli fałszerze i phisherzy mogą obejść SPF na kilka ciekawych sposobów (może to temat na inny dzień). To jest SMTP: End-to-end TLS nie jest gwarantowany, więc musimy zawsze zakładać cleartext. Wiadomości mogą być manipulowane lub sfałszowane.

Ale wejdź na scenę po prawej stronie…

Implementing DomainKeys Identified Mail

Gdy poczta jest wysyłana, 301Moved.com podpisuje (bez szyfrowania) pocztę kluczem prywatnym. Od tej pory, jakakolwiek modyfikacja wiadomości, włączając w to treść, nagłówki lub załączniki, złamie podpis i sprawi, że wiadomość będzie nieważna. Ponownie zaglądamy do Google, korzystając z ich artykułu Authenticate email with DKIM

Krok piąty: Dodaj klucz publiczny do swojego rekordu DNS.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Każdy rekord DKIM ma unikalny prefiks selektora, co oznacza, że możemy opublikować więcej niż jeden. Zamiast łączyć je w jeden rekord, tak jak to robiliśmy z SPF, możesz użyć unikalnych selektorów i opublikować tyle kluczy publicznych, ile potrzebujesz. To pozwala nam dodać dużą liczbę autoryzowanych serwerów DKIM bez żadnych górnych limitów.

Zauważysz, że prefiks powyżej to „google”, domyślny, którego Google Apps używa podczas generowania rekordu DKIM do publikacji. Możesz to zmienić w Google i większości innych konfiguracji, więc jeśli chciałbyś prefiks „dkimawesome”, nic cię nie powstrzyma.

Niektórzy dostawcy usług w chmurze robią to inaczej. Zamiast generować unikalne pary kluczy dla każdego dzierżawcy chmury, podpisują całą pocztę wychodzącą dla wszystkich domen tym samym kluczem – jednocześnie każąc Ci opublikować nazwę kanoniczną (CNAME) zamiast tego dla ich klucza.

Zendesk robi to, CNAME dwóch różnych kluczy na naszym DNS do ich DNS. Zendesk ma świetny artykuł pomocy – Cyfrowe podpisywanie wiadomości e-mail za pomocą DKIM lub DMARC (Plus i Enterprise)

Krok szósty (jeśli dotyczy): CNAME klucze na swoim DNS do ich DNS. Każde zapytanie DNS szukające zendesk1._domainkey.301Moved.com zostanie przekierowane przez Twój DNS do zendesk1._domainkey.zendesk.com. Zendesk wtedy serwuje klucze DKIM bezpośrednio.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

Możemy zobaczyć jak to wygląda na innych serwerach używając lokalnie narzędzia nslookup (dla Unix lub Windows).

Nie wszyscy wychodzący nadawcy obsługują DKIM. Google Apps oczywiście obsługuje, ale starsze serwery pocztowe mogą nie.

Implementing Domain-based Message Authentication, Reporting, and Conformance

DMARC, lub Domain-based Message Authentication, Reporting, and Conformance, jest ostatnim narzędziem, jakie mamy do walki ze złośliwą pocztą. Dla serwerów pocztowych, które nasłuchują, DMARC, przekazuje jak traktować SPF i DKIM, a także jak raportować do Ciebie, dając Ci bardzo potrzebny wgląd w Twoje wskaźniki dostarczania i zgodność z rekordami.

I tak, DMARC to kolejny rekord TXT.

Krok siódmy: Skonfiguruj politykę DMARC, zidentyfikuj adres mailto, ustaw tryb wyrównania i określ procent wiadomości, do których polityka powinna być stosowana (nie martw się, jest to prostsze niż się wydaje).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

Powyższa polityka jest oznaczona jako p=none. Nie modyfikujemy jeszcze w ogóle przepływu poczty – po prostu ustawiamy politykę i jej odpowiednie raportowanie. Adres, na który będą wysyłane raporty XML o statusie DMARC jest oznaczony rua=.

Odbierające serwery pocztowe będą wysyłać załączniki XML pokazujące jak wiadomości z – i te podające się za pochodzące z – twojej domeny wypadły w konfrontacji z SPF, DKIM i DMARC, które większość nowoczesnych serwerów pocztowych narzuca.

Raporty te pokazują, na podstawie każdej koperty, czy SPF przeszedł, nie przeszedł czy softfailed. Pokazują one, czy DKIM nie przeszedł, nie przeszedł wyrównania lub przeszedł pomyślnie – i jak powyższe polityki zostały zastosowane.

Na koniec, te raporty pokazują ostateczną dyspozycję dostarczenia wiadomości. Istnieją świetne narzędzia, które pomagają w ich analizowaniu. Nawet jeśli nie stosujesz zasad do wiadomości, to tak jak w przypadku zapory sieciowej, DNS i logów IDS/IPS – zawsze dobrze jest mieć coś, do czego można wrócić i spojrzeć na nie.

Adkim=r określa zrelaksowany tryb wyrównania DKIM, „r” oznacza zrelaksowany, a „s” oznacza ścisły. Tryb zrelaksowany pozwala uwierzytelnionym domenom DKIM d= w obrębie wspólnej Domeny Organizacyjnej w nagłówku pocztowym-From: na PRZEPROWADZENIE kontroli DMARC. Tryb ścisły wymaga idealnego dopasowania pomiędzy domeną DKIM d= a adresem nagłówka-From wiadomości e-mail. Pomyśl o subdomenach, jeśli ich używasz.

aspf=r robi dokładnie to samo, z wyjątkiem sprawdzania SPF.

Pct=100 jest procentem wiadomości, które są rzeczywiście traktowane zgodnie z polityką DKIM. Wybierany losowo, odbierający serwer pocztowy będzie egzekwował politykę DKIM na tym procencie wiadomości z Twojej domeny. Używamy 100 na razie, ponieważ nie stosujemy polityki, jeszcze.

Zanim zastosujemy politykę, zdławimy to do pięciu tak, że tylko jedna na 20 wiadomości będzie miała zastosowaną politykę, gdy zmienimy flagę p= policy na kwarantannę lub odrzucenie. W ten sposób, jeśli całkowicie to spieprzymy, 95% naszych emaili nadal zostanie dostarczonych, zamiast 0%, gdybyśmy zaczęli od pct=100.

Wiadomości, które nie przejdą kontroli DMARC, lub tryby wyrównania adkim= i aspf=, które ustawiliśmy powyżej są miękko odbijane, jak powyżej, dla polityki kwarantanny, lub całkowicie odbijane, gdy ustawione na odrzucenie.

Jest bardzo ważne aby zauważyć, że DMARC będzie PASS wiadomość jeśli albo SPF lub DKIM przechodzi, i tylko FAIL wiadomość jeśli zarówno SPF i DKIM FAIL. W ten sposób wiadomości SPF-only i DKIM-only mogą PASS DMARC, ale wiadomości bez SPF/DKIM zawsze będą FAIL. To jest świetna wiadomość jeśli masz systemy pocztowe, które obsługują tylko SPF, lub tylko DKIM.

Użyj Dmarcian’s DMARC Inspector aby sprawdzić swoje rekordy DMARC.

Dmarcian jest płatnym narzędziem, które pozwala na łatwe zarządzanie raportami DMARC, jest wiele innych, ale Dmarcian jest moim ulubionym.

Uaktualnienie: Otrzymaliśmy kilka (zgodnych z DMARC!) emaili z pytaniem o politykę subdomen sp=none. Z polityką, która zawiera sp=none nie określasz polityki DMARC dla żadnej subdomeny. Można to zrobić ręcznie poprzez ustawienie odpowiedniego rekordu DMARC dla każdej konkretnej subdomeny lub zawrzeć w głównym rekordzie DMARC z sp=quarantine lub sp=reject.

Minimum Config

Jeśli chcesz to wypróbować, polecam zacząć bardzo otwarcie i pozostać prostym, aż będziesz miał wystarczająco dużo raportów DMARC, aby zacząć cokolwiek egzekwować.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

Zdefiniuj dużych dostawców z „include:” i wszelkie bloki IP, z których możesz wysyłać pocztę z „IP4 „lub „IP6”. Użyj „MX” aby autoryzować swoje serwery poczty przychodzącej. I o ile nie wysyłasz poczty bezpośrednio z tej samej skrzynki/serwera, który hostuje twoją stronę (zła, zła praktyka przy okazji), możesz pominąć mechanizm „A”, który został wspomniany powyżej. The „?” nie stosuje żadnej polityki do twoich wiadomości, ale dostaje twój rekord SPF tam, więc DMARC może go rozpoznać.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Znajdź właściwy selektor, „google” w tym przypadku, i właściwy klucz. Pamiętaj, że możesz opublikować więcej niż jeden.

Uwaga: Proszę nie publikuj tego rzeczywistego klucza albo będę w stanie podpisać Twoją pocztę DKIM.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

Dla DMARC, nie mamy zastosowanej żadnej polityki, jesteśmy w trybie zrelaksowanym, ale prosimy o wysłanie raportów XML do skrzynki pocztowej, do której mamy dostęp. Stąd DMARC daje nam dość szybką (nie w czasie rzeczywistym) informację zwrotną o tym, jak możemy zaostrzyć różne polityki we wszystkich trzech rekordach.

Ale zaraz, co z TLS?

Transport Layer Security, lub TLS, nie jest częścią standardu DMARC, i nie jest rekordem DNS.

Zamiast tego, TLS jest po prostu rozwiniętym Secure Socket Layer (SSL), którego serwery pocztowe mogą używać do przesyłania wiadomości do siebie nawzajem przez publiczne połączenia. Jest to SMTP zawinięte w TLS, tak jak można robić wiele innych rzeczy wewnątrz/ponad TLS-SNMP nad TLS i FTP nad TLS będące powszechnymi przykładami. TLS szyfruje wiadomości tylko w tranzycie, nie w spoczynku.

Jeśli wyślemy wiadomość podpisaną DKIM przez TLS, jest ona podpisana przez cały czas jej istnienia, ale tylko zaszyfrowana, gdy przeskakuje z Google Apps do Cisco Ironport, lub gdziekolwiek, gdzie poczta jest przesyłana. TLS z pewnością nie chroni wiadomości w spoczynku, chociaż jest również używany do sesji HTTPS:// do webmaila, gdy czytasz tę samą wiadomość, ale znowu, to jest w tranzycie.

TLS jest czymś, czego powinieneś używać wszędzie, gdzie to możliwe, ale również być gotowym do mówienia cleartext do innych publicznych systemów pocztowych. Nawet w 2015 roku niektóre serwery pocztowe nie obsługują STARTTLS (określenie serwerów na rozpoczęcie handshake’u TLS).

Możesz wymusić użycie TLS z niektórymi domenami zewnętrznymi w Google Apps za pomocą prostej zmiany konfiguracji. Jest to dobra rzecz do włączenia dla stowarzyszonych firm zewnętrznych, partnerów i innych organizacji, ale wymuszaj TLS tylko wtedy, gdy jesteś pewien, że jest niezawodny i obsługiwany przez wszystkie serwery pocztowe w tej konkretnej domenie.

Ważność bezpieczeństwa poczty elektronicznej i unikanie oszustw nadawcy

Czy jesteś doświadczonym administratorem IT, czy dopiero zaczynasz, te trzy standardy mają takie samo znaczenie. Co prawda, to co każdy z nich robi i jak ze sobą współpracują może być nieco zagmatwane, ale wdrożenie ich jest stosunkowo proste, a korzyści są warte Twojego czasu.