SMTP czy API e-mail: co wybrać dla swojej aplikacji?

Prędzej czy później każdy produkt musi wysyłać e-maile, a pierwsze pytanie brzmi: jak Twój kod ma rozmawiać z systemem pocztowym? Są dwie odpowiedzi: komunikować się bezpośrednio przez SMTP albo wywoływać API e-mail przez HTTPS.

Obie działają. Stawiają jednak Twojej aplikacji zupełnie różne wymagania, a właściwy wybór zależy od tego, gdzie działa Twój kod i ile infrastruktury pocztowej chcesz utrzymywać sam.

W czym SMTP jest dobry

SMTP (Simple Mail Transfer Protocol) to sposób, w jaki serwery pocztowe wymieniają e-maile od początku lat 80. Obsługuje go każdy dostawca skrzynek, a niemal każdy framework ma wbudowaną obsługę wysyłki przez SMTP: Nodemailer, send_mail w Django, Laravel Mail, Action Mailer w Rails.

Zalety:

• Uniwersalność. Obsługuje go każde konto e-mail i każdy język.
• Brak uzależnienia od dostawcy. Zmieniasz dostawcę, zmieniając nazwę hosta i hasło.
• Własna domena i reputacja. Poczta wychodzi przez serwer, który kontrolujesz lub wynajmujesz, z adresów w Twojej domenie.

Gdzie SMTP przeszkadza w aplikacji

SMTP to rozmowny, stanowy protokół. Aby wysłać jedną wiadomość, aplikacja otwiera połączenie TCP, wita się z serwerem, przełącza się na TLS, uwierzytelnia, a potem przechodzi przez serię poleceń i odpowiedzi dla nadawcy, odbiorcy i danych. Każdy krok to przejście przez sieć tam i z powrotem.

W praktyce prowadzi to do:

• Wolnych żądań. Nawiązanie połączenia z odległym serwerem może zająć setki milisekund, zanim w ogóle zacznie się przesyłanie wiadomości.
• Zablokowanych portów. Wiele platform chmurowych i środowisk serverless ogranicza wychodzące porty 25, 465 i 587, by walczyć ze spamem. HTTPS na porcie 443 prawie nigdy nie jest blokowany.
• Danych logowania wszędzie. Każda usługa wysyłająca pocztę potrzebuje hasła do skrzynki. Jego zmiana oznacza ponowne wdrożenie wszystkich usług.
• Słabej widoczności. Gdy coś się nie uda, błąd zostaje w logach jednej usługi, o ile w ogóle został zalogowany.

Co zmienia API e-mail

API e-mail opakowuje wysyłkę w jedno żądanie HTTPS z treścią JSON. Twój kod wykonuje jeden POST i dostaje z powrotem kod statusu. Połączenie SMTP i dane logowania trzyma usługa API.

Zalety:

• Jedno szybkie żądanie przez port 443, z dowolnego miejsca: kontenerów, funkcji serverless, środowisk edge, zadań CI.
• Klucze zamiast haseł. Każda usługa dostaje własny klucz API z ograniczonymi uprawnieniami, a jeden możesz unieważnić lub zrotować bez ruszania pozostałych.
• Centralna widoczność. Wywołania API i wyniki dostarczania są śledzone w jednym miejscu.
• Zwykłe błędy HTTP. 401 czy 429 znacznie łatwiej obsłużyć niż kod odpowiedzi SMTP zakopany w stack trace.

Kompromis: w większości API e-mail poczta wychodzi przez ich serwery, więc przejmujesz ich konfigurację domeny nadawczej i reputację IP, a późniejsza przeprowadzka oznacza ponowną weryfikację wszystkiego gdzie indziej.

Inbixio: API przed Twoim serwerem SMTP

Inbixio opiera się na prostym pomyśle: zachować to, co w SMTP wartościowe, czyli własny serwer pocztowy i tożsamość nadawcy, a zastąpić to, co przeszkadza w aplikacjach.

1. Raz podłączasz serwer SMTP w panelu: host, port, nazwę użytkownika i hasło.
2. Twoje usługi wywołują POST /api/send-email/ z kluczem API Inbixio.
3. Inbixio loguje się do Twojego serwera SMTP przez TLS i dostarcza wiadomość z Twojego adresu.
4. Panel pokazuje liczbę wysłanych e-maili, odsetek nieudanych dostarczeń i opóźnienie dostarczania, a także log każdego wywołania API.

curl -X POST https://backend.inbixio.com/api/send-email/ \
  -H "X-API-Key: $INBIXIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to_email":"user@example.com","subject":"Welcome!","message":"<h1>Hello</h1>"}'

Co Ci to daje:

• Hasło SMTP jest przechowywane w jednym miejscu. Twoje usługi widzą wyłącznie klucze API.
• Klucze można przypiąć do jednego konkretnego serwera, więc usługa rozliczeń wysyła z billing@, a usługa uwierzytelniania z security@.
• Uprawnienia każdego klucza są jawne, a klucz można odnowić lub usunąć bez ruszania serwera pocztowego.
• Zachowujesz domenę nadawczą, dostawcę i reputację. Jeśli zmienisz dostawcę poczty, aktualizujesz jeden wpis serwera, a Twój kod się nie zmienia.

Porównanie

Co więc wybrać?

• Używaj bezpośrednio SMTP w pojedynczej małej aplikacji na serwerze, na którym wychodzący ruch SMTP jest dozwolony, a zarządzanie tam danymi logowania Ci nie przeszkadza.
• Używaj API e-mail, gdy masz kilka usług, wdrażasz na platformy blokujące porty SMTP, chcesz centralnych logów albo chcesz przestać przekazywać sobie hasła do skrzynek.
• Używaj Inbixio, gdy chcesz tych korzyści z API, ale zależy Ci też na tym, by poczta nadal płynęła przez Twój własny serwer pocztowy i domenę.

Chcesz spróbować? Pięciominutowy szybki start przeprowadzi Cię od rejestracji do dostarczonego e-maila.