| SMTP | |
|---|---|
| název | Jednoduchý protokol pro přenos pošty |
| Úroveň (podle modelu OSI ) | Aplikovaný |
| Rodina | TCP/IP |
| Port/ID |
25/TCP, 587/TCP 465/TCP (SMTP přes SSL) |
| Účel protokolu | Odesílání emailu |
| Specifikace | RFC 5321 |
| Hlavní implementace (klienti) | MUA ( The Bat!, MS Outlook , MS Outlook Express , Mozilla Thunderbird , Claws Mail atd.) |
| Implementace jádra ( servery ) | MTA ( sendmail , postfix , OpenSMTPD , qmail , exim , Microsoft Exchange Server , MDaemon ) |
| Rozšiřitelnost | Přidat. příkazy ( RFC 2449 ) |
| Mediální soubory na Wikimedia Commons | |
SMTP ( anglicky Simple Mail Transfer Protocol - jednoduchý protokol pro přenos pošty) je široce používaný síťový protokol určený k přenosu elektronické pošty přes sítě TCP /IP.
SMTP byl poprvé popsán v RFC 821 (1982); nejnovější aktualizace v RFC 5321 (2008) obsahuje škálovatelné rozšíření - ESMTP ( Extended SMTP ) . V současné době se pod pojmem „protokol SMTP“ obvykle rozumí jeho rozšíření. Protokol SMTP je navržen pro přenos odchozí pošty pomocí portu TCP 25.
Zatímco servery elektronické pošty a další agenti přenosu zpráv používají SMTP k odesílání a přijímání poštovních zpráv, aplikace poštovních klientů na uživatelské úrovni obecně používají SMTP pouze k odesílání zpráv na poštovní server pro přenos. K přijímání zpráv klientské aplikace obvykle používají buď POP ( Post Office Protocol ) nebo IMAP ( Internet Message Access Protocol ) nebo proprietární systémy (jako je Microsoft Exchange a Lotus Notes / Domino ) pro přístup k účtu .
V 60. letech se používaly různé formy elektronické komunikace. Lidé spolu komunikovali pomocí systémů určených pro specifické sálové počítače . Jak se připojovalo stále více počítačů, zejména na vládní síti USA, ARPANET , byly vyvinuty standardy, aby si uživatelé na různých systémech mohli psát elektronické zprávy . Tyto standardy, vyvinuté v 70. letech, se staly základem pro SMTP.
Kořeny SMTP lze vysledovat zpět ke dvěma implementacím popsaným v roce 1971, Mail Box Protocol a SNDMSG, které „vynalezl“ Ray Tomlinson z BBN Technologies pro počítače TOPS-20/TENEX, které posílaly zprávy přes ARPANET (v té době méně než 50 hostitelů).
Mezi další implementace patří FTP Mail and Mail Protocol, vyvinutý v roce 1973. Vývoj pokračoval po celá sedmdesátá léta, dokud se ARPANET nevyvinul v moderní Internet kolem roku 1980. Ve stejném roce Jon Postel navrhl Mail Transport Protocol., díky kterému FTP přestal být základ pro přenos pošty. SMTP publikovaný v RFC 821 (také napsaný Postel) v srpnu 1982.
Standard SMTP byl vyvinut přibližně ve stejnou dobu jako Usenet , datová síť s určitými podobnostmi s SMTP. SMTP se začal široce používat na počátku 80. let. V té době to byl doplněk pro poštovní program Unix to Unix CoPy (UUCP) založený na Unixu, který byl vhodnější pro zpracování přenosu elektronických zpráv mezi přerušovaně připojenými zařízeními. Na druhou stranu SMTP funguje skvěle, když jsou odesílající i přijímající zařízení neustále připojena k síti. Obě zařízení používají mechanismus ukládání a předávání a jsou příkladem technologie push . Zatímco diskusní skupiny Usenet jsou stále šířeny mezi servery pomocí protokolu UUCP, pošta UUCP účinně zmizela spolu s „cestou třesku“ (sekvence hostitelských strojů v síti, kterou musí zpráva přijmout, aby dosáhla svého cíle), které byly použity jako směrovací hlavičky. Článek Sender Rewrite poskytuje technické informace o historii raného SMTP a směrování zdroje před RFC 1123 .
Sendmail byl jedním z prvních (ne-li prvním) agentem přenosu zpráv, který implementoval SMTP. Mezi další oblíbené serverové programy, které podporují SMTP, patří Postfix , qmail , Novell GroupWise , Exim , Novell NetMail, Microsoft Exchange Server , Sun Java System Messaging Server.
Odesílání zpráv ( RFC 2476 ) a SMTP-AUTH ( RFC 2554 ) byly zavedeny v letech 1998 a 1999. a popsal nové trendy v přenosu elektronických zpráv. Zpočátku byly servery SMTP obvykle interní v organizaci, přijímaly zprávy od vnějších organizací a předávaly zprávy organizace vnějšímu světu. Postupem času však servery SMTP (agenti přenosu zpráv) ve skutečnosti rozšířily své funkce a nakonec se staly agenty doručování zpráv pro uživatelské poštovní aplikace , z nichž některé nyní předávají poštu mimo organizaci (například jednatel společnosti na výletě chce odesílat e-maily pomocí podnikového serveru SMTP).
Tento problém, jako důsledek rychlého rozvoje a popularity World Wide Web , znamenal, že SMTP musel zahrnovat specifická pravidla a metody pro předávání zpráv a autorizaci uživatelů, aby zabránili zneužití, jako je předávání nevyžádané pošty ( spam ).
Protože tento protokol byl původně textovým ( ASCII ) rozhraním, nefungoval dobře s binárními soubory a znaky z mnoha neanglických jazyků. Standardy jako Multipurpose Internet Mail Extensions ( MIME ) byly vyvinuty pro kódování binárních souborů pro přenos přes SMTP. Agenti pro předávání Post-Sendmail obvykle také implementovali čistě 8bitovou možnost, takže k odesílání libovolných textových dat (v jakémkoli osmibitovém kódování znaků podobném ASCII) přes SMTP lze použít alternativní strategii „jen odeslat osm“. Stále však přetrvával problém s krakozyabr , způsobený odlišným zobrazováním znakových sad ze strany výrobců, ačkoliv samotné poštovní adresy stále umožňovaly používat výhradně ASCII. Dnes čistě 8bitové přenosové agenty obvykle podporují rozšíření 8BITMIME, díky kterému je přenos binárních souborů téměř stejně snadný jako prostý text. Rozšíření SMTPUTF8 bylo nedávno vytvořeno pro podporu textu kódovaného UTF-8 , což umožňuje zahrnout mezinárodní obsah a adresy pomocí skriptů, jako je azbuka nebo čínština.
K základní specifikaci SMTP přispělo mnoho prominentních lidí, včetně Jona Postela , Erica Allmana, Davea Crockera, Neda Frieda, Randalla Jellense, Johna Klensina a Keitha Moorea.
E-mail je prezentován poštovním klientem (MUA, mail user agent ) poštovnímu serveru (MSA, mail Sending agent) pomocí SMTP na TCP portu 587. Odtud MSA doručuje poštu svým agentům přenosu zpráv (MTA) . převodní agent ). Často jsou tito dva agenti pouze různými instancemi stejného softwaru běžícího s různými nastaveními na stejném zařízení. Místní zpracování může být prováděno jak na samostatném stroji, tak rozděleno mezi různá zařízení; v prvním případě zúčastněné procesy sdílejí soubory, ve druhém případě se k předání zprávy interně používá SMTP, přičemž každý hostitel je nakonfigurován tak, aby používal další zařízení jako mezihostitel . Každý proces je sám o sobě MTA, tedy server SMTP.
Hraniční MTA musí najít cílového hostitele. Využívá Domain Name System ( DNS ) k vyhledání záznamů mail exchanger (MX) pro doménu příjemce (část adresy vpravo od symbolu @). Záznam MX vrácené pošty obsahuje název cílového hostitele. MTA se poté připojí k serveru Exchange jako klient SMTP.
Jakmile cíl MX obdrží příchozí zprávu, předá ji agentovi pro doručování pošty ( MDA ), aby zprávu doručil lokálně. MDA poskytuje možnost ukládat zprávy ve vhodném formátu poštovní schránky. Příjem pošty lze opět provádět jak několika, tak jedním počítačem - obrázek ukazuje dvě nejbližší poštovní schránky pro každý případ. MDA může doručovat zprávy přímo do úložiště nebo je přenášet po síti pomocí SMTP nebo jakýchkoli jiných prostředků, včetně Local Mail Transfer Protocol ( LMTP ), derivátu SMTP, navrženého pro tento účel.
Po doručení na lokální poštovní server je zpráva uložena pro dávkové vyhledávání pomocí ověřených poštovních klientů (MUA). Zprávu načítají aplikace koncových uživatelů (poštovní klienti) pomocí protokolu IMAP (Internet Message Access Protocol), který usnadňuje přístup ke zprávám a spravuje uloženou poštu, nebo pomocí protokolu POP (Post Office Protocol), který obvykle využívá tradiční mbox. formát souboru nebo proprietární systémy jako Microsoft Exchange/Outlook nebo Lotus Notes/Domino. Síťoví poštovní klienti mohou používat obě metody, ale vyhledávací protokol často neodpovídá oficiálním standardům.
SMTP definuje přenos zprávy, nikoli její obsah. Určuje tedy obal zprávy a její parametry (jako je odesílatel obalu), nikoli však záhlaví nebo tělo samotné zprávy. STD 10 a RFC 5321 definují SMTP (obal), zatímco STD 11 a RFC 5322 definují zprávu (záhlaví a tělo), oficiálně označované jako Internet Message Format.
SMTP je textový protokol, který vyžaduje spojení, pomocí kterého odesílatel zprávy komunikuje s příjemcem vydáváním příkazových řádků a přijímáním potřebných dat přes spolehlivý kanál, kterým je obvykle připojení TCP (Transmission Control Protocol - protokol řízení přenosu) . Relace SMTP se skládá z příkazů odeslaných klientem SMTP a odpovídajících odpovědí ze serveru SMTP . Při otevření relace si server a klient vymění své parametry. Relace může zahrnovat nula nebo více operací SMTP (transakcí).
Operace SMTP se skládá ze tří sekvencí příkaz/odpověď (viz příklad níže). Popis sekvencí:
Kromě mezilehlých odpovědí na příkaz DATA může být každá odpověď serveru kladná (kód odpovědi 2xx) nebo záporná. To druhé může být trvalé (kód 5xx) nebo dočasné (kód 4xx). Selhání serveru SMTP při odeslání zprávy je trvalou chybou; v tomto případě musí klient odeslat vrácený e-mail. Po resetu - kladná odpověď bude zpráva s největší pravděpodobností odmítnuta. Server může také indikovat, že jsou od klienta očekávána další data (kód 3xx).
Počáteční hostitel (klient SMTP) může být buď poštovní klient koncového uživatele (funkčně definovaný jako poštovní agent - MUA) nebo agent přenosu zpráv (MTA) na serveru, tj. server se chová jako klient v odpovídající relaci pro přenos. zpráva. Plně funkční servery udržují fronty zpráv pro opětovné odeslání zprávy v případě chyb.
MUA zná ze svého nastavení server SMTP pro odchozí poštu. Server SMTP, který funguje jako klient, tedy přeposílání zpráv, určuje, ke kterému serveru se má připojit, vyhledáním prostředku záznamu DNS MX (Mail eXchange) pro doménu každého příjemce . V případě, že záznam MX není nalezen, kompatibilní MTA (ne všechny) se vrátí k jednoduchému záznamu A. Forwardery lze také nakonfigurovat pro použití inteligentních hostitelů.
SMTP server jako klient naváže TCP spojení se serverem na portu 25, určeném pro SMTP , MUA musí používat port 587 pro připojení k Message Delivery Agent (MSA). Hlavní rozdíl mezi MTA a MSA je v tom, že autentizace SMTP je vyžadována pouze pro MSA.
SMTP je pouze doručovací protokol. Nemůže na vyžádání načítat zprávy ze vzdáleného serveru. Pro získávání pošty a správu poštovních schránek byly vyvinuty další protokoly jako POP a IMAP. SMTP však poskytuje možnost spustit zpracování fronty zpráv na vzdáleném serveru, přičemž žádající systém může přijímat všechny zprávy na něj směrované (viz Spouštění vzdálené fronty zpráv níže). POP a IMAP jsou preferovány, když počítač uživatele není vždy zapnutý nebo je dočasně připojen k internetu.
Vzdálené spouštění fronty zpráv je funkce SMTP, která umožňuje vzdálenému hostiteli začít zpracovávat frontu zpráv serveru, aby mohl přijímat zprávy pro něj určené pomocí příkazu TURN. Tato funkce však byla považována za nezabezpečenou a byla rozšířena v RFC 1985 týmem ETRN, který pracuje bezpečněji s metodou ověřování založenou na informacích DNS .
ODMR (On-Demand Mail Relay - přenos pošty na vyžádání) je rozšíření SMTP standardizované v RFC 2645 , které umožňuje předání zprávy ověřenému uživateli.
Mnoho uživatelů, jejichž znaková sada se liší od latinky, čelí požadavku na e-mailovou adresu v latince. K vyřešení tohoto problému byl vytvořen RFC 6531 , který poskytuje možnosti internacionalizace pro SMTP - rozšíření SMTPUTF8. RFC 6531 poskytuje podporu pro vícebajtové a neASCII znaky v poštovní adrese, například: δοκιμή@παράδειγμα.δοκιμή nebo 测试@测试.测试. Současná podpora je omezená, ale existuje velký zájem o široké přijetí RFC 6531 a souvisejících RFC v zemích s velkou uživatelskou základnou, které nemají latinku jako své původní písmo.
Poštovní klient musí znát IP adresu SMTP serveru, která je uvedena v rámci konfigurace (obvykle ve formě DNS jména). Server bude doručovat odchozí zprávy jménem uživatele.
Správci serveru musí řídit, kteří klienti mohou server používat. To jim umožňuje bojovat proti zneužívání, jako je spam. Běžně se používají dvě řešení:
V tomto případě SMTP server ISP neumožní přístup uživatelům „mimo“ síť ISP. Přesněji řečeno, server může přijímat pouze uživatele, jejichž IP adresu poskytuje ISP, což je ekvivalentní požadavku na připojení k internetu prostřednictvím tohoto ISP. Mobilní uživatel může být často v jiné síti než jeho ISP, a proto nebudou odesílány žádné zprávy.
Tento systém má několik druhů. Server SMTP organizace může například udělit přístup pouze uživatelům ve stejné síti a blokovat ostatní uživatele. Server může také provádět řadu kontrol IP adresy klienta. Tyto metody byly běžně používány organizacemi a institucemi, jako jsou univerzity, pro interní použití serveru. Většina z nich však nyní používá metody ověřování popsané níže.
Omezením přístupu na určité adresy mohou správci serveru snadno určit adresu jakéhokoli narušitele. Pokud může uživatel pro připojení k Internetu používat různé ISP, tento druh omezení se stává nepraktickým a změna nakonfigurované adresy odchozího serveru SMTP je nepraktická. Je velmi žádoucí mít možnost používat informace o nastavení klienta, které není třeba měnit.
Namísto výše popsaného omezení umístění moderní servery SMTP obvykle vyžadují, aby uživatelé byli před získáním přístupu ověřeni. Tento systém, i když je flexibilnější, podporuje mobilní uživatele a poskytuje jim pevný výběr nakonfigurovaného serveru odchozí pošty.
Server, který je přístupný široké síti a neposkytuje tyto typy omezení přístupu, se nazývá otevřený přenos . Nyní jsou takové servery považovány za nevychované.
Správci serverů volí, zda budou klienti pro přenos odchozí pošty používat port 25 nebo 587. Specifikace a mnoho serverů podporuje oba porty. Ačkoli některé servery podporují port 465 pro zabezpečené SMTP, je vhodnější použít standardní porty a příkazy ESMTP, pokud je vyžadována zabezpečená relace mezi klientem a serverem.
Některé servery jsou nakonfigurovány tak, aby odmítaly všechny přenosy na portu 25, ale uživatelé ověření na portu 587 mohou předávat zprávy na jakoukoli platnou adresu.
Někteří ISP zachycují port 25 a přesměrují provoz na svůj vlastní server SMTP, bez ohledu na cílovou adresu. Jejich uživatelé tedy nemají přístup k serveru mimo síť ISP na portu 25.
Některé servery podporují ověřený přístup na dalším portu jiném než 25, což uživatelům umožňuje připojit se k nim, i když je port 25 blokován.
C: - klient, S: - servery
S: (čeká na spojení) C: (Připojuje se k portu serveru 25) S:220 mail.company.tld ESMTP vás těší! C:HELO Název domény S:250 by měl být kvalifikovaný C:MAIL OD: <someusername@somecompany.ru> S:250 someusername@somecompany.ru odesílatel přijat C:RCPT TO: <user1@company.tld> S:250 user1@company.tld v pořádku C:RCPT TO: <user2@company.tld> S:550 user2@company.tld neznámý uživatelský účet C:DATA S:354 Zadejte e-mail, zakončete "." na lince sám o sobě C:From: Nějaký uživatel <someusername@somecompany.ru> C:To:User1 <user1@company.tld> C:Předmět:předmět C:Content-Type: text/plain C: C: Ahoj! C:. S:250 769947 zpráva přijata k doručení C: UKONČIT S:221 mail.company.tld CommuniGate Pro SMTP ukončení připojení S: (uzavře připojení)V důsledku takové relace bude dopis doručen na adresu user1@company.tld, ale nebude doručen na adresu user2@company.tld, protože taková adresa neexistuje.
Mnoho klientů požaduje rozšíření SMTP podporovaná serverem pomocí příkazu HELOz Extended SMTP Specification ( RFC 1870 ). HELOpoužívá se pouze v případě, že server neodpověděl na EHLO. Moderní klienti mohou pomocí klíče SIZE rozšíření ESMTP požádat o maximální velikost zprávy, která bude přijata. Starší klienti a servery se mohou pokoušet odesílat příliš velké zprávy, které budou odmítnuty po spotřebování síťových zdrojů, včetně doby připojení. Uživatelé mohou ručně předdefinovat maximální velikost akceptovanou servery ESMTP. Klient nahradí příkaz příkazem HELOEHLO.
S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Dobrý den bob.example.org [192.0.2.201] S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELPsmtp2.example.com oznamuje, že přijme zprávu ne větší než 14 680 064 oktetů (8 bitů). V závislosti na skutečném využití serveru nemusí aktuálně přijmout zprávu této velikosti. V nejjednodušším případě ESMTP server oznámí maximální VELIKOST pouze při interakci s uživatelem prostřednictvím HELO.
Enhanced SMTP (ESMTP) (někdy nazývaný Enhanced SMTP) je definice rozšíření protokolu pro standard SMTP. ESMTP byl definován v listopadu 1995 v IETF RFC 1869, který vytvořil společný rámec pro všechna existující a budoucí rozšíření. ESMTP definuje konzistentní a kontrolované prostředky, pomocí kterých lze klienty a servery ESMTP identifikovat a servery mohou určit, která rozšíření podporují. Původní protokol SMTP podporoval pouze neověřené nešifrované textové zprávy ASCII, náchylné k útokům typu man-in-the-middle, spoofingu a spamu a vyžadující, aby jakákoli binární data byla před přenosem zakódována do čitelného textu. Řada dalších rozšíření naznačuje různé mechanismy řešení těchto problémů.
Klienti se učí možnosti podporované serverem pomocí pozdravu EHLO namísto původního pozdravu HELO. Klienti se vrátí k HELO pouze v případě, že server nepodporuje rozšíření SMTP. Moderní klienti mohou pomocí klíčového slova SIZE rozšíření ESMTP požádat server o maximální velikost zprávy, která bude přijata. Starší klienti a servery se mohou pokoušet odesílat zprávy, které jsou příliš velké a budou odmítnuty po vyčerpání síťových zdrojů, včetně doby připojení k síťovým linkám, která se účtuje po minutách. Uživatelé mohou předem určit maximální povolenou velikost pro servery ESMTP ručně. Klient nahradí příkaz HELO příkazem EHLO.
Nativní SMTP podporuje pouze jeden text ASCII, takže jakákoli binární data musí být před odesláním zakódována jako text v těle zprávy a poté příjemcem dekódována. Běžně se používalo binární kódování textu, jako je uuencode a BinHex.
K vyřešení tohoto problému byl vyvinut příkaz 8BITMIME. To bylo standardizováno v roce 1994 jako RFC 1652. Usnadňuje transparentní výměnu e-mailových zpráv obsahujících oktety mimo sedmibitovou znakovou sadu ASCII tím, že je zakóduje jako části obsahu MIME, obvykle zakódované v Base64.
On-Demand Mail Relay (ODMR) je rozšíření SMTP standardizované v RFC 2645, které umožňuje pravidelně připojenému serveru SMTP přijímat e-maily zařazené do fronty, když je připojen.
Nativní SMTP podporuje pouze e-mailové adresy ASCII, což je nepohodlné pro uživatele, jejichž vlastní skript není založen na latinské abecedě nebo kteří používají diakritiku mimo znakovou sadu ASCII. Toto omezení bylo odstraněno s rozšířeními umožňujícími UTF-8 v názvech adres. RFC 5336 zavedl experimentální příkaz UTF8SMTP a později byl nahrazen RFC 6531, který zavedl příkaz SMTPUTF8. Tato rozšíření poskytují podporu pro vícebajtové a neASCII znaky v e-mailových adresách, jako jsou ty s diakritikou a jiné jazykové znaky, jako je řečtina a čínština. Současná podpora je omezená, ale existuje velký zájem o široké přijetí RFC 6531 a souvisejících RFC v zemích, jako je Čína s velkou uživatelskou základnou, kde je latinka (ASCII) cizí písmo.
ESMTP je stejně jako SMTP protokol používaný k přenosu internetové pošty. Používá se jako meziserverový transportní protokol a (s vynuceným omezeným chováním) jako protokol pro odesílání pošty. Primární autentizační funkcí pro klienty ESMTP je otevřít přenos pomocí příkazu EHLO (Extended HELLO) spíše než 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 své konfiguraci. Server ESMTP vrací kód 250 OK ve víceřádkové odpovědi se svou doménou a seznamem klíčových slov, které označují, která rozšíření podporuje. Server vyhovující RFC 821 vrací kód chyby 500, což klientům ESMTP umožňuje vyzkoušet buď HELO, nebo UKONČIT. Každé rozšíření služby je definováno ve schváleném formátu v následujících dokumentech RFC a registrováno u úřadu IANA (Internet Assigned Numbers Authority). První definice byly doplňkové služby RFC 821: SEND, SOML (odeslat nebo poslat poštou), SAML (odeslat a poslat poštou), EXPN, HELP a TURN. Formát pro další SMTP slovesa byl také nastaven pro nové parametry v MAIL a RCPT. Některá relativně běžná klíčová slova (ne všechna odpovídají příkazům), která se dnes používají:
Formát ESMTP byl přeformulován v RFC 2821 (nahrazuje RFC 821) a aktualizován na nejnovější definici v RFC 5321 v roce 2008. Podpora příkazu EHLO na serverech se stala povinnou a HELO označilo povinné vrácení zpět. Nestandardní, neregistrovaná rozšíření služeb mohou být použita na základě dvoustranné dohody, tyto služby jsou označeny klíčovým slovem EHLO zprávy začínajícím na „X“ a případnými dalšími parametry nebo podobně označenými slovesy. Příkazy SMTP nerozlišují velká a malá písmena. Jsou zde velká písmena pouze pro zdůraznění. Server SMTP, který vyžaduje speciální metodu psaní velkých písmen, je v rozporu se standardem.
Původní specifikace SMTP neobsahovala prostředky k ověřování odesílatelů. Následně, v RFC 2554 , rozšíření bylo představeno. Rozšíření SMTP (ESMTP) poskytuje e-mailovým klientům možnost specifikovat mechanismus zabezpečení serveru, ověřování a bezpečnostní profil SASL (Simple Authentication and Security Layer) pro následné přenosy zpráv.
Produkty společnosti Microsoft implementují svůj vlastní protokol - SPA (Secure Password Authentication) pomocí rozšíření SMTP-AUTH.
Nepraktičnost rozšířené implementace a správy SMTP-AUTH však znamená, že problém spamu s ní nelze vyřešit.
Rozsáhlá změna SMTP, stejně jako jeho úplná náhrada, je považována za nepraktickou kvůli obrovské instalované základně SMTP. Internet Mail 2000 byl jedním z uchazečů o takovou náhradu.
Spam funguje na základě různých faktorů, včetně nestandardních implementací MTA, bezpečnostních zranitelností v operačních systémech (zhoršených trvalým širokopásmovým připojením), které umožňují spammerům vzdáleně ovládat a odesílat spam z počítače koncového uživatele.
Existuje několik návrhů pro postranní protokoly, které pomáhají SMTP pracovat. Anti-Spam Research Group (ASRG), divize Internet Technology Research Group, pracuje na autentizaci pošty a dalších návrzích k zajištění jednoduché autentizace, která je flexibilní, nenáročná a škálovatelná. Nedávné aktivity Internet Engineering Task Force (IETF) zahrnují MARID (2004), vedoucí ke dvěma experimentům schváleným IETF v roce 2005, a DomainKeys Identified Mail v roce 2006.
STARTTLS v RFC 1869 přikazuje zahájit relaci nikoli příkazem HELO, ale příkazem EHLO. Pokud server rozšíření nepodporuje, odpoví EHLOchybou. V takovém případě musí klient odeslat příkaz HELOa nepoužívat rozšíření protokolu.
Pokud server podporuje ESMTP, pak kromě pozdravu ohlásí seznam podporovaných rozšíření protokolu SMTP, například:
ehlo office.company1.tld 250-mail.company2.tld vás těší 250-DSN VELIKOST 250 250 STARTTLS 250-AUTH PŘIHLÁŠENÍ PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-OTÁČEK 250-ATRN 250-NE-ŽÁDÁNÍ 250-NÁPOVĚDA 250-PIPELINING 250 hej| Schémata URI | |
|---|---|
| Oficiální | |
| neoficiální | |
| Základní protokoly TCP /IP podle vrstev modelu OSI | |
|---|---|
| Fyzický | |
| odvedeny | |
| síť | |
| Doprava | |
| zasedání | |
| Zastoupení | |
| Aplikovaný | |
| Uplatněno jiné | |
| Seznam portů TCP a UDP | |