Serwer ogłasza mechanizmy uwierzytelniania po tym, jak klient wyśle EHLO. Klient kończy jeden z nich przed wysłaniem wiadomości.
Kiedy następuje uwierzytelnianie SMTP?
Klient łączy się, uruchamia TLS, gdy jest to wymagane, i wysyła EHLO. Serwer wymienia mechanizmy uwierzytelniania w odpowiedzi. Następnie klient wysyła AUTH z mechanizmem i danymi uwierzytelniającymi. Po pomyślnej wymianie klient może wydać MAIL FROM i kontynuować transakcję SMTP.
RFC 6409 oddziela przesyłanie wiadomości od przekazywania między serwerami. Wymaga od serwerów przesyłania uwierzytelniania klientów, chyba że obowiązuje wyraźny wyjątek. Ten domyślny wymóg zapobiega nieautoryzowanemu przesyłaniu. Używaj szyfrowanego połączenia przed wysłaniem danych uwierzytelniających.
| Mechanizm | Co chroni lub potwierdza |
|---|---|
| TLS | Chroni połączenie podczas transmisji |
| SMTP AUTH | Identyfikuje klienta przesyłającego wobec przekaźnika |
| SPF, DKIM i DMARC | Autoryzują lub weryfikują domenę wysyłającą |
RFC 4954 definiuje rozszerzenie AUTH oraz jego odpowiedzi sukcesu i niepowodzenia. AUTH nie dowodzi, że odbiorca zaakceptuje wiadomość.
Jakich danych uwierzytelniających używa SMTP?
Przekaźnik może używać nazwy użytkownika i hasła, klucza API jako hasła lub innego mechanizmu, który ogłasza. Traktuj obie części jako sekrety. Nie umieszczaj ich w systemie kontroli wersji ani w logach, ponieważ każdy, kto odczyta ujawnione dane uwierzytelniające, może wysyłać pocztę jako Twoje konto.
Uwierzytelnianie potwierdza, że klient może przesyłać pocztę przez dany przekaźnik. Nie dowodzi, że odbiorca zaakceptuje wiadomość. Nie dowodzi dostarczenia do skrzynki odbiorczej. Uwierzytelnianie domeny, takie jak SPF, DKIM i DMARC, dotyczy innego etapu dostarczania.
Dlaczego uwierzytelnione wysłanie nadal może się nie powieść?
Przekaźnik może odrzucić dane uwierzytelniające, uprawnienia nadawcy, politykę wiadomości lub politykę odbiorcy na różnych etapach. Odczytaj kod odpowiedzi SMTP i tekst, a następnie napraw etap, który zawiódł, zanim spróbujesz ponownie.
Pomyślne AUTH kończy jedynie logowanie. Późniejsza odpowiedź RCPT TO nadal może odrzucić odbiorcę. Dostawca odbierający nadal może odfiltrować zaakceptowaną wiadomość.
C: EHLO app.example
S: 250-AUTH PLAIN LOGIN
C: STARTTLS
S: 220 Ready to start TLS
C: EHLO app.example
C: AUTH <credentials omitted>
S: 235 Authentication successful
Serwer zwraca 535, gdy uwierzytelnianie się nie powiedzie. Nigdy nie umieszczaj prawdziwego hasła ani danych uwierzytelniających w formacie base64 w logach ani przykładach. Każdy, kto je odczyta, mógłby wysyłać pocztę jako Twoje konto.
Jak uwierzytelnić się w Bird?
Użyj hosta SMTP odpowiedniego dla regionu Twojego klucza. Wybierz port 587 ze STARTTLS lub port 465 z niejawnym TLS. Uwierzytelnij się nazwą użytkownika bird i kluczem API z zakresem emails jako hasłem. Przewodnik po przekaźniku SMTP pokazuje ustawienia połączenia i obsługę odpowiedzi.
Podsumowanie
- Uwierzytelnianie SMTP potwierdza, że klient może przesyłać pocztę przez przekaźnik.
- Uwierzytelniaj się po włączeniu szyfrowania.
- Pomyślne logowanie nie gwarantuje dostarczenia ani umieszczenia w skrzynce odbiorczej.
- Bird używa
birdjako nazwy użytkownika i klucza API jako hasła.
