Adres e-mail — Email address

Adres email identyfikuje e-mail pole, do którego wiadomości są dostarczane. Podczas gdy wczesne systemy przesyłania wiadomości wykorzystywały różne formaty adresowania, dziś adresy e-mail podlegają zbiorowi określonych reguł, które zostały pierwotnie ustandaryzowane przez Internet Engineering Task Force (IETF) w latach 80. XX wieku i zaktualizowane przez RFC  5322 i 6854 . Termin adres e-mail w tym artykule odnosi się do specyfikacji adresu w RFC 5322, a nie do adresu lub skrzynki pocztowej ; tj. surowy adres bez wyświetlanej nazwy .

Adres e-mail, taki jak jan.kowalski@example.com , składa się z części lokalnej , symbolu @ i domeny , która może być nazwą domeny lub adresem IP ujętym w nawiasy kwadratowe. Chociaż standard wymaga, aby część lokalna uwzględniała wielkość liter, zaleca się również, aby hosty odbierające dostarczały wiadomości w sposób niezależny od wielkości liter, np. aby system poczty w domenie example.com traktował John.Smith jako odpowiednik john.smith ; niektóre systemy pocztowe traktują je nawet jako odpowiedniki johnsmith . Systemy pocztowe często ograniczają wybór nazwy przez użytkownika do podzbioru technicznie dozwolonych znaków.

Wraz z wprowadzeniem umiędzynarodowionych nazw domen postępują wysiłki, aby dopuścić znaki spoza ASCII w adresach e-mail.

Transport wiadomości

Adres e-mail składa się z dwóch części, części lokalnej i domeny; jeśli domena jest nazwą domeny, a nie adresem IP, klient SMTP używa nazwy domeny do wyszukiwania adresu IP wymiany poczty. Ogólny format adresu e-mail to część lokalna @ domain , np. jkowalski@[192.168.1.2], jkowalski@example.com . Klient SMTP przesyła wiadomość do wymiany poczty, która może przekazać ją do innej wymiany poczty, aż w końcu dotrze do hosta systemu pocztowego odbiorcy.

Transmisja poczty elektronicznej z komputera autora oraz pomiędzy hostami pocztowymi w Internecie wykorzystuje protokół SMTP ( Simple Mail Transfer Protocol ), zdefiniowany w RFC  5321 i 5322 oraz rozszerzenia takie jak RFC 6531. Dostęp do skrzynek pocztowych i zarządzanie nimi może odbywać się za pomocą aplikacji na komputery osobiste, urządzenia mobilne lub witryny poczty internetowej, korzystające z protokołu SMTP i protokołu POP ( Post Office Protocol ) lub protokołu IMAP ( Internet Message Access Protocol ).

Podczas przesyłania wiadomości e-mail , MUA (MUA) i środki przesyłania poczty (MTA) korzystać z systemu nazw domen (DNS), aby spojrzeć w górę do zasobów rekordu (RR) dla domeny odbiorcy. Rekord zasobu usługi wymiany poczty ( rekord MX ) zawiera nazwę serwera poczty adresata. W przypadku braku rekordu MX, rekord adresu ( A lub AAAA ) bezpośrednio określa hosta poczty.

Lokalna część adresu e-mail nie ma znaczenia dla pośrednich systemów przekazywania poczty innych niż końcowy host skrzynki pocztowej. Nadawcy wiadomości e-mail i pośrednie systemy przekazujące nie mogą zakładać, że wielkość liter nie jest rozróżniana, ponieważ końcowy host skrzynki pocztowej może, ale nie musi, traktować go jako takiego. Pojedyncza skrzynka pocztowa może odbierać pocztę z wielu adresów e-mail, jeśli została skonfigurowana przez administratora. I odwrotnie, pojedynczy adres e-mail może być aliasem listy dystrybucyjnej do wielu skrzynek pocztowych. Aliasy e-mail , elektroniczne listy mailingowe , adresy podrzędne i adresy typu catch-all , te ostatnie to skrzynki pocztowe, które odbierają wiadomości niezależnie od ich części lokalnej, to typowe wzorce służące do osiągania różnych celów dostarczania.

Adresy znajdujące się w polach nagłówka wiadomości e-mail nie są bezpośrednio używane przez giełdy poczty do dostarczania wiadomości. Wiadomość e-mail zawiera również kopertę wiadomości zawierającą informacje dotyczące routingu poczty. Chociaż adresy koperty i nagłówka mogą być takie same, sfałszowane adresy e- mail – zwane również sfałszowanymi adresami e-mail – są często spotykane w spamie , phishingu i wielu innych oszustwach internetowych. Doprowadziło to do powstania kilku inicjatyw, których celem jest ułatwienie wykrywania takich fałszerstw fałszywych wiadomości e-mail.

