Simple Mail Transfer Protocol - Simple Mail Transfer Protocol

„SMTP“ přeadresuje tady. Společnost pro doručování e -mailů viz SMTP (společnost) . Protokol pro přenos krátkých zpráv viz GSM 03.40 .

Sada internetových protokolů
Aplikační vrstva
Transportní vrstva
Internetová vrstva
Odkazová vrstva

Simple Mail Transfer Protocol ( SMTP ) je internetový standardní komunikační protokol pro elektronické pošty přenosu. Poštovní servery a další agenti pro přenos zpráv používají k odesílání a přijímání poštovních zpráv protokol SMTP. E - mailoví klienti na úrovni uživatelů obvykle používají SMTP pouze k odesílání zpráv na poštovní server pro předávání a obvykle odesílají odchozí e-maily na poštovní server na portu 587 nebo 465 podle RFC  8314 . Pro načítání zpráv je standardní protokol IMAP (který nahradil starší POP3 ), ale proprietární servery také často implementují proprietární protokoly, např. Exchange ActiveSync .

Od zavedení SMTP v roce 1981 byl několikrát aktualizován, upravován a rozšiřován. Verze protokolu, která se dnes běžně používá, má rozšiřitelnou strukturu s různými rozšířeními pro autentizaci , šifrování , přenos binárních dat a internacionalizované e -mailové adresy . Servery SMTP běžně používají protokol přenosu přenosu na portu číslo 25 (pro prostý text) a 587 (pro šifrovanou komunikaci).

Dějiny

Předchůdci SMTP

V 60. letech se používaly různé formy individuálních elektronických zpráv . Uživatelé komunikovali pomocí systémů vyvinutých pro konkrétní sálové počítače . Jak bylo propojeno více počítačů, zejména v ARPANETu americké vlády , byly vyvinuty standardy, které umožňují výměnu zpráv mezi různými operačními systémy. SMTP vyrostl z těchto standardů vyvinutých v 70. letech minulého století.

SMTP stopuje jeho kořeny dvou provedeních popsaných v roce 1971: Mail Box protokol, jehož realizace byla sporná, ale je popsán v RFC  196 a dalších RFC, a program SNDMSG, který, podle RFC  2235 , Ray Tomlinson z BBN vynalezen Počítače TENEX k odesílání poštovních zpráv přes ARPANET. K ARPANETu bylo v tuto chvíli připojeno méně než 50 hostitelů.

Mezi další implementace patří FTP Mail a Mail Protocol, oba od roku 1973. Vývojové práce pokračovaly po celá sedmdesátá léta, dokud ARPANET kolem roku 1980 nepřešel na moderní internet.

Originální SMTP

V roce 1980 vydal Jon Postel RFC  772, který navrhoval protokol Mail Transfer Protocol jako náhradu za používání protokolu FTP ( File Transfer Protocol ) pro poštu. RFC  780 z května 1981 odstranil všechny odkazy na FTP a přidělil port 57 pro TCP a UDP , alokaci, která byla mezitím odstraněna IANA . V listopadu 1981 Postel publikoval RFC  788 „Simple Mail Transfer Protocol“.

Standard SMTP byl vyvinut přibližně ve stejnou dobu jako Usenet , komunikační síť typu one-to-many s některými podobnostmi.

SMTP se stal široce používán na začátku 80. let minulého století. V té době to byl doplněk programu Unix to Unix Copy Program (UUCP), který byl vhodnější pro zpracování přenosů e -mailů mezi počítači, které byly přerušovaně připojeny. SMTP na druhou stranu funguje nejlépe, když jsou k síti neustále připojeny jak odesílací, tak přijímací stroje. Oba používali mechanismus úložiště a předávání a jsou příklady technologie push . Ačkoli diskusní skupiny Usenet byly stále šířeny pomocí UUCP mezi servery, UUCP jako přenos pošty prakticky zmizel spolu s „ třeskovými cestami “, které používaly jako záhlaví směrování zpráv.

Sendmail , vydaný s 4.1cBSD v roce 1982, krátce po vydání RFC  788 v listopadu 1981, byl jedním z prvních agentů pro přenos pošty, kteří implementovali SMTP. Postupem času, kdy se BSD Unix stal nejpopulárnějším operačním systémem na internetu, se Sendmail stal nejběžnějším MTA (agent pro přenos pošty).

Původní protokol SMTP podporoval pouze neověřenou nešifrovanou 7bitovou textovou komunikaci ASCII, náchylnou k triviálním útokům typu man-in-the-middle , spoofing a spamming a vyžadující před přenosem všechna binární data zakódovat do čitelného textu. Vzhledem k absenci správného ověřovacího mechanismu byl každý server SMTP záměrně přenosem otevřené pošty . The Internet Mail Consortium (IMC) uvedlo, že 55% poštovních serverů byla otevřená relé v roce 1998, ale méně než 1% v roce 2002. Kvůli obavám ze spamu většina poskytovatelů e -mailů blokovala otevřená relé, takže původní SMTP byl pro obecné použití na internetu v podstatě nepraktický .

Moderní SMTP

