
W tej serii widzieliśmy, że dołączenie podpisu S/MIME jest stosunkowo proste. Wysyłanie zaszyfrowanej poczty S/MIME jest bardziej skomplikowane, ponieważ musisz uzyskać klucze publiczne odbiorców. To jedna rzecz, gdy korzystasz z klienta pocztowego dla ludzi, takiego jak Thunderbird – ale jak to może działać w przypadku generowanych przez aplikację strumieni e-mailowych?
W części 1, przeprowadziliśmy szybki przegląd S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 przeprowadziła nas przez prostą narzędziową linię poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wstrzyknąć bezpieczne strumienie poczty do platform lokalnych, takich jak Port25 PowerMTA i Momentum.
W tej serii widzieliśmy, że dołączenie podpisu S/MIME jest stosunkowo proste. Wysyłanie zaszyfrowanej poczty S/MIME jest bardziej skomplikowane, ponieważ trzeba uzyskać klucze publiczne odbiorców. To inna sprawa, gdy używasz klienta poczty dla ludzi, takiego jak Thunderbird – ale jak to działa w przypadku strumieni e-mail generowanych przez aplikacje? E-maile generowane przez aplikacje, jak te używane przez platformy randkowe, wymagają starannej strategii do maksymalizacji zaangażowania. Zobacz, jak aplikacje randkowe tworzą przyciągające uwagę uruchamiające doświadczenia e-mail.
Ale poczekaj – jest jeszcze inny sposób na dostanie się do Mordor, aby uzyskać te klucze. Twoja usługa może zaprosić Twoich klientów (oczywiście przez e-mail) do przesłania Ci podpisanej wiadomości na znany adres obsługi klienta. Używając magicznych mocy webhooków SparkPost Inbound Relay, wyciągniemy i przechowamy ten klucz publiczny do Twojego użytku.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, przekazuję twojej usłudze mój osobisty podpis e-mailowy poprzez e-mail, aby w przyszłości wiadomości e-mail mogły być wysyłane do mnie w formie zaszyfrowanej S/MIME.
Na tej podstawie wywiedziemy bardziej szczegółowe wymagania:
Potrzebujemy niezawodnej, zawsze włączonej usługi przyjmowania e-maili, aby odbierać te podpisane wiadomości.
Nie powinny istnieć specjalne wymagania dotyczące formatu poczty, poza tym, że powinien on zawierać podpis S/MIME.
Ponieważ każdy może spróbować wysłać wiadomość do tej usługi, powinna ona być zaprojektowana defensywnie, na przykład aby odrzucać „podrobione” wiadomości od złych aktorów. Będzie potrzeba kilku warstw weryfikacji.
Jeśli wszystko się zgadza, usługa zapisze certyfikat w pliku, używając dobrze znanego formatu tekstowego Privacy-Enhanced Mail (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhook z maszyny do maszyny mogą być trudne do zauważenia tylko z odpowiedzi na to, co dzieje się wewnątrz. Usługa powinna zapewniać obszerne, czytelne dla człowieka logi aplikacji na poziomie aplikacji, w szczególności powinno być prowadzone logowanie weryfikacji i parsowanie certyfikatów.
Dodajemy przypadki testowe dla wewnętrznych części aplikacji, używając fajnego frameworka Pytest, a następnie automatycznie uruchamiamy te testy przy zameldowaniu używając integracji Travis CI z GitHub.
OK – zaczynamy!
1. Przegląd rozwiązania
Oto jak będzie wyglądało ogólne rozwiązanie.

2. Instalacja, konfiguracja i uruchamianie aplikacji webowej
3. SparkPost inbound relay webhooks konfiguracja
Po pierwsze, wybieramy domenę do użycia jako nasz adres wiadomości przychodzącej – tutaj będzie to inbound.thetucks.com. Skonfiguruj swoją domenę zgodnie z tym przewodnikiem. Oto kroki, które użyłem szczegółowo:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego konkretnego konta dostawcy usług internetowych. Po zakończeniu możesz sprawdzić je za pomocą dig – oto polecenie dla mojej domeny.
Powinieneś zobaczyć:
3.2 Utwórz domenę przychodzącą
Użyj SparkPost Postman API collection, wybierając domeny przychodzące / Create .. call. Treść żądania POST zawiera Twoją domenę, na przykład:

3.3 Utwórz Relay Webhook
Utwórz webhook przekaźnika przychodzącego, używając odpowiedniego wywołania Postman. Treść wiadomości w moim przypadku zawiera:
Jak wspomniano wcześniej, polecam ustawienie auth_token na własną tajną wartość, jak ustawiono w pliku webapp.ini na Twoim hoście.
Twój „target” musi pasować do adresu hosta i portu TCP, gdzie będziesz prowadzić aplikację internetową.
Twój „domain” musi pasować do rekordów MX skonfigurowanych w kroku 1.

To wszystko! Instalacja jest zakończona. Teraz powinieneś być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetworzone i pojawią się na Twoim hoście aplikacji internetowej – w tym przypadku, plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane e-maile do Bob, używając narzędzi opisanych w częściach 2 i 3 tej serii.
Możesz przeanalizować zawartość certyfikatu używając:
4. Wewnętrzności: sprawdzanie DKIM, walidacja certyfikatu
Aplikacja sprawdza, czy otrzymane e-maile mają ważny DKIM i czy same certyfikaty są ważne, jak opisano tutaj. Znajdują się tam również notatki dotyczące wdrożenia oraz pomysły na dalsze działania.
Podsumowując…
Widzieliśmy, jak klucze publiczne odbiorców mogą być łatwo gromadzone za pomocą wiadomości e-mail na adres webhooks dla przychodzącej wiadomości. Po wykonaniu tego, ci odbiorcy mogą otrzymywać swoje wiadomości w szyfrowanej formie S/MIME.
To wszystko na teraz! Udanych wysyłek.