Składnia

Format adresu e-mail to local-part@domain , gdzie część lokalna może mieć długość do 64 oktetów, a domena może mieć maksymalnie 255 oktetów. Formalne definicje znajdują się w RFC 5322 (sekcje 3.2.3 i 3.4.1) oraz RFC 5321 — z bardziej czytelną formą podaną w informacyjnym dokumencie RFC 3696 i powiązanej erracie.

Z adresem e-mail może być również powiązana wyświetlana nazwa odbiorcy, która poprzedza specyfikację adresu, teraz otoczoną nawiasami ostrymi , na przykład: Jan Kowalski <jan.kowalski@example.org> .

Wcześniejsze formy adresów e-mail dla innych sieci niż Internet zawierały inne notacje, takie jak wymagana przez X.400 oraz notację UUCP bang path , w której adres był podawany w postaci sekwencji komputerów, przez które wiadomość powinna być przekazywane. To było powszechnie stosowane przez kilka lat, ale zostało zastąpione przez standardy internetowe ogłoszone przez Internet Engineering Task Force (IETF).

Część lokalna

Lokalna część adresu e-mail może nie być cytowana lub może być ujęta w cudzysłów.

Jeśli nie jest cytowany, może używać dowolnego z tych znaków ASCII :

  • Wielkie i małe łacińskie litery Acelu Zi adoz
  • cyfry 0do9
  • znaki do druku !#$%&'*+-/=?^_`{|}~
  • kropka ., pod warunkiem, że nie jest to pierwszy ani ostatni znak i pod warunkiem, że nie pojawia się kolejno (np. John..Doe@example.comniedozwolone).

Jeśli jest cytowany, może zawierać spację, zakładkę poziomą (HT), dowolną grafikę ASCII z wyjątkiem odwrotnego ukośnika i cytatu oraz parę cytatów składającą się z odwróconego ukośnika, po którym następuje HT, spacja lub dowolna grafika ASCII; może być również podzielony między wiersze w dowolnym miejscu, w którym pojawia się HT lub spacja. W przeciwieństwie do nienotowanych lokalnej części, adresy ".John.Doe"@example.com, "John.Doe."@example.comi "John..Doe"@example.comsą dozwolone.

Maksymalna całkowita długość lokalnej części adresu e-mail to 64 oktety.

Zwróć uwagę, że niektóre serwery pocztowe obsługują rozpoznawanie elementów lokalnych za pomocą symboli wieloznacznych, zazwyczaj znaki po plusie i rzadziej znaki po minusie, więc fred+bah@domena i fred+foo@domena mogą trafić do tej samej skrzynki odbiorczej co fred+@domena lub nawet jako fred@domain. Może to być przydatne do oznaczania wiadomości e-mail w celu sortowania (patrz poniżej) oraz do kontroli spamu. Szelki {i }są również używane w ten sposób, choć rzadziej.

  • spacja i znaki specjalne "(),:;<>@[\]są dozwolone z ograniczeniami (są one dozwolone tylko w ciągu znaków w cudzysłowie, jak opisano w poniższym akapicie, a w tym ciągu w cudzysłowie każdy ukośnik odwrotny lub podwójny cudzysłów musi być poprzedzony jednym ukośnikiem odwrotnym);
  • komentarze są dozwolone z nawiasami na obu końcach części lokalnej; np. john.smith(comment)@example.comi (comment)john.smith@example.comoba są równoważne john.smith@example.com.

Oprócz powyższych znaków ASCII, znaki międzynarodowe powyżej U+007F, zakodowane jako UTF-8 , są dozwolone przez RFC 6531, chociaż nawet systemy pocztowe obsługujące SMTPUTF8 i 8BITMIME mogą ograniczać użycie znaków podczas przypisywania części lokalnych.

Część lokalna jest ciągiem kropkowym lub ciągiem w cudzysłowie; to nie może być kombinacja. Cytowane ciągi i znaki nie są jednak powszechnie używane. RFC 5321 ostrzega również, że „host, który oczekuje na odbieranie poczty POWINIEN unikać definiowania skrzynek pocztowych, w których część lokalna wymaga (lub używa) formularza ciągu w cudzysłowie”.