V listopadu 1995 definoval RFC  1869 protokol Extended Simple Mail Transfer Protocol (ESMTP), který stanovil obecnou strukturu pro všechna stávající i budoucí rozšíření, která měla za cíl doplnit funkce chybějící z původního SMTP. ESMTP definuje konzistentní a spravovatelné prostředky, pomocí kterých lze identifikovat klienty a servery ESMTP a servery mohou označovat podporovaná rozšíření.

Odesílání zpráv ( RFC  2476 ) a SMTP-AUTH ( RFC  2554 ) byly zavedeny v letech 1998 a 1999, přičemž oba popisovaly nové trendy v doručování e-mailů. Servery SMTP byly původně interní pro organizaci, přijímaly poštu pro organizaci zvenčí a předávaly zprávy z organizace navenek . Ale jak šel čas, servery SMTP (agenti pro přenos pošty) v praxi rozšiřovaly své role, aby se staly agenty pro odesílání zpráv pro uživatelské agenty pošty , z nichž některé nyní předávaly poštu zvenčí organizace. (např. vedoucí společnosti si přeje odesílat e -maily na cesty pomocí podnikového serveru SMTP.) Tento problém, důsledek rychlé expanze a popularity World Wide Web , znamenal, že SMTP musel zahrnovat specifická pravidla a metody pro předávání pošty a ověřování uživatelů, aby se zabránilo zneužívání, jako je předávání nevyžádaných e -mailů ( nevyžádané pošty ). Práce na odesílání zpráv ( RFC  2476 ) byla původně zahájena, protože populární poštovní servery často přepisovaly poštu ve snaze vyřešit v ní problémy, například přidáním názvu domény na nekvalifikovanou adresu. Toto chování je užitečné, když je opravovaná zpráva počátečním odesláním, ale nebezpečné a škodlivé, když zpráva pochází jinam a je předávána. Čisté oddělení pošty na odesílání a předávání bylo považováno za způsob, jak povolit a podpořit přepisování a zároveň zakázat přepisování přenosu. Jak se spam rozšířil, byl také považován za způsob, jak zajistit autorizaci pro rozesílání pošty od organizace a také sledovatelnost. Toto oddělení přenosu a odesílání se rychle stalo základem pro moderní postupy zabezpečení e -mailu.

Protože tento protokol začínal čistě na textové bázi ASCII , nepracoval dobře s binárními soubory nebo znaky v mnoha neanglických jazycích. Pro kódování binárních souborů pro přenos přes SMTP byly vyvinuty standardy, jako je MIME (Multipurpose Internet Mail Extensions ). Agenti přenosu pošty (MTA) vyvinutí po Sendmailu také měli tendenci být implementováni 8bitově čistě , takže k přenosu libovolných textových dat mohla být použita alternativní strategie „jen poslat osm“ (v jakémkoli 8bitovém kódování znaků podobném ASCII) přes SMTP. Mojibake byl stále problém kvůli odlišnému mapování znakové sady mezi dodavateli, i když samotné e -mailové adresy stále umožňovaly pouze ASCII . 8-bit-clean MTA dnes obvykle podporují rozšíření 8BITMIME, což umožňuje přenos některých binárních souborů téměř stejně snadno jako prostý text (limity délky řádku a povolené hodnoty oktetů stále platí, takže kódování MIME je pro většinu netextových kódů potřeba data a některé textové formáty). V roce 2012 bylo SMTPUTF8rozšíření vytvořeno na podporu textu UTF-8 , což umožňuje mezinárodní obsah a adresy v nelatinských skriptech, jako je cyrilice nebo čínština .

Mnoho lidí přispělo k základním specifikacím SMTP, mezi nimi Jon Postel , Eric Allman , Dave Crocker, Ned Freed , Randall Gellens, John Klensin a Keith Moore .

Model zpracování pošty

Modré šipky znázorňují implementaci variací SMTP

E -mail odesílá poštovní klient ( agent uživatelské pošty , MUA) na poštovní server ( agent pro odesílání pošty , MSA) pomocí SMTP na portu TCP 587. Většina poskytovatelů poštovních schránek stále umožňuje odesílání na tradičním portu 25. MSA doručuje poštu agent pro přenos pošty (agent pro přenos pošty , MTA). Tito dva agenti jsou často instance stejného softwaru spuštěného s různými možnostmi na stejném počítači. Místní zpracování lze provést buď na jednom počítači, nebo rozdělit mezi více strojů; procesy poštovního agenta na jednom počítači mohou sdílet soubory, ale pokud zpracování probíhá na více počítačích, přenášejí mezi sebou zprávy pomocí SMTP, kde je každý počítač nakonfigurován tak, aby jako inteligentní hostitel používal další počítač . Každý proces je MTA (server SMTP) sám o sobě.

Hraniční MTA používá DNS k vyhledání záznamu MX (mail exchanger) pro doménu příjemce (část e -mailové adresy vpravo od @). MX záznam obsahuje název cílového MTA. Na základě cílového hostitele a dalších faktorů vybere odesílající MTA server příjemce a připojí se k němu, aby dokončil výměnu pošty.

