Rozszerzony SMTP - Extended SMTP

Extended SMTP ( ESMTP ), czasami określany jako Enhanced SMTP , to definicja rozszerzeń protokołu w stosunku do standardu Simple Mail Transfer Protocol (SMTP). ESMTP zostało zdefiniowane w listopadzie 1995 r. W publikacji IETF RFC 1869, która ustanowiła ogólną strukturę dla wszystkich istniejących i przyszłych rozszerzeń.

ESMTP definiuje spójne i łatwe w zarządzaniu środki, za pomocą których można identyfikować klientów i serwery ESMTP, a serwery mogą wskazywać obsługiwane rozszerzenia.

Rozszerzenia

Podobnie jak SMTP, ESMTP jest protokołem używanym do przesyłania poczty internetowej. Jest używany zarówno jako protokół transportowy między serwerami, jak i (z wymuszonym zachowaniem) protokół przesyłania poczty.

Główną cechą identyfikacyjną klientów ESMTP jest otwarcie transmisji za pomocą polecenia EHLO(Extended HELLO), a nie HELO(Hello, oryginalny standard RFC 821 ). W zależności od konfiguracji serwer odpowie sukcesem (kod 250), niepowodzeniem (kod 550) lub błędem (kod 500, 501, 502, 504 lub 421). Serwer ESMTP zwraca kod 250 OK w wielowierszowej odpowiedzi ze swoją domeną i listą słów kluczowych wskazujących obsługiwane rozszerzenia. RFC 821 kod błędu zgodne powraca serwer 500, dzięki czemu klienci ESMTP spróbować albo HELOalbo QUIT.

Każde rozszerzenie usługi jest zdefiniowane w zatwierdzonym formacie w kolejnych RFC i zarejestrowane w Internet Assigned Numbers Authority (IANA). Pierwsze definicje były RFC 821 opcjonalne usługi: SEND, SOML(wysyłanie lub Mail), SAML(wysyłanie i Mail), EXPN, HELP, i TURN. Ustawiono format dodatkowych czasowników SMTP oraz nowe parametry w MAILi RCPT.

Niektóre stosunkowo popularne słowa kluczowe (nie wszystkie z nich odpowiadają poleceniom) używane obecnie to:

Format ESMTP został ponownie zmieniony w RFC 2821 (zastępującym RFC 821 ) i zaktualizowany do najnowszej definicji w RFC 5321 w 2008 roku. Obsługa EHLOpolecenia na serwerach stała się obowiązkowa i HELOwyznaczyła wymaganą rezerwę.

Z niestandardowych, niezarejestrowanych rozszerzeń usług można skorzystać na podstawie umowy bilateralnej, usługi te są oznaczone EHLOsłowem kluczowym wiadomości zaczynającym się od „X”, z dodatkowymi parametrami lub czasownikami podobnie oznaczonymi.

W poleceniach SMTP wielkość liter nie jest rozróżniana. Przedstawiono je tutaj wielką literą tylko dla podkreślenia. Serwer SMTP, który wymaga określonej metody kapitalizacji, stanowi naruszenie standardu.

Lista obsługiwanych serwerów

  • IceWarp
  • Postfix  - brak poprawek potrzebnych do RFC 6531 .. RFC 6533 .
  • Sendmail  - łatka do kodu źródłowego niezbędna do obsługi SMTPUTF8
  • HMailServer  - darmowy serwer pocztowy dla Windows
  • Exim
  • MailEnable - wsparcie tylko w Enterprise Edition
  • MagicMail - wykładanie rur celowo nie jest obsługiwane

8BITMIME

Lista obsługiwanych serwerów

Przynajmniej następujące serwery reklamują rozszerzenie 8BITMIME:

Następujące serwery można skonfigurować do ogłaszania 8BITMIME, ale nie wykonują konwersji danych 8-bitowych na 7-bitowe podczas łączenia się z przekaźnikami innymi niż 8BITMIME:

  • Exim i qmail nie tłumaczą wiadomości ośmiobitowych na siedmiobitowe podczas próby przekazania 8-bitowych danych do rówieśników innych niż 8BITMIME, jak jest to wymagane przez RFC. W praktyce nie powoduje to problemów, ponieważ praktycznie wszystkie współczesne przekaźniki pocztowe są czyste 8-bitowo .
  • Microsoft Exchange Server 2003 domyślnie ogłasza 8BITMIME, ale przekazanie do partnera innego niż 8BITMIME powoduje odrzucenie. Jest to dozwolone przez RFC 6152 sekcja 3 .

SMTP-AUTH

Główny artykuł: Uwierzytelnianie SMTP

Rozszerzenie SMTP-AUTH zapewnia mechanizm kontroli dostępu. Składa się z kroku uwierzytelniania, dzięki któremu klient efektywnie loguje się do serwera poczty podczas procesu wysyłania poczty. Serwery obsługujące SMTP-AUTH można zwykle skonfigurować tak, aby wymagały od klientów korzystania z tego rozszerzenia, dzięki czemu znana jest prawdziwa tożsamość nadawcy. Rozszerzenie SMTP-AUTH jest zdefiniowane w RFC 4954.

SMTP-AUTH może służyć do zezwalania uprawnionym użytkownikom na przekazywanie poczty, jednocześnie odmawiając usługi przekazywania nieautoryzowanym użytkownikom, takim jak spamerzy . Niekoniecznie gwarantuje to autentyczność nadawcy w kopercie SMTP lub nagłówka „Od:” RFC 2822. Na przykład spoofing , w którym jeden nadawca podszywa się pod kogoś innego, jest nadal możliwy przy użyciu SMTP-AUTH, chyba że serwer jest skonfigurowany tak, aby ograniczać wiadomości od-adresy do adresów, do których ten AUTHED użytkownik jest upoważniony.

Rozszerzenie SMTP-AUTH umożliwia także jednemu serwerowi poczty wskazanie drugiemu, że nadawca został uwierzytelniony podczas przekazywania poczty. Ogólnie wymaga to od serwera odbiorcy zaufania serwerowi wysyłającemu, co oznacza, że ​​ten aspekt SMTP-AUTH jest rzadko używany w Internecie.

SMTPUTF8

Lista obsługiwanych serwerów

Lista obsługiwanych serwerów lokalnych

Lokalne serwery dostarczania (LMTP)

  • Żaden

Lista klientów wspierających

  • nmh (od wersji 1.7)

Lista obsługiwanych filtrów treści

  • Amavis (SMTP i LMTP) od wersji 2.10.0

Zobacz też

Bibliografia

Zewnętrzne linki