Część lokalna postmasterjest traktowana specjalnie — nie jest w niej rozróżniana wielkość liter i powinna zostać przekazana administratorowi poczty e-mail domeny. Technicznie wszystkie inne części są lokalni wielkość liter, więc jsmith@example.comi JSmith@example.comokreślenie różnych skrzynek pocztowych; jednak wiele organizacji traktuje wielkie i małe litery jako równoważne. Rzeczywiście, RFC 5321 ostrzega, że ​​„host, który oczekuje na odbiór poczty POWINIEN unikać definiowania skrzynek pocztowych, w których… część lokalna rozróżnia wielkość liter”.

Pomimo szerokiego zakresu znaków specjalnych, które są ważne technicznie, organizacje, usługi pocztowe, serwery pocztowe i klienci poczty w praktyce często nie akceptują ich wszystkich. Na przykład usługa Windows Live Hotmail umożliwia tylko tworzenie adresów e-mail przy użyciu znaków alfanumerycznych, kropki ( .), podkreślenia ( _) i łącznika ( -). Powszechną radą jest unikanie używania niektórych znaków specjalnych, aby uniknąć ryzyka odrzucenia wiadomości e-mail.

Domena

Część adresu e-mail dotycząca nazwy domeny musi być zgodna ze ścisłymi wytycznymi: musi odpowiadać wymaganiom nazwy hosta , listy oddzielonych kropkami etykiet DNS , przy czym każda etykieta jest ograniczona do 63 znaków i składa się z:

  • Wielkie i małe łacińskie litery Ado Zi ado z;
  • cyfry 0do 9, pod warunkiem, że nazwy domen najwyższego poziomu nie są wyłącznie numeryczne;
  • myślnik -, pod warunkiem, że nie jest to pierwszy ani ostatni znak.

Ta zasada jest znana jako zasada LDH (litery, cyfry, myślnik). Ponadto domena może być literałem adresu IP ujętym w nawiasy kwadratowe [], na przykład jsmith@[192.168.2.1]lub jsmith@[IPv6:2001:db8::1], chociaż jest to rzadko spotykane, z wyjątkiem spamu e-mailowego . Umiędzynarodowione nazwy domen (które są zakodowane zgodnie z wymaganiami nazwy hosta ) umożliwiają prezentację domen innych niż ASCII. W systemach pocztowych zgodnych z RFC 6531 i RFC 6532 adres e-mail może być zakodowany jako UTF-8 , zarówno jako część lokalna, jak i nazwa domeny.

Komentarze są dozwolone zarówno w domenie, jak iw części lokalnej; na przykład john.smith@(comment)example.comi john.smith@example.com(comment)są równoważne john.smith@example.com.

Zarezerwowane domeny

RFC  2606 określa, że ​​niektóre domeny, na przykład te przeznaczone do dokumentacji i testowania, nie powinny być rozwiązywalne i że w rezultacie poczta adresowana do znajdujących się w nich skrzynek pocztowych i ich poddomen nie powinna być dostarczana. W przypadku wiadomości e-mail warto zwrócić uwagę na przykład , nieprawidłowy , przyklad.com , przyklad.net i przyklad.org .

Przykłady

Prawidłowe adresy e-mail
simple@example.com
very.common@example.com
disposable.style.email.with+symbol@example.com
other.email-with-hyphen@example.com
fully-qualified-domain@example.com
user.name+tag+sorting@example.com(może trafić do user.name@example.comskrzynki odbiorczej w zależności od serwera pocztowego)
x@example.com (jednoliterowa część lokalna)
example-indeed@strange-example.com
test/test@test.com (ukośniki są znakami drukowalnymi i są dozwolone)
admin@mailserver1(lokalna nazwa domeny bez TLD , chociaż ICANN zdecydowanie odradza adresy e-mail bez kropek)
example@s.example(patrz Lista domen internetowych najwyższego poziomu )
" "@example.org (spacja między cudzysłowami)
"john..doe"@example.org (cytowana podwójna kropka)
mailhost!username@example.org (zangażowana trasa hosta używana dla mailerów uucp)
user%example.com@example.org (% trasa poczty ze znakami ucieczki na adres użytkownik@example.com przez example.org)
user-@example.org (część lokalna kończąca się znakiem niealfanumerycznym z listy dozwolonych znaków drukowalnych)