K přenosu zpráv může dojít v jediném spojení mezi dvěma MTA nebo v sérii skoků prostřednictvím zprostředkovatelských systémů. Přijímající server SMTP může být konečným cílem, mezilehlým „relé“ (to znamená, že ukládá a přeposílá zprávu) nebo „bránou“ (to znamená, že může přeposílat zprávu pomocí jiného protokolu než SMTP). Podle RFC  5321, část 2.1, je každý skok formálním předáním odpovědnosti za zprávu, přičemž přijímající server musí buď doručit zprávu, nebo řádně nahlásit selhání.

Jakmile konečný skok přijme příchozí zprávu, předá ji agentovi pro doručování pošty (MDA) pro místní doručení. MDA ukládá zprávy v příslušném formátu poštovní schránky . Stejně jako u odesílání lze tento příjem provést pomocí jednoho nebo více počítačů, ale ve schématu výše je MDA znázorněno jako jedno pole poblíž schránky výměníku pošty. MDA může doručovat zprávy přímo do úložiště nebo je přeposílat po síti pomocí protokolu SMTP nebo jiného protokolu, jako je například protokol LMTP ( Local Mail Transfer Protocol ), což je derivát protokolu SMTP navržený pro tento účel.

Po doručení na místní poštovní server je pošta uložena pro dávkové načtení ověřenými poštovními klienty (MUA). Poštu načítají aplikace koncových uživatelů, nazývané e-mailoví klienti, pomocí protokolu Internet Message Access Protocol (IMAP), což je protokol, který usnadňuje přístup k poště a spravuje uloženou poštu, nebo protokol Post Office Protocol (POP), který obvykle používá tradiční poštu mbox formát souboru nebo proprietární systém, jako je Microsoft Exchange / Outlook nebo Lotus Notes / Domino . Weboví klienti mohou používat obě metody, ale protokol pro získávání často není formálním standardem.

SMTP definuje přenos zpráv , nikoli obsah zprávy . Definuje tedy obálku pošty a její parametry, například odesílatele obálky , nikoli však záhlaví (kromě informací o stopách ) ani samotné tělo zprávy. STD 10 a RFC  5321 definují SMTP (obálka), zatímco STD 11 a RFC  5322 definují zprávu (záhlaví a tělo), formálně označovanou jako formát internetové zprávy .

Přehled protokolu

SMTP je orientovaný na připojení , textový protokol , ve kterém mailová adresa odesílatele komunikuje s poštovním přijímače podle vydávání příkazových řetězců a dodává potřebná data přes spolehlivou objednané datového toku kanálu, typicky Transmission Control Protocol (TCP) připojení. Relace SMTP se skládá z příkazů vznikla SMTP klient (iniciační prostředek , odesílatele nebo vysílače) a odpovídající reakcí ze SMTP serveru (poslechové činidla nebo přijímač), takže relace je otevřen, a parametry relace jsou vyměňovány. Relace může obsahovat nula nebo více transakcí SMTP. Transakce SMTP se skládá ze tří příkazu / odpovědi sekvencí:

  1. Příkaz MAIL k určení zpáteční adresy, nazývané také zpáteční cesta, zpětná cesta , odrazová adresa , mfrom nebo odesílatel obálky.
  2. RCPT příkaz, kterým se stanoví příjemce zprávy. Tento příkaz lze zadat vícekrát, pro každého příjemce jeden. Tyto adresy jsou také součástí obálky.
  3. DATA k signalizaci začátku textu zprávy ; obsah zprávy, na rozdíl od její obálky. Skládá se z hlavičky zprávy a těla zprávy oddělené prázdným řádkem. DATA je ve skutečnosti skupina příkazů a server odpoví dvakrát: jednou na samotný příkaz DATA , aby potvrdil, že je připraven přijmout text, a podruhé po sekvenci konce dat buď přijmout, nebo odmítnout celou zprávu.

Kromě přechodné odpovědi pro DATA může být odpověď každého serveru kladná (kódy 2xx odpovědí) nebo záporná. Negativní odpovědi mohou být trvalé (kódy 5xx) nebo přechodné (kódy 4xx). Odmítnutí je trvalé selhání a klient by měl poslat odmítnutí zprávy serveru to jej obdržel od. Pokles je pozitivní odezva následovaná zprávou odpadků spíše než dodávky.

Počáteční hostitel, klient SMTP, může být buď e- mailový klient koncového uživatele , funkčně identifikovaný jako agent poštovního uživatele (MUA), nebo agent přenosu pošty (MTA) na přenosovém serveru , což je server SMTP fungující jako klient SMTP v příslušné relaci za účelem předávání pošty. Plně schopné servery SMTP udržují fronty zpráv pro opakování přenosů zpráv, které vedly k přechodným selháním.

Server MTP zná server SMTP odchozí pošty ze své konfigurace. Reléový server obvykle určuje, ke kterému serveru se připojit, vyhledáním záznamu zdroje DNS MX (Mail eXchange) pro název domény každého příjemce . Pokud není nalezen žádný záznam MX, místo toho vyhledá záznam A vyhovující předávající server (ne všichni) . Reléové servery lze také nakonfigurovat tak, aby používaly inteligentního hostitele . Reléový server zahájí připojení TCP k serveru na „ dobře známém portu “ pro SMTP: port 25 nebo pro připojení k MSA, port 587. Hlavní rozdíl mezi MTA a MSA spočívá v tom, že připojení k MSA vyžaduje Ověření SMTP .

