S/MIME Część 4: Łatwe zbieranie kluczy publicznych odbiorców – z użyciem webhooków SparkPost Inbound Relay
Ptak
1 lut 2019
1 min read
Najważniejsze informacje
Założenie: Wysyłanie e-maili szyfrowanych za pomocą S/MIME nie jest trudne, gdy można automatycznie zbierać publiczne klucze każdego odbiorcy. Ten post zamyka tę lukę, używając SparkPost Inbound Relay Webhooks do odbierania podpisanych e-maili, wydobywania certyfikatów i przechowywania ich do późniejszego szyfrowania.
Cel: Zbudowanie usługi webhook opartej na Flasku, która nasłuchuje na przychodzące podpisane wiadomości, weryfikuje je (sprawdzanie DKIM + certyfikaty) i bezpiecznie zapisuje każdy publiczny klucz na dysku do użycia w wychodzących wiadomościach e-mail o wysokim bezpieczeństwie.
Najważniejsze punkty:
Problem: Ręczna wymiana kluczy nie działa na dużą skalę w przypadku e-maili generowanych przez aplikację.
Rozwiązanie: Zaproś użytkowników do wysłania podpisanego e-maila; przychodzący webhook automatycznie przetwarza i przechowuje ich certyfikat PEM.
Kroki konfiguracyjne:
Skonfiguruj Inbound Domain i rekordy MX (np. inbound.yourdomain.com).
Utwórz Inbound Relay Webhook za pomocą API SparkPost wskazującego na punkt końcowy aplikacji.
Wdroż małą aplikację Flask (webapp.py) korzystając z konfiguracji z webapp.ini.
Dokumentuj dogłębnie dla przejrzystości; zintegrować Pytest + Travis CI do automatycznej weryfikacji.
Środki bezpieczeństwa:
Weryfikuj podpisy DKIM i autentyczność wiadomości.
Waliduj zaufanie do łańcucha certyfikatów przed ich zapisaniem.
Użyj sekretnych tokenów uwierzytelniających w nagłówkach webhooków.
Wynik:
Każda ważna przychodząca wiadomość tworzy plik certyfikatu, taki jak bob.lumreeker@gmail.com.crt.
Po zapisaniu te klucze umożliwiają szyfrowane odpowiedzi za pomocą wcześniejszych skryptów z części 2 i 3.
Podsumowanie pytań i odpowiedzi
Dlaczego zbieranie kluczy odbiorców jest takie ważne dla S/MIME?
Ponieważ szyfrowanie wymaga publicznego klucza każdego odbiorcy; zautomatyzowanie tego kroku pozwala każdej aplikacji wysyłać bezpieczną pocztę bez ręcznej wymiany.
Jak Webhook przekazywania wiadomości SparkPost ułatwia zbieranie kluczy?
Konwertuje każdy podpisany przychodzący e-mail na ustrukturyzowany ładunek JSON, umożliwiając twojej aplikacji programowe analizowanie i przechowywanie certyfikatów.
Jakie zabezpieczenia zapobiegają podszywaniu się lub niechcianym zgłoszeniom?
Usługa weryfikuje podpisy DKIM, egzekwuje tokeny uwierzytelniające i odrzuca nieprawidłowe lub podpisane wiadomości.
Gdzie są przechowywane certyfikaty i w jakim formacie?
One są zapisane na dysku w formacie PEM (pliki
.crt), gotowe do użycia przez narzędzie do podpisywania/szyfrowania zbudowane w poprzednich częściach.Jaki jest workflow dewelopera?
Uruchom aplikację Flask, zweryfikuj za pomocą Postman przy użyciu dostarczonego przykładowego ładunku, a następnie połącz ją z aktywnym webhookiem SparkPost w celu ciągłej pracy.
Ogólne wrażenie?
Zarządzanie kluczami S/MIME można w pełni zautomatyzować za pomocą kilku linijek Pythona i SparkPost API—przynosząc skalowalne szyfrowanie do każdego generowanego przez aplikację przepływu e-mail.
W części 1 mieliśmy szybki przegląd S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 przeszła przez prostą narzędzie linii poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wprowadzić bezpieczne strumienie pocztowe do lokalnych platform takich jak Port25 PowerMTA i Momentum.
W tej serii zobaczyliśmy, jak włączenie podpisu S/MIME jest całkiem proste. Wysyłanie szyfrowanych wiadomości S/MIME jest bardziej skomplikowane, ponieważ musisz uzyskać klucze publiczne odbiorców. To jedna sprawa, gdy używasz klienta pocztowego dla ludzi, takiego jak Thunderbird – ale jak to działa z generowanymi przez aplikacje strumieniami e-maili? E-maile generowane przez aplikacje, takie jak te używane przez platformy randkowe, wymagają ostrożnej strategii, aby maksymalizować zaangażowanie. Zobacz, jak aplikacje randkowe tworzą angażujące doświadczenia z e-mailem wyzwalanym.
Ale poczekaj – jest inny sposób na wejście do Mordoru, aby zdobyć te klucze. Twój serwis może zaprosić swoich klientów (oczywiście za pośrednictwem e-maila), aby odesłali Ci podpisany e-mail na znany adres obsługi klienta. Używając magicznych mocy interfejsów API SparkPost Inbound Relay, wydobędziemy i przechowamy ten klucz publiczny, abyś mógł go użyć.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, przekazuję Twojemu serwisowi mój osobisty podpis e-mailowy za pośrednictwem e-maila, aby w przyszłości e-maile mogły być wysyłane do mnie w postaci szyfrowanej S/MIME.
Na podstawie tego wywnioskujmy bardziej szczegółowe wymagania:
Potrzebujemy nieprzerwanego, niezawodnego serwisu e-mailowego do odbierania tych podpisanych e-maili.
Nie powinno być specjalnych wymagań dotyczących formatu poczty, z wyjątkiem tego, że powinien mieć podpis S/MIME.
Ponieważ każdy może spróbować wysłać e-mail do tego serwisu, powinien być on zaprojektowany defensywnie, na przykład aby odrzucać „fałszywe” wiadomości od złych aktorów. Będzie potrzeba kilku warstw weryfikacji.
Jeśli wszystko się zgadza, serwis zapisze certyfikat w pliku, używając dobrze znanego formatu Szyfrowanej Poczty Tekstowej (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhooków między maszynami mogą być trudne do zrozumienia tylko z odpowiedzi na to, co się dzieje wewnątrz. Serwis powinien zapewniać obszerne logi aplikacji w formacie przyjaznym dla ludzi. W szczególności analiza i weryfikacja certyfikatu powinny być logowane.
Dodajemy przypadki testowe dla wewnętrznych funkcji aplikacji, korzystając z ładnego frameworka Pytest, i uruchamiamy te testy automatycznie po dodaniu zmian, korzystając z integracji Travis CI z GitHubem.
OK – zaczynajmy!
W części 1 mieliśmy szybki przegląd S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 przeszła przez prostą narzędzie linii poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wprowadzić bezpieczne strumienie pocztowe do lokalnych platform takich jak Port25 PowerMTA i Momentum.
W tej serii zobaczyliśmy, jak włączenie podpisu S/MIME jest całkiem proste. Wysyłanie szyfrowanych wiadomości S/MIME jest bardziej skomplikowane, ponieważ musisz uzyskać klucze publiczne odbiorców. To jedna sprawa, gdy używasz klienta pocztowego dla ludzi, takiego jak Thunderbird – ale jak to działa z generowanymi przez aplikacje strumieniami e-maili? E-maile generowane przez aplikacje, takie jak te używane przez platformy randkowe, wymagają ostrożnej strategii, aby maksymalizować zaangażowanie. Zobacz, jak aplikacje randkowe tworzą angażujące doświadczenia z e-mailem wyzwalanym.
Ale poczekaj – jest inny sposób na wejście do Mordoru, aby zdobyć te klucze. Twój serwis może zaprosić swoich klientów (oczywiście za pośrednictwem e-maila), aby odesłali Ci podpisany e-mail na znany adres obsługi klienta. Używając magicznych mocy interfejsów API SparkPost Inbound Relay, wydobędziemy i przechowamy ten klucz publiczny, abyś mógł go użyć.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, przekazuję Twojemu serwisowi mój osobisty podpis e-mailowy za pośrednictwem e-maila, aby w przyszłości e-maile mogły być wysyłane do mnie w postaci szyfrowanej S/MIME.
Na podstawie tego wywnioskujmy bardziej szczegółowe wymagania:
Potrzebujemy nieprzerwanego, niezawodnego serwisu e-mailowego do odbierania tych podpisanych e-maili.
Nie powinno być specjalnych wymagań dotyczących formatu poczty, z wyjątkiem tego, że powinien mieć podpis S/MIME.
Ponieważ każdy może spróbować wysłać e-mail do tego serwisu, powinien być on zaprojektowany defensywnie, na przykład aby odrzucać „fałszywe” wiadomości od złych aktorów. Będzie potrzeba kilku warstw weryfikacji.
Jeśli wszystko się zgadza, serwis zapisze certyfikat w pliku, używając dobrze znanego formatu Szyfrowanej Poczty Tekstowej (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhooków między maszynami mogą być trudne do zrozumienia tylko z odpowiedzi na to, co się dzieje wewnątrz. Serwis powinien zapewniać obszerne logi aplikacji w formacie przyjaznym dla ludzi. W szczególności analiza i weryfikacja certyfikatu powinny być logowane.
Dodajemy przypadki testowe dla wewnętrznych funkcji aplikacji, korzystając z ładnego frameworka Pytest, i uruchamiamy te testy automatycznie po dodaniu zmian, korzystając z integracji Travis CI z GitHubem.
OK – zaczynajmy!
W części 1 mieliśmy szybki przegląd S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 przeszła przez prostą narzędzie linii poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wprowadzić bezpieczne strumienie pocztowe do lokalnych platform takich jak Port25 PowerMTA i Momentum.
W tej serii zobaczyliśmy, jak włączenie podpisu S/MIME jest całkiem proste. Wysyłanie szyfrowanych wiadomości S/MIME jest bardziej skomplikowane, ponieważ musisz uzyskać klucze publiczne odbiorców. To jedna sprawa, gdy używasz klienta pocztowego dla ludzi, takiego jak Thunderbird – ale jak to działa z generowanymi przez aplikacje strumieniami e-maili? E-maile generowane przez aplikacje, takie jak te używane przez platformy randkowe, wymagają ostrożnej strategii, aby maksymalizować zaangażowanie. Zobacz, jak aplikacje randkowe tworzą angażujące doświadczenia z e-mailem wyzwalanym.
Ale poczekaj – jest inny sposób na wejście do Mordoru, aby zdobyć te klucze. Twój serwis może zaprosić swoich klientów (oczywiście za pośrednictwem e-maila), aby odesłali Ci podpisany e-mail na znany adres obsługi klienta. Używając magicznych mocy interfejsów API SparkPost Inbound Relay, wydobędziemy i przechowamy ten klucz publiczny, abyś mógł go użyć.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, przekazuję Twojemu serwisowi mój osobisty podpis e-mailowy za pośrednictwem e-maila, aby w przyszłości e-maile mogły być wysyłane do mnie w postaci szyfrowanej S/MIME.
Na podstawie tego wywnioskujmy bardziej szczegółowe wymagania:
Potrzebujemy nieprzerwanego, niezawodnego serwisu e-mailowego do odbierania tych podpisanych e-maili.
Nie powinno być specjalnych wymagań dotyczących formatu poczty, z wyjątkiem tego, że powinien mieć podpis S/MIME.
Ponieważ każdy może spróbować wysłać e-mail do tego serwisu, powinien być on zaprojektowany defensywnie, na przykład aby odrzucać „fałszywe” wiadomości od złych aktorów. Będzie potrzeba kilku warstw weryfikacji.
Jeśli wszystko się zgadza, serwis zapisze certyfikat w pliku, używając dobrze znanego formatu Szyfrowanej Poczty Tekstowej (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhooków między maszynami mogą być trudne do zrozumienia tylko z odpowiedzi na to, co się dzieje wewnątrz. Serwis powinien zapewniać obszerne logi aplikacji w formacie przyjaznym dla ludzi. W szczególności analiza i weryfikacja certyfikatu powinny być logowane.
Dodajemy przypadki testowe dla wewnętrznych funkcji aplikacji, korzystając z ładnego frameworka Pytest, i uruchamiamy te testy automatycznie po dodaniu zmian, korzystając z integracji Travis CI z GitHubem.
OK – zaczynajmy!
1. Przegląd rozwiązania
Oto jak będzie wyglądać ogólne rozwiązanie.
Oto jak będzie wyglądać ogólne rozwiązanie.
Oto jak będzie wyglądać ogólne rozwiązanie.
2. Instalacja, konfiguracja i uruchamianie aplikacji webowej
Zaczniemy od tej części, aby ją w pełni przetestować przed montażem przychodzących webhooków relay.
Aplikacja internetowa jest zawarta w tym samym projekcie GitHub co części 1 – 3, więc jeśli śledziłeś te części, już ją masz. Oto nowe elementy:
Program readSMIMEsig.py – odczytuje e-mail i wydobywa certyfikaty pośrednie i użytkowników.
Program webapp.py – prosta aplikacja internetowa kompatybilna z Flask do użycia z Webhookami Przychodzącymi SparkPost.
webapp.ini – plik konfiguracyjny dla powyższego. Plik konfiguracyjny umożliwia łatwe przekazywanie tych samych wartości zarówno do aplikacji wiersza poleceń, jak i aplikacji internetowych.
Musisz upewnić się, że twój serwer ma otwarty odpowiedni port TCP do przychodzących żądań ze świata zewnętrznego, aby SparkPost mógł wysyłać wiadomości POST do twojej aplikacji. Jeśli jest hostowana na AWS EC2, na przykład, musisz skonfigurować grupę bezpieczeństwa swojej instancji.
Instrukcje dotyczące konfigurowania i uruchamiania aplikacji internetowej są dostępne w naszym przewodniku instalacyjnym – to całkiem proste. Aby sprawdzić, czy twoja aplikacja działa i jest dostępna z zewnątrz, możesz wysłać (puste) żądania z innego hosta, używając curl, na przykład:
curl -X POST https://app.trymsys.net:8855/
Powinieneś zobaczyć odpowiedź taką jak:
{"message":"Unknown Content-Type in request headers"}
To dobry znak – twoja aplikacja działa!
W pliku webapp.log na twoim hoście zobaczysz podobne wyjście:
2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None
Aby pomóc ci od razu pracować z rzeczywistymi danymi w twojej aplikacji, możesz zaimportować to konkretne żądanie Postman z repozytorium projektu. To symuluje to, co będzie robiło twoje konto SparkPost, tzn. wysyła https POST zawierające e-mail z określonym, ważnym certyfikatem (należącym do mojego konta testowego) do twojej aplikacji.
Musisz tylko zmienić docelowy adres w żądaniu (w szarym polu powyżej), aby odpowiadał twojej instalacji. Jeśli zmieniłeś wartość tokena w webapp.ini, dostosuj wartość nagłówka w Postmanie, aby odpowiadała.
Jeśli twoja aplikacja działa, zobaczysz odpowiedź "200 OK" z powrotem w Postmanie. Plik webapp.log twojego hosta będzie zawierał wyjście podobne do tego:
2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Aby szybko sprawdzić trafność, poszukaj ostatniej linii – jeśli mówi "zapisany plik", jesteś w dobrej sytuacji. Reszta tego dokumentu pokazuje proces weryfikacji DKIM i weryfikacji certyfikatu.
Zaczniemy od tej części, aby ją w pełni przetestować przed montażem przychodzących webhooków relay.
Aplikacja internetowa jest zawarta w tym samym projekcie GitHub co części 1 – 3, więc jeśli śledziłeś te części, już ją masz. Oto nowe elementy:
Program readSMIMEsig.py – odczytuje e-mail i wydobywa certyfikaty pośrednie i użytkowników.
Program webapp.py – prosta aplikacja internetowa kompatybilna z Flask do użycia z Webhookami Przychodzącymi SparkPost.
webapp.ini – plik konfiguracyjny dla powyższego. Plik konfiguracyjny umożliwia łatwe przekazywanie tych samych wartości zarówno do aplikacji wiersza poleceń, jak i aplikacji internetowych.
Musisz upewnić się, że twój serwer ma otwarty odpowiedni port TCP do przychodzących żądań ze świata zewnętrznego, aby SparkPost mógł wysyłać wiadomości POST do twojej aplikacji. Jeśli jest hostowana na AWS EC2, na przykład, musisz skonfigurować grupę bezpieczeństwa swojej instancji.
Instrukcje dotyczące konfigurowania i uruchamiania aplikacji internetowej są dostępne w naszym przewodniku instalacyjnym – to całkiem proste. Aby sprawdzić, czy twoja aplikacja działa i jest dostępna z zewnątrz, możesz wysłać (puste) żądania z innego hosta, używając curl, na przykład:
curl -X POST https://app.trymsys.net:8855/
Powinieneś zobaczyć odpowiedź taką jak:
{"message":"Unknown Content-Type in request headers"}
To dobry znak – twoja aplikacja działa!
W pliku webapp.log na twoim hoście zobaczysz podobne wyjście:
2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None
Aby pomóc ci od razu pracować z rzeczywistymi danymi w twojej aplikacji, możesz zaimportować to konkretne żądanie Postman z repozytorium projektu. To symuluje to, co będzie robiło twoje konto SparkPost, tzn. wysyła https POST zawierające e-mail z określonym, ważnym certyfikatem (należącym do mojego konta testowego) do twojej aplikacji.
Musisz tylko zmienić docelowy adres w żądaniu (w szarym polu powyżej), aby odpowiadał twojej instalacji. Jeśli zmieniłeś wartość tokena w webapp.ini, dostosuj wartość nagłówka w Postmanie, aby odpowiadała.
Jeśli twoja aplikacja działa, zobaczysz odpowiedź "200 OK" z powrotem w Postmanie. Plik webapp.log twojego hosta będzie zawierał wyjście podobne do tego:
2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Aby szybko sprawdzić trafność, poszukaj ostatniej linii – jeśli mówi "zapisany plik", jesteś w dobrej sytuacji. Reszta tego dokumentu pokazuje proces weryfikacji DKIM i weryfikacji certyfikatu.
Zaczniemy od tej części, aby ją w pełni przetestować przed montażem przychodzących webhooków relay.
Aplikacja internetowa jest zawarta w tym samym projekcie GitHub co części 1 – 3, więc jeśli śledziłeś te części, już ją masz. Oto nowe elementy:
Program readSMIMEsig.py – odczytuje e-mail i wydobywa certyfikaty pośrednie i użytkowników.
Program webapp.py – prosta aplikacja internetowa kompatybilna z Flask do użycia z Webhookami Przychodzącymi SparkPost.
webapp.ini – plik konfiguracyjny dla powyższego. Plik konfiguracyjny umożliwia łatwe przekazywanie tych samych wartości zarówno do aplikacji wiersza poleceń, jak i aplikacji internetowych.
Musisz upewnić się, że twój serwer ma otwarty odpowiedni port TCP do przychodzących żądań ze świata zewnętrznego, aby SparkPost mógł wysyłać wiadomości POST do twojej aplikacji. Jeśli jest hostowana na AWS EC2, na przykład, musisz skonfigurować grupę bezpieczeństwa swojej instancji.
Instrukcje dotyczące konfigurowania i uruchamiania aplikacji internetowej są dostępne w naszym przewodniku instalacyjnym – to całkiem proste. Aby sprawdzić, czy twoja aplikacja działa i jest dostępna z zewnątrz, możesz wysłać (puste) żądania z innego hosta, używając curl, na przykład:
curl -X POST https://app.trymsys.net:8855/
Powinieneś zobaczyć odpowiedź taką jak:
{"message":"Unknown Content-Type in request headers"}
To dobry znak – twoja aplikacja działa!
W pliku webapp.log na twoim hoście zobaczysz podobne wyjście:
2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None
Aby pomóc ci od razu pracować z rzeczywistymi danymi w twojej aplikacji, możesz zaimportować to konkretne żądanie Postman z repozytorium projektu. To symuluje to, co będzie robiło twoje konto SparkPost, tzn. wysyła https POST zawierające e-mail z określonym, ważnym certyfikatem (należącym do mojego konta testowego) do twojej aplikacji.
Musisz tylko zmienić docelowy adres w żądaniu (w szarym polu powyżej), aby odpowiadał twojej instalacji. Jeśli zmieniłeś wartość tokena w webapp.ini, dostosuj wartość nagłówka w Postmanie, aby odpowiadała.
Jeśli twoja aplikacja działa, zobaczysz odpowiedź "200 OK" z powrotem w Postmanie. Plik webapp.log twojego hosta będzie zawierał wyjście podobne do tego:
2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Aby szybko sprawdzić trafność, poszukaj ostatniej linii – jeśli mówi "zapisany plik", jesteś w dobrej sytuacji. Reszta tego dokumentu pokazuje proces weryfikacji DKIM i weryfikacji certyfikatu.
3. Konfiguracja webhooków relacji przychodzących SparkPost
Po pierwsze, wybieramy domenę, którą wykorzystamy jako nasz adres do odbierania wiadomości – tu będzie to inbound.thetucks.com. Skonfiguruj swoją domenę, postępując według tego przewodnika. Oto kroki, które użyłem szczegółowo:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego specyficznego konta dostawcy usług internetowych. Po zakończeniu możesz je sprawdzić za pomocą dig – oto komenda dla mojej domeny.
dig +short MX inbound.thetucks.com
Powinieneś zobaczyć:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Utwórz domenę przychodzącą
Użyj kolekcji API SparkPost Postman API collection, wybierając ziemię przychodzącą / Utwórz ... wywołanie. Treść żądania POST zawiera twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz webhook przekazywania
Utwórz przychodzący webhook przekazywania za pomocą odpowiedniego wywołania Postman. Treść wiadomości w moim przypadku zawiera:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Jak już wcześniej wspomniałem, zalecam ustawienie auth_token na swoją własną tajną wartość, jak ustalone w pliku webapp.ini na Twoim hoście.
Twoja wartość „target” musi odpowiadać adresowi Twojego hosta i porcie TCP, na którym uruchomisz aplikację internetową.
Twoja wartość „domain” musi odpowiadać rekordom MX skonfigurowanym w kroku 1.
To wszystko! Instalacja została zakończona. Teraz powinieneś być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetwarzane i pojawią się na hoście Twojej aplikacji internetowej – w tym przypadku plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane e-maile do Boba, korzystając z narzędzi opisanych w częściach 2 & 3 tej serii.
Możesz zbadać zawartość certyfikatu, używając:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Po pierwsze, wybieramy domenę, którą wykorzystamy jako nasz adres do odbierania wiadomości – tu będzie to inbound.thetucks.com. Skonfiguruj swoją domenę, postępując według tego przewodnika. Oto kroki, które użyłem szczegółowo:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego specyficznego konta dostawcy usług internetowych. Po zakończeniu możesz je sprawdzić za pomocą dig – oto komenda dla mojej domeny.
dig +short MX inbound.thetucks.com
Powinieneś zobaczyć:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Utwórz domenę przychodzącą
Użyj kolekcji API SparkPost Postman API collection, wybierając ziemię przychodzącą / Utwórz ... wywołanie. Treść żądania POST zawiera twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz webhook przekazywania
Utwórz przychodzący webhook przekazywania za pomocą odpowiedniego wywołania Postman. Treść wiadomości w moim przypadku zawiera:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Jak już wcześniej wspomniałem, zalecam ustawienie auth_token na swoją własną tajną wartość, jak ustalone w pliku webapp.ini na Twoim hoście.
Twoja wartość „target” musi odpowiadać adresowi Twojego hosta i porcie TCP, na którym uruchomisz aplikację internetową.
Twoja wartość „domain” musi odpowiadać rekordom MX skonfigurowanym w kroku 1.
To wszystko! Instalacja została zakończona. Teraz powinieneś być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetwarzane i pojawią się na hoście Twojej aplikacji internetowej – w tym przypadku plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane e-maile do Boba, korzystając z narzędzi opisanych w częściach 2 & 3 tej serii.
Możesz zbadać zawartość certyfikatu, używając:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Po pierwsze, wybieramy domenę, którą wykorzystamy jako nasz adres do odbierania wiadomości – tu będzie to inbound.thetucks.com. Skonfiguruj swoją domenę, postępując według tego przewodnika. Oto kroki, które użyłem szczegółowo:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego specyficznego konta dostawcy usług internetowych. Po zakończeniu możesz je sprawdzić za pomocą dig – oto komenda dla mojej domeny.
dig +short MX inbound.thetucks.com
Powinieneś zobaczyć:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Utwórz domenę przychodzącą
Użyj kolekcji API SparkPost Postman API collection, wybierając ziemię przychodzącą / Utwórz ... wywołanie. Treść żądania POST zawiera twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz webhook przekazywania
Utwórz przychodzący webhook przekazywania za pomocą odpowiedniego wywołania Postman. Treść wiadomości w moim przypadku zawiera:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Jak już wcześniej wspomniałem, zalecam ustawienie auth_token na swoją własną tajną wartość, jak ustalone w pliku webapp.ini na Twoim hoście.
Twoja wartość „target” musi odpowiadać adresowi Twojego hosta i porcie TCP, na którym uruchomisz aplikację internetową.
Twoja wartość „domain” musi odpowiadać rekordom MX skonfigurowanym w kroku 1.
To wszystko! Instalacja została zakończona. Teraz powinieneś być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetwarzane i pojawią się na hoście Twojej aplikacji internetowej – w tym przypadku plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane e-maile do Boba, korzystając z narzędzi opisanych w częściach 2 & 3 tej serii.
Możesz zbadać zawartość certyfikatu, używając:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Wewnętrzne: sprawdzanie DKIM, walidacja certyfikatów
Aplikacja sprawdza, czy otrzymane e-maile mają ważny DKIM i sprawdza, czy same certyfikaty są ważne, jak opisano tutaj. Znajdziesz tam także notatki dotyczące implementacji oraz pomysły na dalsze prace.
Aplikacja sprawdza, czy otrzymane e-maile mają ważny DKIM i sprawdza, czy same certyfikaty są ważne, jak opisano tutaj. Znajdziesz tam także notatki dotyczące implementacji oraz pomysły na dalsze prace.
Aplikacja sprawdza, czy otrzymane e-maile mają ważny DKIM i sprawdza, czy same certyfikaty są ważne, jak opisano tutaj. Znajdziesz tam także notatki dotyczące implementacji oraz pomysły na dalsze prace.
Podsumowując…
Widzieliśmy, jak klucze publiczne odbiorców można łatwo zbierać, używając e-maila do adresu webhooka przychodzącego. Po zakończeniu, ci odbiorcy mogą otrzymywać swoje wiadomości w formie zaszyfrowanej S/MIME.
Na tym na razie kończymy! Szczęśliwego wysyłania.
Widzieliśmy, jak klucze publiczne odbiorców można łatwo zbierać, używając e-maila do adresu webhooka przychodzącego. Po zakończeniu, ci odbiorcy mogą otrzymywać swoje wiadomości w formie zaszyfrowanej S/MIME.
Na tym na razie kończymy! Szczęśliwego wysyłania.
Widzieliśmy, jak klucze publiczne odbiorców można łatwo zbierać, używając e-maila do adresu webhooka przychodzącego. Po zakończeniu, ci odbiorcy mogą otrzymywać swoje wiadomości w formie zaszyfrowanej S/MIME.
Na tym na razie kończymy! Szczęśliwego wysyłania.