Nieprawidłowe adresy e-mail
Abc.example.com (bez znaku @)
A@b@c@example.com (tylko jeden znak @ jest dozwolony poza cudzysłowami)
a"b(c)d,e:f;g<h>i[j\k]l@example.com (żaden ze znaków specjalnych w tej części lokalnej nie jest dozwolony poza cudzysłowami)
just"not"right@example.com (ciągi w cudzysłowie muszą być oddzielone kropkami lub jako jedyny element tworzący część lokalną)
this is"not\allowed@example.com (spacje, cudzysłowy i odwrotne ukośniki mogą istnieć tylko wtedy, gdy znajdują się w ciągach w cudzysłowie i są poprzedzone odwrotnym ukośnikiem)
this\ still\"not\\allowed@example.com (nawet jeśli zostały zmienione (poprzedzone odwrotnym ukośnikiem), spacje, cudzysłowy i odwrotne ukośniki muszą nadal być zawarte w cudzysłowie)
1234567890123456789012345678901234567890123456789012345678901234+x@example.com (część lokalna jest dłuższa niż 64 znaki)
i_like_underscore@but_its_not_allowed_in_this_part.example.com (Podkreślenie nie jest dozwolone w części domeny)
QA[icon]CHOCOLATE[icon]@test.com (znaki ikon)

Wspólna semantyka części lokalnej

Zgodnie z RFC 5321 2.3.11 Skrzynka pocztowa i adres, „...część lokalna MUSI być interpretowana i przypisywana semantyce tylko przez hosta określonego w domenie adresu”. Oznacza to, że nie można przyjąć żadnych założeń dotyczących znaczenia części lokalnej innego serwera pocztowego. Wszystko zależy od konfiguracji serwera pocztowego.

Normalizacja części lokalnej

Interpretacja lokalnej części adresu e-mail jest uzależniona od konwencji i polityk zaimplementowanych na serwerze pocztowym. Na przykład rozróżnianie wielkości liter może rozróżniać skrzynki pocztowe różniące się tylko wielkością znaków części lokalnej, chociaż nie jest to bardzo powszechne. Gmail ignoruje wszystkie kropki w lokalnej części adresu @gmail.com w celu określenia tożsamości konta.

Podadresowanie

Niektóre usługi pocztowe obsługują znacznik zawarty w części lokalnej, tak że adres jest aliasem przedrostka części lokalnej. Na przykład adres jan+tag@example.com oznacza ten sam adres dostawy co jan@example.com . RFC 5233, odnosi się do tej konwencji jako sub-adresowania , ale jest również znany jako Plus adresowania , oznaczonych adresowania lub rozszerzeń pocztowych .

Adresy tego formularza, wykorzystujące różne separatory między nazwą podstawową a tagiem, są obsługiwane przez kilka usług pocztowych, w tym Andrew Project (plus), Runbox (plus), Gmail (plus), Rackspace (plus), Yahoo! Mail Plus (łącznik), Apple iCloud (plus), Outlook.com (plus), ProtonMail (plus), Fastmail (plus i adresowanie poddomen), postale.io (plus), Pobox (plus), MeMail (plus), MMDF (równa się), Qmail i Courier Mail Server (łącznik). Postfix i Exim umożliwiają skonfigurowanie dowolnego separatora z zestawu znaków prawnych.

Tekst tagu może służyć do filtrowania lub tworzenia jednorazowych lub jednorazowych adresów e-mail .

W praktyce walidacja formularzy niektórych witryn internetowych może odrzucać znaki takie jak „+” w adresie e-mail – traktując je błędnie, jako nieprawidłowe znaki. Może to prowadzić do otrzymania wiadomości e-mail przez nieprawidłowego użytkownika, jeśli znak „+” zostanie po cichu usunięty przez witrynę bez żadnych ostrzeżeń ani komunikatów o błędach. Na przykład wiadomość e-mail przeznaczona dla adresu e-mail wprowadzonego przez użytkownika foo+bar@example.com może zostać błędnie wysłana na adres foobar@example.com. W innych przypadkach może wystąpić złe doświadczenie użytkownika, jeśli niektóre części witryny, takie jak strona rejestracji użytkownika, zezwalają na znak „+”, podczas gdy inne części, takie jak strona do anulowania subskrypcji listy mailingowej witryny, nie.

Walidacja i weryfikacja

Adresy e-mail są często wymagane jako dane wejściowe do witryny internetowej jako potwierdzenie istnienia użytkownika. Dostępne są inne metody weryfikacji, takie jak weryfikacja numeru telefonu komórkowego, weryfikacja poczty pocztowej i weryfikacja faksu.