SMTP vs načítání pošty

SMTP je pouze doručovací protokol. Při běžném používání je pošta „doručována“ na cílový poštovní server (nebo poštovní server dalšího přeskakování), jak přichází. Pošta je směrována podle cílového serveru, nikoli podle jednotlivých uživatelů, kterým je adresována. Jiné protokoly, jako například Post Office Protocol (POP) a Internet Message Access Protocol (IMAP), jsou speciálně navrženy pro použití jednotlivými uživateli při načítání zpráv a správě poštovních schránek . Chcete-li povolit přerušovaně připojenému poštovnímu serveru tahat zprávy ze vzdáleného serveru na vyžádání, má SMTP funkci pro zahájení zpracování poštovní fronty na vzdáleném serveru (viz Spuštění vzdálené fronty zpráv níže). POP a IMAP jsou nevhodné protokoly pro předávání pošty přerušovaně připojenými počítači; jsou navrženy tak, aby fungovaly po konečném doručení, když byly odstraněny informace důležité pro správnou funkci přenosu pošty („poštovní obálka“).

Spouštění vzdálené fronty zpráv

Vzdálené spouštění front zpráv umožňuje vzdálenému hostiteli zahájit zpracování poštovní fronty na serveru, aby mohl přijímat zprávy, které jsou mu určeny, odesláním odpovídajícího příkazu. Původní TURNpříkaz byl považován za nezabezpečený a byl v RFC  1985 rozšířen o ETRNpříkaz, který funguje bezpečněji pomocí metody autentizace založené na informacích systému Domain Name System .

Server SMTP pro odchozí poštu

E -mailový klient potřebuje znát IP adresu původního serveru SMTP, což je třeba zadat v rámci konfigurace (obvykle jako název DNS ). Tento server bude doručovat odchozí zprávy jménem uživatele.

Omezení přístupu k serveru odchozí pošty

Administrátoři serveru musí zavést určitou kontrolu, na které mohou klienti používat server. To jim umožňuje vypořádat se se zneužíváním, například spamem . Běžně se používají dvě řešení:

  • V minulosti mnoho systémů ukládalo omezení používání podle umístění klienta, což umožňovalo použití pouze klientům, jejichž IP adresa je ta, kterou správci serveru ovládají. Použití z jakékoli jiné IP adresy klienta není povoleno.
  • Moderní servery SMTP obvykle nabízejí alternativní systém, který před povolením přístupu vyžaduje autentizaci klientů pomocí přihlašovacích údajů.

Omezení přístupu podle polohy

V tomto systému neumožňuje SMTP server ISP přístup uživatelům, kteří se nacházejí mimo síť ISP. Přesněji řečeno, server může povolit přístup pouze uživatelům s IP adresou poskytnutou ISP, což odpovídá požadavku, aby byli připojeni k internetu pomocí stejného ISP. Mobilní uživatel může být často v jiné síti, než je jeho běžný ISP, a poté zjistí, že odesílání e -mailů selže, protože konfigurovaný výběr serveru SMTP již není přístupný.

Tento systém má několik variací. Server SMTP organizace může například poskytovat služby pouze uživatelům ve stejné síti, což je vynuceno bránou firewall, která blokuje přístup uživatelům na širším internetu. Nebo server může provádět kontroly rozsahu na IP adrese klienta. Tyto metody obvykle používaly korporace a instituce, jako jsou univerzity, které poskytovaly server SMTP pro odchozí poštu pouze pro interní použití v rámci organizace. Většina těchto těl však nyní používá metody ověřování klienta, jak je popsáno níže.

Pokud je uživatel mobilní a k připojení k internetu může používat různé ISP, je tento druh omezení použití obtížný a změna nakonfigurované adresy serveru SMTP pro odchozí e -maily je nepraktická. Je velmi žádoucí používat informace o konfiguraci e -mailového klienta, které není třeba měnit.

Ověření klienta

Moderní servery SMTP obvykle před povolením přístupu vyžadují autentizaci klientů pomocí přihlašovacích údajů, nikoli omezení přístupu podle umístění, jak bylo popsáno výše. Tento flexibilnější systém je přátelský k mobilním uživatelům a umožňuje jim mít pevný výběr konfigurovaného odchozího serveru SMTP. Ověřování SMTP , často zkráceně SMTP AUTH, je rozšířením SMTP za účelem přihlášení pomocí ověřovacího mechanismu.

Porty

Komunikace mezi poštovními servery obecně využívá standardní port TCP 25 určený pro SMTP.

Poštovní klienti to však obecně nepoužívají, místo toho používají konkrétní porty „odeslání“. Poštovní služby obecně přijímají odesílání e -mailů od klientů na jednom z:

Někteří jednotliví poskytovatelé mohou používat port 2525 a další, ale nikdy nebyly oficiálně podporovány.

Mnoho poskytovatelů internetových služeb nyní svým zákazníkům blokuje veškerý odchozí port 25. Hlavně jako opatření proti nevyžádané poště, ale také jako vyléčení vyšších nákladů, které mají, když jej necháte otevřený, možná účtováním více od několika zákazníků, kteří jej vyžadují.

Příklad přenosu SMTP

Typický příklad odeslání zprávy přes SMTP do dvou poštovních schránek ( alice a theboss ) umístěných ve stejné poštovní doméně ( example.com ) je reprodukován v následující výměně relací. (V tomto případě mají části konverzace předponu S: a C: pro server a klienta ; tyto popisky nejsou součástí burzy.)

Poté, co odesílatel zprávy (klient SMTP) naváže spolehlivý komunikační kanál pro příjemce zprávy (server SMTP), se relace zahájí pozdravem serveru, který obvykle obsahuje jeho plně kvalifikovaný název domény (FQDN), v tomto případě příklad smtp. .com . Klient zahájí dialog tak, že odpoví HELOpříkazem, který se v parametru příkazu identifikuje svým FQDN (nebo doslovným adresou, pokud není k dispozici). 

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: RCPT TO:<theboss@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.org>
C: To: "Alice Example" <alice@example.com>
C: Cc: theboss@example.com
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}

Klient upozorní příjemce MAIL FROMpříkazem na původní e -mailovou adresu zprávy . Toto je také adresa pro vrácení nebo odskočení v případě, že zprávu nelze doručit. V tomto případě je e -mailová zpráva odeslána do dvou poštovních schránek na stejném serveru SMTP: jedna pro každého příjemce uvedeného v polích To:a Cc:záhlaví. Odpovídající příkaz SMTP je RCPT TO. Každý úspěšný příjem a provedení příkazu je serverem potvrzeno kódem výsledku a odpovědí (např. 250 Ok).

Přenos těla poštovní zprávy je zahájen DATApříkazem, načež je přenášen doslovně po řádcích a je ukončen sekvencí konce dat. Tato sekvence se skládá z nového řádku ( <CR><LF>), jediné tečky ( .), za kterou následuje další nový řádek ( <CR><LF>). Protože tělo zprávy může obsahovat řádek s pouze tečkou jako součást textu, klient odešle dvě tečky pokaždé, když řádek začíná tečkou; odpovídajícím způsobem server nahradí každou sekvenci dvou teček na začátku řádku jedinou. Takové unikající metodě se říká tečkování .

Pozitivní odpověď serveru na konec dat, jak je ukázáno na příkladu, znamená, že server převzal odpovědnost za doručení zprávy. Zprávu lze zdvojnásobit, pokud v tuto chvíli dojde k selhání komunikace, např. Z důvodu nedostatku napájení: Dokud odesílatel tuto 250 Okodpověď neobdrží , musí předpokládat, že zpráva nebyla doručena. Na druhou stranu, poté, co se příjemce rozhodl zprávu přijmout, musí předpokládat, že jí byla zpráva doručena. Během této doby mají tedy oba agenti aktivní kopie zprávy, kterou se pokusí doručit. Pravděpodobnost, že dojde k selhání komunikace přesně v tomto kroku, je přímo úměrná množství filtrování, které server provádí na těle zprávy, nejčastěji pro účely antispamu. Časový limit je stanoven na 10 minut.

QUITPříkaz ukončí relaci. Pokud má e -mail jiné příjemce umístěné jinde, klient by se QUITpřipojil k příslušnému serveru SMTP pro následné příjemce po zařazení aktuálního cíle do fronty. Informace, které klient odešle do příkazů HELOa, MAIL FROMjsou přidány (nejsou vidět v ukázkovém kódu) jako další pole záhlaví do zprávy přijímajícím serverem. Přidá pole Receiveda Return-Pathzáhlaví.

Někteří klienti jsou implementováni k ukončení připojení po přijetí zprávy ( 250 Ok: queued as 12345), takže poslední dva řádky mohou být ve skutečnosti vynechány. Při pokusu o odeslání 221 Byeodpovědi to způsobí chybu na serveru .

Rozšíření SMTP

Mechanismus zjišťování rozšíření

Klienti se naučí možnosti serveru podporované pomocí EHLOpozdravu, jak je uvedeno níže, namísto originálu HELO. Ke klientům se dostanete zpět HELOpouze v případě, že server nepodporuje EHLOpozdrav.

Moderní klienti mohou pomocí klíčového slova ESMTP SIZEdotazovat server na maximální velikost zprávy, která bude přijata. Starší klienti a servery se mohou pokusit přenést nadměrně velké zprávy, které budou odmítnuty po spotřebování síťových prostředků, včetně doby připojení k síťovým odkazům, která se platí za minutu.

Uživatelé mohou předem ručně určit maximální velikost akceptovanou servery ESMTP. Klient nahradí HELOpříkaz EHLOpříkazem. 

S: 220 smtp2.example.com ESMTP Postfix
C: EHLO bob.example.org
S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201]
S: 250-SIZE 14680064
S: 250-PIPELINING
S: 250 HELP