Ogólnie uznaje się, że adres e-mail ma dwie części połączone znakiem „at” ( @ ), chociaż specyfikacja techniczna szczegółowo opisana w RFC 822 i kolejnych dokumentach RFC jest bardziej obszerna.

Poprawne składniowo, zweryfikowane adresy e-mail nie gwarantują istnienia skrzynki e-mail . W związku z tym wiele serwerów pocztowych błędnie używa innych technik i sprawdza istnienie skrzynki pocztowej w odpowiednich systemach, takich jak system nazw domen dla domeny lub przy użyciu weryfikacji wywołania zwrotnego w celu sprawdzenia, czy skrzynka istnieje. Weryfikacja wywołania zwrotnego jest rozwiązaniem niedoskonałym, ponieważ można ją wyłączyć, aby uniknąć ataku z wykorzystaniem katalogu .

Do weryfikacji adresu e-mail użytkownika można wykorzystać kilka technik walidacji. Na przykład,

  • Linki weryfikacyjne: Weryfikacja adresu e-mail jest często przeprowadzana w celu utworzenia konta w witrynach internetowych, wysyłając wiadomość e-mail na podany przez użytkownika adres e-mail ze specjalnym tymczasowym hiperłączem. Po otrzymaniu użytkownik otwiera link, natychmiast aktywując konto. Adresy e-mail są również przydatne jako sposób dostarczania wiadomości ze strony internetowej, np. wiadomości użytkownika, czynności użytkownika, do skrzynki odbiorczej poczty e-mail.
  • Standardy formalne i nieformalne: RFC 3696 zawiera szczegółowe porady dotyczące walidacji identyfikatorów internetowych, w tym adresów e-mail. Niektóre witryny zamiast tego próbują ocenić ważność adresów e-mail za pomocą arbitralnych standardów, na przykład odrzucając adresy zawierające prawidłowe znaki, takie jak + i / lub wymuszając dowolne ograniczenia długości. Internacjonalizacja adresów e-mail zapewnia znacznie większy zakres znaków niż pozwala na to wiele obecnych algorytmów walidacji, na przykład wszystkie znaki Unicode powyżej U+0080, zakodowane jako UTF-8 .
  • Reputacja nadawcy: Reputacja nadawcy wiadomości e-mail może być wykorzystana do próby zweryfikowania, czy nadawca jest godny zaufania, czy też jest potencjalnym spamerem. Czynniki, które mogą być uwzględnione w ocenie reputacji nadawcy, obejmują jakość wcześniejszych kontaktów lub treści dostarczanych przez adres IP lub adres e-mail nadawcy oraz poziom zaangażowania.
  • Weryfikacja oparta na przeglądarce: formularze HTML5 zaimplementowane w wielu przeglądarkach umożliwiają walidację adresu e-mail przez przeglądarkę.

Niektóre firmy oferują usługi weryfikacji adresu e-mail, często przy użyciu interfejsu programowania aplikacji , ale nie ma gwarancji, że zapewni to dokładne wyniki.

Umiędzynarodowienie

IETF prowadzi i norm technicznych grupę roboczą poświęconą kwestii umiędzynarodowienia adresów e-mail, zatytułowany adres email Internacjonalizacja (EAI, znany również jako IMA umiędzynarodowionej mail). Grupa ta wyprodukowała RFC  6530 , 6531 , 6532 i 6533 i kontynuuje prace nad dodatkowymi dokumentami RFC związanymi z EAI.

Grupa Robocza EAI IETF opublikowała RFC 6530 „Przegląd i ramy dla zinternacjonalizowanej poczty e-mail”, która umożliwiła stosowanie znaków innych niż ASCII zarówno w częściach lokalnych, jak iw domenie adresu e-mail. RFC 6530 zapewnia pocztę elektroniczną opartą na kodowaniu UTF-8 , co pozwala na pełny repertuar Unicode . RFC 6531 zapewnia mechanizm dla serwerów SMTP do negocjowania transmisji treści SMTPUTF8 .

Podstawowe koncepcje EAI obejmują wymianę poczty w UTF-8. Chociaż pierwotna propozycja zawierała mechanizm obniżania wersji starszych systemów, teraz została ona porzucona. Lokalne serwery są odpowiedzialne za lokalną część adresu, podczas gdy domena byłaby ograniczona zasadami umiędzynarodowionych nazw domen , choć nadal byłaby przesyłana w UTF-8. Serwer poczty jest również odpowiedzialny za wszelkie mechanizmy mapowania między formularzem IMA a dowolnym aliasem ASCII.