Smtp2.example.com tedy prohlašuje, že může přijmout pevnou maximální velikost zprávy ne větší než 14 680 064 oktetů (8bitové bajty).

V nejjednodušším případě server ESMTP deklaruje maximum SIZEihned po obdržení souboru EHLO. Podle RFC  1870 je však numerický parametr SIZErozšíření v EHLOodpovědi nepovinný. Klienti mohou místo toho při zadávání MAIL FROMpříkazu uvádět číselný odhad velikosti zprávy, kterou přenášejí, aby server mohl odmítnout příjem příliš velkých zpráv.

Binární přenos dat

Původní SMTP podporuje pouze jedno tělo textu ASCII, takže jakákoli binární data musí být před přenosem kódována jako text do těla zprávy a poté dekódována příjemcem. Obvykle se používalo kódování binárních textů , například uuencode a BinHex .

K vyřešení tohoto problému byl vyvinut příkaz 8BITMIME. Byl standardizován v roce 1994 jako RFC  1652. Umožňuje transparentní výměnu e-mailových zpráv obsahujících oktety mimo sedmbitovou znakovou sadu ASCII jejich zakódováním jako částí obsahu MIME , typicky kódovaných pomocí Base64 .

Rozšíření mechanismu doručování pošty

Relé pošty na vyžádání

Hlavní článek: Poštovní relé na vyžádání

On-Demand Mail Relay ( ODMR ) je rozšíření SMTP standardizované v RFC  2645, které umožňuje přerušovaně připojenému serveru SMTP přijímat e-maily ve frontě, když je připojeno.

Internacionalizační rozšíření

Hlavní článek: Mezinárodní e -mail

Původní SMTP podporuje e -mailové adresy složené pouze ze znaků ASCII , což je nepohodlné pro uživatele, jejichž nativní skript není založen na latince, nebo kteří používají diakritiku, která není ve znakové sadě ASCII. Toto omezení bylo zmírněno prostřednictvím rozšíření umožňujících UTF-8 v názvech adres. RFC  5336 zavedl experimentální UTF8SMTPpříkaz a později byl nahrazen RFC  6531, který zavedl SMTPUTF8příkaz. Tato rozšíření poskytují podporu pro vícebajtové znaky a znaky jiné než ASCII v e-mailových adresách, jako jsou ty s diakritikou a jiné jazykové znaky, jako je řečtina a čínština .

Aktuální podpora je omezená, ale existuje velký zájem o široké přijetí RFC  6531 a souvisejících RFC v zemích jako Čína, které mají velkou uživatelskou základnu, kde latinka (ASCII) je cizí skript.

Rozšíření

Stejně jako SMTP je ESMTP protokol používaný k přenosu internetové pošty. Používá se jako protokol pro přenos mezi servery a (s vynuceným omezeným chováním) protokol pro odesílání pošty.

Hlavní identifikační funkcí pro klienty ESMTP je otevřít přenos pomocí příkazu EHLO(Extended HELLO), nikoli HELO(Hello, původní standard RFC  821 ). Server odpoví úspěchem (kód 250), selháním (kód 550) nebo chybou (kód 500, 501, 502, 504 nebo 421) v závislosti na konfiguraci. Server ESMTP vrátí kód 250 OK ve víceřádkové odpovědi se svou doménou a seznamem klíčových slov pro označení podporovaných rozšíření. Server kompatibilní s RFC 821 vrací kód chyby 500, což klientům ESMTP umožňuje vyzkoušet buď HELOnebo QUIT.

Každé rozšíření služby je definováno ve schváleném formátu v následujících RFC a registrováno u úřadu Internet Assigned Numbers Authority (IANA). První definice byly RFC 821 volitelné služby: SEND, SOML(Odeslat nebo Mail), SAML(Odeslat and Mail) EXPN, HELPa TURN. Byl nastaven formát dalších sloves SMTP a pro nové parametry v MAILa RCPT.

Některá relativně běžná klíčová slova (ne všechna z nich odpovídají příkazům), která se dnes používají, jsou:

Formát ESMTP byl přepracován v RFC  2821 (nahrazující RFC 821) a aktualizován na nejnovější definici v RFC  5321 v roce 2008. Podpora EHLOpříkazu na serverech se stala povinnou a byla HELOoznačena jako požadovaná záložní.

Nestandardní, neregistrovaná, rozšíření služeb lze použít na základě dvoustranné dohody, tyto služby jsou označeny EHLOklíčovým slovem zprávy začínajícím na „X“ a podobně označeny další parametry nebo slovesa.

Příkazy SMTP nerozlišují velká a malá písmena. Jsou zde uvedeny pouze velkými písmeny pro zdůraznění. Server SMTP, který vyžaduje konkrétní metodu kapitalizace, je porušením standardu.

8 BITMIME

Rozšíření 8BITMIME inzerují alespoň následující servery:

Následující servery lze nakonfigurovat tak, aby inzerovaly 8BITMIME, ale neprováděly převod 8bitových dat na 7bitové při připojení k relé jiným než 8BITMIME:

  • Exim a qmail nepřevádějí osmibitové zprávy na sedmbitové, když se pokoušejí předat 8bitová data jiným kolegům než 8BITMIME, jak to vyžaduje RFC. V praxi to nezpůsobuje problémy, protože prakticky všechna moderní poštovní relé jsou 8bitová čistá .
  • Microsoft Exchange Server 2003 ve výchozím nastavení inzeruje 8BITMIME, ale přepojení na peer jiný než 8BITMIME vede k okamžitému odrazu. To umožňuje RFC 6152 část 3 .

SMTP-AUTH

Hlavní článek: Ověřování SMTP

Rozšíření SMTP-AUTH poskytuje mechanismus řízení přístupu. Skládá se z kroku autentizace, prostřednictvím kterého se klient efektivně přihlásí na poštovní server během procesu odesílání pošty. Servery, které podporují SMTP-AUTH, lze obvykle nakonfigurovat tak, aby vyžadovaly, aby klienti používali toto rozšíření, čímž je zajištěna známá skutečná identita odesílatele. Rozšíření SMTP-AUTH je definováno v RFC  4954 .

SMTP-AUTH lze použít k tomu, aby legitimní uživatelé mohli předávat poštu a zároveň odmítat službu přenosu neoprávněným uživatelům, například spammerům . Nezaručuje nutně autentičnost odesílatele obálky SMTP ani záhlaví RFC  2822 "Od:". Například podvržení , při kterém se jeden odesílatel vydává za někoho jiného, ​​je u SMTP-AUTH stále možné, pokud není server nakonfigurován tak, aby omezoval adresy odesílatelů na adresy, pro které je tento AUTHED uživatel autorizován.

Rozšíření SMTP-AUTH také umožňuje jednomu poštovnímu serveru indikovat druhému, že odesílatel byl při přenosu pošty ověřen. Obecně to vyžaduje, aby server příjemce důvěřoval odesílajícímu serveru, což znamená, že tento aspekt SMTP-AUTH se na internetu používá jen zřídka.

SMTPUTF8

Mezi podpůrné servery patří:

Rozšíření zabezpečení

Doručování pošty může probíhat jak přes prostý text, tak i šifrovaná připojení, ale komunikující strany nemusí předem vědět o schopnosti druhé strany používat zabezpečený kanál.

STARTTLS nebo „Oportunistický TLS“

Hlavní články: Oportunistické TLS a šifrování e -mailů

Rozšíření STARTTLS umožňuje podporujícím serverům SMTP upozorňovat připojující se klienty na to, že podporuje šifrovanou komunikaci TLS, a nabízí klientům příležitost upgradovat připojení odesláním příkazu STARTTLS. Servery podporující rozšíření samy o sobě nezískávají žádné bezpečnostní výhody z jeho implementace, protože upgrade na šifrovanou relaci TLS závisí na tom, jak se připojující klient rozhodne tuto možnost uplatnit, a proto se označuje termín oportunistický TLS .

STARTTLS je účinný pouze proti útokům pasivního pozorování, protože vyjednávání STARTTLS probíhá v prostém textu a aktivní útočník může triviálně odstraňovat příkazy STARTTLS. Tento typ útoku typu man-in-the-middle je někdy označován jako STRIPTLS , kde informace o vyjednávání šifrování zaslané z jednoho konce nikdy nedorazí na druhý. V tomto scénáři obě strany berou neplatné nebo neočekávané odpovědi jako označení toho, že druhá strana správně nepodporuje STARTTLS, ve výchozím nastavení tradiční přenos e-mailů ve formátu prostého textu. Všimněte si toho, že STARTTLS je také definován pro IMAP a POP3 v jiných RFC, ale tyto protokoly slouží různým účelům: SMTP se používá pro komunikaci mezi agenty přenosu zpráv, zatímco IMAP a POP3 jsou pro koncové klienty a agenty přenosu zpráv.

Electronic Frontier Foundation udržuje seznam „STARTTLS Everywhere“, který podobně jako seznam „ HTTPS Everywhere “ umožňuje spoléhajícím se stranám objevit další podporující zabezpečenou komunikaci bez předchozí komunikace.

RFC  8314 oficiálně prohlásil prostý text za zastaralý a doporučuje vždy používat protokol TLS a přidávat porty s implicitním protokolem TLS.

Přísné zabezpečení přenosu SMTP MTA

Novější 2018 RFC  8461 s názvem „SMTP MTA Strict Transport Security (MTA-STS)“ má za cíl vyřešit problém aktivního protivníka definováním protokolu pro poštovní servery, který deklaruje jejich schopnost používat zabezpečené kanály v konkrétních souborech na serveru a konkrétním DNS Záznamy TXT. Spoléhající se strana by pravidelně kontrolovala existenci takového záznamu a ukládala jej do mezipaměti po dobu uvedenou v záznamu a nikdy nekomunikovala přes nezabezpečené kanály, dokud záznam nevyprší. Záznamy MTA-STS se vztahují pouze na provoz SMTP mezi poštovními servery, zatímco komunikace mezi klientem uživatele a poštovním serverem je chráněna pomocí Transport Layer Security s SMTP/MSA, IMAP, POP3 nebo HTTPS v kombinaci s organizační nebo technickou zásadou. MTA-STS je v zásadě prostředkem k rozšíření takové politiky na třetí strany.