EAI umożliwia użytkownikom posiadanie zlokalizowanego adresu w skrypcie lub zestawie znaków języka ojczystego, a także formie ASCII do komunikacji ze starszymi systemami lub do użytku niezależnego od skryptu. Aplikacje, które rozpoznają umiędzynarodowione nazwy domen i adresy e-mail, muszą mieć funkcje umożliwiające konwersję tych reprezentacji.

Oczekuje się znacznego popytu na takie adresy w Chinach, Japonii, Rosji i na innych rynkach, na których istnieją duże bazy użytkowników korzystających z systemu pisma nie-łacińskiego.

Na przykład, oprócz domeny najwyższego poziomu .in , rząd Indii w 2011 roku uzyskał zgodę na „.bharat” (od Bharat Gaṇarājya ), napisany w siedmiu różnych skryptach do użytku przez Gujrati, Marathi, Bangali, Tamil, Głośniki telugu, pendżabski i urdu. Indyjska firma XgenPlus.com twierdzi, że jest pierwszym na świecie dostawcą skrzynek pocztowych EAI, a rząd Radżastanu udostępnia teraz bezpłatne konto e-mail w domenie राजस्थान.भारत dla każdego obywatela stanu. Wiodący dom mediowy Rajasthan Patrika uruchomił swoją domenę IDN पत्रिका.भारत z kontaktowym adresem e-mail.

Przykłady internacjonalizacji

Poniższe przykładowe adresy nie będą obsługiwane przez serwery oparte na RFC 5322, ale są dozwolone przez RFC 6530. Serwery zgodne z tym będą w stanie obsłużyć te:

Wsparcie internacjonalizacji

  • Postfix Mailer podpory zinternacjonalizowany pocztę od 2015-02-08 o wydaniu stabilnej 3.0.0.
  • Google obsługuje wysyłanie wiadomości e-mail do i z domen umiędzynarodowionych, ale nie zezwala na rejestrację adresów e-mail innych niż ASCII.
  • Microsoft dodał podobną funkcjonalność w Outlooku 2016
  • DataMail wprowadza zinternacjonalizowaną obsługę poczty e-mail w 8 językach indyjskich przy użyciu platformy e-mail XgenPlus w Indiach.

Dokumenty normatywne

  • RFC  821 — prosty protokół przesyłania poczty (przestarzały przez RFC 2821)
  • RFC  822 — standard formatu wiadomości tekstowych internetowych ARPA (przestarzały przez RFC 2822) (Errata)
  • RFC  1035 — nazwy domen, implementacja i specyfikacja (Errata)
  • RFC  1123 — wymagania dotyczące hostów internetowych, aplikacji i wsparcia (zaktualizowane przez RFC 2821, RFC 5321) (Errata)
  • RFC  2142 — Nazwy skrzynek pocztowych dla wspólnych usług, ról i funkcji (Errata)
  • RFC  2821 — prosty protokół przesyłania poczty (przestarzałe RFC 821, aktualizacje RFC 1123, przestarzałe przez RFC 5321) (Errata)
  • RFC  2822 — format wiadomości internetowych (przestarzałe RFC 822, przestarzałe przez RFC 5322) (Errata)
  • RFC  3696 — Techniki aplikacyjne sprawdzania i przekształcania nazw (Errata)
  • RFC  4291 — architektura adresowania IP w wersji 6 (zaktualizowana przez RFC 5952) (Errata)
  • RFC  5321 — prosty protokół przesyłania poczty (przestarzałe RFC 2821, aktualizacje RFC 1123) (Errata)
  • RFC  5322 — format wiadomości internetowych (przestarzałe RFC 2822, zaktualizowane przez RFC 6854) (Errata)
  • RFC  5952 — zalecenie dotyczące reprezentacji tekstu adresu IPv6 (aktualizacje RFC 4291) (Errata)
  • RFC  6530 — omówienie i struktura umiędzynarodowionej poczty e-mail (przestarzałe RFC 4952, 5504, 5825)
  • RFC  6531 — rozszerzenie SMTP dla międzynarodowej poczty e-mail (przestarzałe RFC 5336)
  • RFC  6854 — aktualizacja formatu wiadomości internetowych, aby umożliwić składnię grupy w polach nagłówka „Od:” i „Nadawca:” (aktualizacje RFC 5322)

Zobacz też

Uwagi

Bibliografia

Zewnętrzne linki