V dubnu 2019 Google Mail oznámil podporu pro MTA-STS.

Hlášení SMTP TLS

Řada protokolů umožňuje zabezpečené doručování zpráv, ale mohou selhat v důsledku nesprávné konfigurace nebo záměrného aktivního rušení, což vede k nedoručeným zprávám nebo k doručení přes nešifrované nebo neověřené kanály. RFC  8460 „SMTP TLS Reporting“ popisuje mechanismus hlášení a formát pro sdílení statistik a konkrétních informací o potenciálních selháních s doménami příjemců. Domény příjemců pak mohou tyto informace použít k detekci potenciálních útoků a diagnostice neúmyslných nesprávných konfigurací.

V dubnu 2019 Google Mail oznámil podporu pro SMTP TLS Reporting.

Spoofing a spamování

Hlavní články: Anti-spamové techniky a ověřování e -mailů

Původní design SMTP neměl možnost ověřovat odesílatele nebo kontrolovat, zda jsou servery oprávněny odesílat jejich jménem, ​​což má za následek, že je možné falšování e -mailů a běžně se používá ve spamu a phishingu e -mailů .

Občas se dělají návrhy na rozsáhlou úpravu SMTP nebo jeho úplné nahrazení. Jedním z příkladů je Internet Mail 2000 , ale ani on, ani žádný jiný neudělal velký pokrok tváří v tvář síťovému efektu obrovské instalované základny klasického SMTP.

Místo toho nyní poštovní servery používají řadu technik, jako je přísnější vynucování standardů, jako je RFC  5322 , DomainKeys Identified Mail , Sender Policy Framework a DMARC , DNSBL a greylisting k odmítání nebo karanténě podezřelých e -mailů .

Implementace

Existuje také implementace serveru SMTP proxy, například nginx .

Hlavní články: Seznam softwaru poštovního serveru a Porovnání poštovních serverů

Související žádosti o komentáře

  • RFC  1123 - Požadavky na internetové hostitele - aplikace a podpora (STD 3)
  • RFC  1870 - SMTP Service Extension for Message Size Declaration (оbsoletes: RFC  1653 )
  • RFC  2505 -Anti-Spam doporučení pro SMTP MTA (BCP 30)
  • RFC  2821 - Simple Mail Transfer Protocol
  • RFC  2920 - SMTP Service Extension for Command Pipelining (STD 60)
  • RFC  3030 - Rozšíření služby SMTP pro přenos velkých a binárních zpráv MIME
  • RFC  3207 - Rozšíření služby SMTP pro zabezpečené zabezpečení SMTP přes transportní vrstvu (zastarává RFC  2487 )
  • RFC  3461 - Rozšíření služby SMTP pro oznámení o stavu doručení (zastaralé RFC  1891 )
  • RFC  3463 - vylepšené stavové kódy pro SMTP (zastaralé RFC  1893 , aktualizováno RFC  5248 )
  • RFC  3464 - rozšiřitelný formát zpráv pro oznámení o stavu doručení (zastaralé RFC  1894 )
  • RFC  3798 - Oznámení o likvidaci zpráv (aktualizace RFC  3461 )
  • RFC  3834 - doporučení pro automatické reakce na elektronickou poštu
  • RFC  3974 - Provozní zkušenosti SMTP v smíšených prostředích IPv4/v6
  • RFC  4952 - Přehled a rámec pro internacionalizovaný e -mail (aktualizováno RFC  5336 )
  • RFC  4954 - SMTP Service Extension for Authentication (zastarává RFC  2554 , aktualizace RFC  3463 , aktualizováno RFC  5248 )
  • RFC  5068 - Operace odesílání e -mailů: Požadavky na přístup a odpovědnost (BCP 134)
  • RFC  5248 - registr stavových kódů vylepšeného systému SMTP (BCP 138) (aktualizace RFC  3463 )
  • RFC  5321 - The Simple Mail Transfer Protocol (zastarává RFC  821 aka STD 10, RFC  974 , RFC  1869 , RFC  2821 , aktualizace RFC  1123 )
  • RFC  5322 - Internet Message Format (zastaralé RFC  822 aka STD 11 a RFC  2822 )
  • RFC  5504 - Mechanismus downgradu pro internacionalizaci e -mailových adres
  • RFC  6409 - Odesílání zpráv pro poštu (STD 72) (zastaralé RFC  4409 , RFC  2476 )
  • RFC  6522 - vícedílný/typ obsahu sestavy pro hlášení zpráv o správě systému pošty (zastarává RFC  3462 a následně RFC  1892 )
  • RFC  6531 - Rozšíření SMTP pro internacionalizované e -mailové adresy (aktualizace RFC  2821 , RFC  2822 , RFC  4952 a RFC  5336 )
  • RFC  8314 - Cleartext považován za zastaralý: Použití zabezpečení Transport Layer Security (TLS) pro odesílání e -mailů a přístup

Viz také

Poznámky

Reference

externí odkazy