| SMTP | |
|---|---|
| Név | Egyszerű levélátviteli protokoll |
| Szint ( az OSI modell szerint ) | Alkalmazott |
| Család | TCP/IP |
| Port/ID |
25/TCP, 587/TCP 465/TCP (SMTP SSL felett) |
| A protokoll célja | E-mail küldése |
| Leírás | RFC 5321 |
| Főbb megvalósítások (kliensek) | MUA ( The Bat!, MS Outlook , MS Outlook Express , Mozilla Thunderbird , Claws Mail stb.) |
| Alapvető megvalósítások ( szerverek ) | MTA ( sendmail , postfix , OpenSMTPD , qmail , exim , Microsoft Exchange Server , MDaemon ) |
| Bővíthetőség | Hozzáadás. parancsok ( RFC 2449 ) |
| Médiafájlok a Wikimedia Commons oldalon | |
Az SMTP ( angolul Simple Mail Transfer Protocol – egy egyszerű levélátviteli protokoll) egy széles körben használt hálózati protokoll , amelyet az e-mailek TCP/ IP hálózatokon keresztüli továbbítására terveztek.
Az SMTP-t először az RFC 821 - ben (1982) írták le; az RFC 5321 (2008) legújabb frissítése egy méretezhető kiterjesztést tartalmaz - ESMTP ( Extended SMTP ) . Jelenleg az "SMTP-protokoll" kifejezés általában a kiterjesztésére utal. Az SMTP protokollt úgy tervezték, hogy a kimenő leveleket a 25-ös TCP - porton keresztül továbbítsa .
Míg az elektronikus levelezőszerverek és más üzenettovábbító ügynökök SMTP-t használnak az e-mail üzenetek küldésére és fogadására, addig a felhasználói szintű levelezőkliens-alkalmazások általában csak az SMTP-t használják az üzenetek küldésére a levelezőszervernek továbbítás céljából. Az üzenetek fogadásához az ügyfélalkalmazások általában POP -t ( Post Office Protocol ) vagy IMAP -t ( Internet Message Access Protocol ) vagy saját rendszereket (például Microsoft Exchange és Lotus Notes / Domino ) használnak a fiók eléréséhez .
Az 1960-as években az elektronikus kommunikáció különféle formáit alkalmazták. Az emberek bizonyos nagyszámítógépekhez tervezett rendszerekkel kommunikáltak egymással . Ahogy egyre több számítógép kapcsolódott össze, különösen az amerikai kormányzati hálózaton, az ARPANET -en, szabványokat fejlesztettek ki, hogy a különböző rendszerek felhasználói elektronikus üzeneteket írhassanak egymásnak. Ezek az 1970-es években kidolgozott szabványok váltak az SMTP alapjává.
Az SMTP gyökerei két, 1971-ben leírt implementációra vezethetők vissza, a Mail Box Protocol-ra és az SNDMSG-re, amelyet Ray Tomlinson, a BBN Technologies munkatársa "talált fel" olyan TOPS-20/TENEX számítógépekhez, amelyek ARPANET-en keresztül küldtek üzeneteket (akkor kevesebb mint 50 gazdagép).
A további megvalósítások közé tartozik az 1973-ban kifejlesztett FTP Mail és Mail Protocol. A fejlesztés az 1970-es években folytatódott, amíg az ARPANET 1980 körül a modern internetté fejlődött . Ugyanebben az évben Jon Postel javasolta a Mail Transport Protocolt. , aminek köszönhetően az FTP megszűnt létezni. a levéltovábbítás alapja. Az SMTP az RFC 821 -ben jelent meg (a Postel is írta) 1982 augusztusában.
Az SMTP szabványt nagyjából egy időben fejlesztették ki a Usenet adathálózattal, amely némileg hasonlít az SMTP-hez. Az SMTP-t széles körben használták az 1980-as évek elején. Akkoriban ez a Unix alapú Unix to Unix CoPy (UUCP) levelezőprogram kiegészítője volt, amely alkalmasabb volt a szakaszosan csatlakoztatott eszközök közötti elektronikus üzenetek továbbításának kezelésére. Másrészt, az SMTP kiválóan működik, ha mind a küldő, mind a fogadó eszközök folyamatosan csatlakoznak a hálózathoz. Mindkét eszköz tárolási és továbbítási mechanizmust használ, és a push technológia példája . Míg a Usenet hírcsoportokat továbbra is UUCP használatával terjesztik a szerverek között, az UUCP levelek gyakorlatilag eltűntek az útválasztási fejlécként használt "bang path"-val (a hálózaton lévő gazdagépek sorozata, amelyen az üzenetnek el kell jutnia a célállomáshoz). A Sender Rewrite cikk technikai háttérinformációkat nyújt az RFC 1123 előtti korai SMTP és forrásútválasztás történetéről .
A Sendmail volt az egyik első (ha nem az első) üzenetátviteli ügynök, amely megvalósította az SMTP-t. Az SMTP-t támogató népszerű kiszolgálóprogramok közé tartozik a Postfix , qmail , Novell GroupWise , Exim , Novell NetMail , Microsoft Exchange Server , Sun Java System Messaging Server .
Az üzenetküldést ( RFC 2476 ) és az SMTP-AUTH-t ( RFC 2554 ) 1998-ban és 1999-ben vezették be. és ismertette az elektronikus üzenetek továbbításának új trendjeit. Kezdetben az SMTP-kiszolgálók jellemzően egy szervezeten belüliek voltak, üzeneteket fogadtak külső szervezetektől, és a szervezet üzeneteit továbbították a külvilág felé. De az idő múlásával az SMTP-kiszolgálók (üzenettovábbító ügynökök) valójában kibővítették funkcióikat, és végül üzenetkézbesítő ügynökökké váltak a felhasználói levelezőalkalmazások számára , amelyek némelyike ma már a szervezeten kívülről továbbítja a leveleket (például egy vállalati vezető utazás közben szeretné e-mailek küldéséhez a vállalati SMTP-kiszolgálón keresztül).
Ez a probléma a World Wide Web gyors fejlődésének és népszerűségének következményeként azt jelentette, hogy az SMTP-nek konkrét szabályokat és módszereket kellett tartalmaznia az üzenetek továbbítására és a felhasználók felhatalmazására, hogy megakadályozzák a visszaéléseket, például a kéretlen levelek ( spam ) továbbítását.
Mivel ez a protokoll eredetileg szöveges ( ASCII ) interfész volt, sok nem angol nyelvű bináris fájlokkal és karakterekkel nem működött jól. Az olyan szabványokat, mint a Multipurpose Internet Mail Extensions ( MIME ) fejlesztették ki a bináris fájlok kódolására az SMTP-n keresztüli továbbításhoz. A Post-Sendmail továbbítási ügynökök jellemzően a tisztán 8 bites opciót is megvalósították, így egy alternatív "csak nyolcat küldj" stratégia is használható tetszőleges szöveges adatok küldésére (bármilyen nyolc bites ASCII-szerű karakterkódolásban) SMTP-n keresztül. A krakozyabr esetében azonban továbbra is fennállt a probléma, amelyet a gyártók eltérő karakterkészlet-megjelenítése okozott, bár maguk a postai címek továbbra is kizárólag ASCII használatát engedélyezték. Manapság a tisztán 8 bites átviteli ügynökök jellemzően támogatják a 8BITMIME kiterjesztést, amely szinte olyan egyszerűvé teszi a bináris fájlok átvitelét, mint az egyszerű szöveget. Az SMTPUTF8 kiterjesztést nemrégiben hozták létre az UTF-8 kódolású szöveg támogatására , lehetővé téve nemzetközi tartalom és címek beillesztését olyan szkriptek használatával, mint a cirill vagy a kínai.
Számos prominens személy járult hozzá az alapvető SMTP specifikációhoz, köztük Jon Postel , Eric Allman , Dave Crocker, Ned Fried, Randall Jellens, John Klensin és Keith Moore.
Az e-maileket egy levelezőkliens (MUA, mail user agent ) jeleníti meg a levelezőszervernek (MSA, mail submission agent) az 587-es TCP - porton lévő SMTP használatával. Innen az MSA kézbesíti a leveleket az üzenetátviteli ügynökeihez (MTA). , mail transzfer ügynök ). Ez a két ügynök gyakran csak ugyanazon szoftver különböző példányai, amelyek ugyanazon az eszközön különböző beállításokkal futnak. A helyi feldolgozás különálló gépen és különböző eszközök között is megosztható; az első esetben az érintett folyamatok fájlokat osztanak meg, a második esetben az SMTP-t használják az üzenet belső továbbítására, és minden gazdagép úgy van beállítva, hogy a következő eszközt köztes gazdagépként használja . Mindegyik folyamat maga egy MTA, azaz egy SMTP szerver.
Az él MTA-nak meg kell találnia a célállomást. A Domain Name System ( DNS ) segítségével megkeresi a címzett tartományához tartozó mail Exchanger (MX) rekordokat (a címnek a @ szimbólumtól jobbra eső része). A visszaküldött mail MX rekord tartalmazza a célállomás nevét. Az MTA ezután SMTP-kliensként csatlakozik az Exchange szerverhez.
Amint az MX-célpont fogad egy bejövő üzenetet, továbbítja azt egy levélkézbesítési ügynöknek ( MDA ), hogy az üzenetet helyileg kézbesítse. Az MDA lehetőséget biztosít az üzenetek megfelelő postafiók-formátumban történő mentésére. A levelek fogadása ismét több és egy számítógéppel is megoldható - a képen minden esetben a két legközelebbi postafiók látható. Az MDA képes üzeneteket közvetlenül a tárhelyre kézbesíteni, vagy a hálózaton keresztül továbbítani SMTP-n vagy bármilyen más módon, beleértve a Local Mail Transfer Protocol-t ( LMTP ), az SMTP egy származékát, amelyet erre a célra terveztek.
A helyi levelezőszerverre történő kézbesítés után az üzenetet a rendszer a hitelesített levelezőkliensek (MUA) kötegelt keresése céljából tárolja. Az üzenetet a végfelhasználói alkalmazások (levelezőkliensek) az IMAP (Internet Message Access Protocol) protokoll használatával kérik le, amely megkönnyíti az üzenetekhez való hozzáférést és kezeli a tárolt leveleket, vagy a POP (Post Office Protocol) protokollt, amely általában a hagyományos mboxot használja. fájlformátumot, vagy olyan védett rendszereket, mint a Microsoft Exchange/Outlook vagy a Lotus Notes/Domino. A hálózati levelezőkliensek bármelyik módszert használhatják, de a keresési protokoll gyakran nem felel meg a hivatalos szabványoknak.
Az SMTP az üzenet továbbítását határozza meg, nem a tartalmát. Így megadja az üzenet burkolóját és paramétereit (például a burkoló feladóját), de magát az üzenet fejlécét vagy törzsét nem. Az STD 10 és az RFC 5321 definiálja az SMTP-t (a wrapper), míg az STD 11 és az RFC 5322 határozza meg az üzenetet (fejléc és törzs), amelyet hivatalosan internetes üzenetformátumnak neveznek.
Az SMTP egy kapcsolatigényes szöveg alapú protokoll, amellyel az üzenet küldője parancssorok kibocsátásával és a szükséges adatok fogadásával kommunikál a címzettel egy megbízható csatornán keresztül, amely általában egy TCP kapcsolat (Transmission Control Protocol - Transmission Control Protocol) . Az SMTP-munkamenet az SMTP- kliens által küldött parancsokból és az SMTP- kiszolgáló megfelelő válaszaiból áll . A munkamenet megnyitásakor a szerver és az ügyfél kicseréli a paramétereit. Egy munkamenet nulla vagy több SMTP-műveletet (tranzakciót) tartalmazhat.
Egy SMTP-művelet három parancs/válasz sorozatból áll (lásd az alábbi példát). A sorozatok leírása:
A DATA parancs közbenső válaszain kívül minden szerver válasz lehet pozitív (2xx válaszkód) vagy negatív. Ez utóbbi viszont lehet állandó (5xx kód) vagy ideiglenes (4xx kód). Az, hogy az SMTP-szerver nem tudta elküldeni az üzenetet, állandó hiba; ebben az esetben az ügyfélnek visszapattanó e-mailt kell küldenie. Visszaállítás után - pozitív válasz esetén az üzenet valószínűleg elutasításra kerül. A szerver jelezheti azt is, hogy további adatok várhatók a klienstől (3xx kód).
A kezdeti gazdagép (SMTP-kliens) lehet egy végfelhasználói levelezőkliens (funkcionálisan levelezési ügynökként definiálva – MUA), vagy egy üzenetátviteli ügynök (MTA) a kiszolgálón, azaz a szerver kliensként működik a megfelelő továbbítási munkamenetben. az üzenet. A teljesen működőképes szerverek üzenetsorokat tartanak fenn, hogy hiba esetén újraküldjék az üzenetet.
A MUA a beállításaiból ismeri a kimenő levelek SMTP-kiszolgálóját. Az SMTP-kiszolgáló, amely ügyfélként működik, azaz üzeneteket továbbít, meghatározza, hogy melyik szerverhez kell csatlakozni azáltal, hogy megkeresi a DNS MX (Mail eXchange) rekorderőforrást minden egyes címzett tartományához . Abban az esetben, ha nem található MX rekord, a kompatibilis MTA-k (nem mindegyik) egy egyszerű A-rekordra térnek vissza . A továbbítók intelligens gazdagépek használatára is konfigurálhatók.
Az ügyfélként működő SMTP-kiszolgáló a 25-ös, SMTP-hez tervezett porton TCP-kapcsolatot hoz létre a szerverrel . A MUA-nak az 587-es portot kell használnia az üzenetkézbesítő ügynökhöz (MSA) való csatlakozáshoz. A fő különbség az MTA és az MSA között, hogy csak az utóbbihoz szükséges SMTP hitelesítés.
Az SMTP csak egy kézbesítési protokoll. Igény szerint nem tud üzeneteket letölteni egy távoli szerverről. Más protokollokat, például a POP-ot és az IMAP-t fejlesztettek ki a levelek lekérésére és a postafiók-kezelésre. Az SMTP azonban lehetőséget biztosít az üzenetsor-feldolgozás elindítására egy távoli kiszolgálón, így a kérelmező rendszer megkaphatja az összes hozzá intézett üzenetet (lásd lent a Távoli üzenetsor kezdete című részt). A POP és az IMAP használata előnyös, ha a felhasználó számítógépe nincs mindig bekapcsolva, vagy ideiglenesen csatlakozik az internethez.
A távoli üzenetsor indítása egy SMTP-szolgáltatás, amely lehetővé teszi a távoli gazdagép számára, hogy megkezdje a kiszolgáló üzenetsorának feldolgozását, hogy a TURN paranccsal fogadhassa a neki szánt üzeneteket. Ezt a funkciót azonban nem tartották biztonságosnak, és az ETRN csapata kiterjesztette az RFC 1985 - ben, amely biztonságosabban működik a DNS-információ-alapú hitelesítési módszerrel .
Az ODMR (On-Demand Mail Relay – mail relay on demand) egy RFC 2645 szabványban szabványosított SMTP-bővítmény, amely lehetővé teszi az üzenetek továbbítását egy hitelesített felhasználóhoz.
Sok olyan felhasználó, akinek a karakterkészlete eltér a latin nyelvtől, szembesül azzal, hogy latin nyelvű e-mail címet kell megadnia. A probléma megoldására létrehozták az RFC 6531 -et , amely nemzetközivé teszi az SMTP-t – az SMTPUTF8 kiterjesztését. Az RFC 6531 támogatja a többbájtos és nem ASCII karaktereket postai címekben, például: δοκιμή@παράδειγμα.δοκιμή vagy 测试@测试.测试@测试.测试. A jelenlegi támogatás korlátozott, de nagy érdeklődés mutatkozik az RFC 6531 és a kapcsolódó RFC-k széles körű elterjedése iránt olyan nagy felhasználói bázissal rendelkező országokban, ahol nem a latin az anyanyelvi írása.
A levelezőkliensnek ismernie kell az SMTP-szerver IP-címét, amelyet a konfiguráció részeként adunk meg (általában DNS-név formájában). A szerver a felhasználó nevében kézbesíti a kimenő üzeneteket.
A szerveradminisztrátoroknak szabályozniuk kell, hogy mely ügyfelek használhatják a szervert. Ez lehetővé teszi számukra a visszaélések, például a spam elleni küzdelmet. Általában két megoldást használnak:
Ebben az esetben az internetszolgáltató SMTP-kiszolgálója nem engedélyezi a hozzáférést az internetszolgáltató hálózatán kívüli felhasználók számára. Pontosabban, a szerver csak olyan felhasználókat tud fogadni, akiknek IP-címét az internetszolgáltató biztosítja, ami egyenértékű az internetkapcsolat szükségességével ezen az internetszolgáltatón keresztül. Előfordulhat, hogy egy mobilfelhasználó más hálózaton van, mint az internetszolgáltatója, ezért nem küldenek üzeneteket.
Ennek a rendszernek több fajtája van. Például előfordulhat, hogy egy szervezet SMTP-kiszolgálója csak az ugyanazon a hálózaton lévő felhasználók számára biztosít hozzáférést, miközben blokkolja a többi felhasználót. A szerver egy sor ellenőrzést is végezhet a kliens IP-címén. Ezeket a módszereket gyakran használták szervezetek és intézmények, például egyetemek a szerver belső használatára. A legtöbbjük azonban az alábbiakban ismertetett hitelesítési módszereket használja.
Bizonyos címekhez való hozzáférés korlátozásával a szerveradminisztrátorok könnyen meghatározhatják bármely betolakodó címét. Ha a felhasználó különböző internetszolgáltatókat használhat az internethez való csatlakozáshoz, akkor ez a fajta korlátozás kivitelezhetetlenné válik, és a konfigurált kimenő SMTP-szerver címének megváltoztatása nem praktikus. Nagyon kívánatos, hogy olyan ügyfélbeállítási információkat használhassanak, amelyeket nem kell módosítani.
A korábban leírt helymeghatározás helyett a modern SMTP-kiszolgálók jellemzően hitelesítést igényelnek a felhasználók hozzáférése előtt. Ez a rendszer, bár rugalmasabb, támogatja a mobil felhasználókat, és fix választási lehetőséget biztosít számukra a konfigurált kimenő levelezőszerver között.
Az olyan szervert, amely elérhető a széles hálózaton, és nem rendelkezik ilyen típusú hozzáférési korlátozásokkal, nyílt továbbításnak nevezzük . Manapság az ilyen szervereket rossz modornak tekintik.
A szerveradminisztrátorok döntik el, hogy a kliensek a 25-ös vagy az 587-es portot használják-e a kimenő levelek továbbítására.A specifikációk és sok kiszolgáló mindkét portot támogatja. Bár egyes kiszolgálók támogatják a 465-ös portot a biztonságos SMTP-hez, célszerűbb szabványos portokat és ESMTP-parancsokat használni, ha biztonságos munkamenetre van szükség az ügyfél és a szerver között.
Egyes kiszolgálók úgy vannak beállítva, hogy elutasítsák a 25-ös porton lévő összes továbbítást, de az 587-es porton hitelesített felhasználók bármilyen érvényes címre továbbíthatják az üzeneteket.
Egyes internetszolgáltatók elfogják a 25-ös portot, és a forgalmat a saját SMTP-kiszolgálójukra továbbítják, függetlenül a célcímtől. Így felhasználóik nem érhetik el a szervert az internetszolgáltató hálózatán kívül a 25-ös porton.
Egyes kiszolgálók a 25-ös porttól eltérő további porton is támogatják a hitelesített hozzáférést, így a felhasználók akkor is csatlakozhatnak hozzájuk, ha a 25-ös port le van tiltva.
C: - kliens, S: - szerverek
S: (kapcsolatra vár) C: (A 25-ös szerverporthoz csatlakozik) S:220 mail.company.tld Az ESMTP örül, hogy látlak! C:HELO Az S:250 domain nevet minősíteni kell C:MAIL FELTŐL: <[email protected]> S:250 [email protected] feladó elfogadva C:RCPT TO: <[email protected]> S:250 [email protected] rendben C:RCPT TO: <[email protected]> S:550 [email protected] ismeretlen felhasználói fiók C:ADATOK S:354 Írja be a mail címet, a végén "." egy vonalon önmagában C:From: Valamely felhasználó <[email protected]> C:Címzett:Felhasználó1 <felhasználó1@vállalat.tld> C:Tárgy:tárgy C:Content-Type: szöveg/sima C: C: Szia! C:. S:250 769947 üzenetet elfogadunk kézbesítésre C: KÉSZ S:221 mail.company.tld CommuniGate Pro SMTP kapcsolat bezárása S: (lezárja a kapcsolatot)Egy ilyen munkamenet eredményeként a levél a [email protected] címre érkezik, de nem a [email protected] címre, mert ilyen cím nem létezik.
HELOSok ügyfél az Extended SMTP Specification ( RFC 1870 ) parancsával kéri a kiszolgáló által támogatott SMTP-bővítményeket . HELOcsak akkor használatos, ha a szerver nem válaszol a -ra EHLO. A modern kliensek az ESMTP-bővítmény SIZE kulcsával kérhetik le az elfogadott maximális üzenetméretet. A régebbi kliensek és szerverek megkísérelhetnek túl nagy üzeneteket küldeni, amelyeket a rendszer elutasít, miután a hálózati erőforrásokat – beleértve a csatlakozási időt is – igénybe veszi. A felhasználók manuálisan előre meghatározhatják az ESMTP-kiszolgálók által elfogadott maximális méretet. Az ügyfél a parancsot HELOEHLO-ra cseréli.
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-PIPELINEING S: 250 SEGÍTSÉGAz smtp2.example.com bejelenti, hogy 14 680 064 oktettnél (8 bites bájtnál) nem nagyobb üzenetet fogad el . A szerver tényleges használatától függően előfordulhat, hogy jelenleg nem fogad ekkora üzenetet. A legegyszerűbb esetben az ESMTP-szerver csak a maximális MÉRETet jelenti be, amikor a felhasználóval a -n keresztül kommunikál HELO.
Az Enhanced SMTP (ESMTP) (néha továbbfejlesztett SMTP-nek is nevezik) az SMTP szabvány protokollbővítmény-definíciója. Az ESMTP-t 1995 novemberében határozták meg az IETF RFC 1869-ben, amely közös keretet hozott létre az összes meglévő és jövőbeli bővítéshez. Az ESMTP egy konzisztens és ellenőrzött eszközt határoz meg, amellyel az ESMTP-kliensek és -kiszolgálók azonosíthatók, és a szerverek meghatározhatják, hogy mely bővítményeket támogatják. Az eredeti SMTP-protokoll csak a nem hitelesített, nem titkosított ASCII szöveges üzeneteket támogatta, amelyek érzékenyek a köztes támadásokra, hamisításra és kéretlen levelekre, és minden bináris adatot olvasható szöveggé kell kódolni az átvitel előtt. Számos további kiterjesztés jelzi a problémák megoldásának különféle mechanizmusait.
Az ügyfelek az eredeti HELO helyett az EHLO üdvözlés használatával tanulják meg a szerver által támogatott opciókat. Az ügyfelek csak akkor térnek vissza a HELO-hoz, ha a szerver nem támogatja az SMTP-bővítményeket. A modern kliensek az ESMTP-bővítmény SIZE kulcsszavával kérhetik meg a szervertől a maximálisan elfogadott üzenetméretet. A régebbi kliensek és szerverek megkísérelhetnek túl nagy üzeneteket küldeni, és a hálózati erőforrások – beleértve a hálózati kapcsolatokhoz való kapcsolódási időt is – kihasználása után elutasításra kerülnek, ami percenként kerül számlázásra. A felhasználók manuálisan előre meghatározhatják az ESMTP-kiszolgálók megengedett maximális méretét. Az ügyfél lecseréli a HELO parancsot az EHLO parancsra.
A natív SMTP csak egyetlen ASCII-szövegtörzset támogat, ezért minden bináris adatot szövegként kell kódolni az üzenettörzsben az átvitel előtt, majd a címzettnek dekódolnia kell. Gyakran használtak bináris szövegkódolásokat, például uuencode-ot és BinHex-et.
A 8BITMIME parancsot ennek a problémának a megoldására fejlesztették ki. 1994-ben szabványosították RFC 1652 néven. Megkönnyíti a hét bites ASCII karakterkészleten kívüli oktetteket tartalmazó e-mail üzenetek átlátható cseréjét azáltal, hogy a MIME tartalom részeként kódolja őket, általában Base64 kódolású.
Az On-Demand Mail Relay (ODMR) az RFC 2645 szabványban szabványosított SMTP-bővítmény, amely lehetővé teszi az időszakosan csatlakoztatott SMTP-kiszolgáló számára, hogy fogadja a sorba állított e-maileket, amikor csatlakozik.
A natív SMTP csak az ASCII-alapú e-mail címeket támogatja, ami kényelmetlen azoknak a felhasználóknak, akiknek saját szkriptje nem a latin ábécén alapul, vagy akik az ASCII-karakterkészleten kívüli diakritikus jeleket használnak. Ezt a korlátozást eltávolítottuk a kiterjesztések révén, amelyek lehetővé teszik az UTF-8 használatát a címnevekben. Az RFC 5336 bevezette a kísérleti UTF8SMTP parancsot, majd később az RFC 6531 váltotta fel, amely bevezette az SMTPUTF8 parancsot. Ezek a bővítmények támogatják a többbájtos és nem ASCII karaktereket az e-mail címekben, például a diakritikus karaktereket és más nyelvi karaktereket, például a görög és a kínai karaktereket. A jelenlegi támogatottság korlátozott, de nagy az érdeklődés az RFC 6531 és a kapcsolódó RFC-k széles körű elterjedése iránt olyan országokban, mint például Kína, ahol nagy felhasználói bázis van, ahol a latin (ASCII) idegen írásmód.
Az SMTP-hez hasonlóan az ESMTP is egy internetes levelek átvitelére használt protokoll. Szerverközi szállítási protokollként és (kikényszerített korlátozott viselkedéssel) levélküldési protokollként használják. Az ESMTP-kliensek elsődleges hitelesítési funkciója az átvitel megnyitása az EHLO (Extended HELLO) paranccsal a HELO (Hello, eredeti RFC 821 szabvány) helyett. A szerver sikeresen (250-es kód), hibával (550-es kód) vagy hibával (500-as, 501-es, 502-es, 504-es vagy 421-es kód) válaszol a konfigurációjától függően. Az ESMTP-kiszolgáló egy többsoros válaszban 250 OK kódot ad vissza a tartományával és a kulcsszavak listájával, jelezve, hogy mely kiterjesztéseket támogatja. Az RFC 821 szabványnak megfelelő kiszolgáló 500-as hibakódot ad vissza, lehetővé téve az ESMTP-kliensek számára a HELO vagy a QUIT kipróbálását. Minden szolgáltatásbővítményt jóváhagyott formátumban határoznak meg a következő RFC-kben, és regisztrálják az Internet Assigned Numbers Authority (IANA) által. Az első definíciók az RFC 821 kiegészítő szolgáltatások voltak: SEND, SOML (küldés vagy levél), SAML (küldés és levél), EXPN, HELP és TURN. A további SMTP igék formátuma is be lett állítva a MAIL és az RCPT új paramétereihez. Néhány ma használatos viszonylag gyakori kulcsszó (nem mindegyik felel meg a parancsoknak):
Az ESMTP formátumot újrafogalmazták az RFC 2821-ben (az RFC 821 helyébe lépve), és 2008-ban frissítették az RFC 5321 legújabb definíciójára. Az EHLO parancs támogatása a szervereken kötelezővé vált, a HELO pedig kötelező visszaállítást jelölt meg. Nem szabványos, nem regisztrált szolgáltatásbővítmények kétoldalú megállapodással használhatók, ezeket a szolgáltatásokat "X"-el kezdődő EHLO-üzenet kulcsszóval és az ehhez hasonlóan jelölt további paraméterekkel vagy igékkel jelöljük. Az SMTP parancsok nem különböztetik meg a kis- és nagybetűket. Itt csak a kiemelés kedvéért vannak nagybetűvel írva. Egy speciális nagybetűs írásmódot igénylő SMTP-kiszolgáló ellentmond a szabványnak.
Az eredeti SMTP-specifikáció nem tartalmazott a feladók hitelesítésére szolgáló eszközt. Ezt követően az RFC 2554 -ben egy kiterjesztést vezettek be. Az SMTP (ESMTP) kiterjesztés lehetővé teszi az e-mail kliensek számára, hogy meghatározzák a kiszolgáló biztonsági mechanizmusát, hitelesítését és SASL (Simple Authentication and Security Layer) biztonsági profilját a későbbi üzenetátvitelhez.
A Microsoft termékek saját protokolljukat – SPA (Secure Password Authentication) – valósítják meg az SMTP-AUTH kiterjesztéssel.
Az SMTP-AUTH széles körben elterjedt megvalósításának és kezelésének kivitelezhetetlensége azonban azt jelenti, hogy a spam problémája nem oldható meg vele.
Az SMTP kiterjedt módosítása, valamint teljes cseréje az SMTP hatalmas telepített bázisa miatt nem praktikus. Az Internet Mail 2000 volt az egyik esélyes egy ilyen helyettesítésre.
A levélszemét számos tényezőn keresztül működik, ideértve a nem szabványos MTA-megvalósításokat, az operációs rendszerek biztonsági réseit (amelyeket tovább súlyosbít a tartós szélessávú kapcsolat), amelyek lehetővé teszik a kéretlen levelek távolról történő vezérlését és spam küldését a végfelhasználó számítógépéről.
Számos javaslat létezik az SMTP működését segítő mellékprotokollokra. Az Anti-Spam Research Group (ASRG), az Internet Technology Research Group részlege, a levelezés hitelesítésén és egyéb javaslatokon dolgozik, hogy egyszerű, rugalmas, könnyű és méretezhető hitelesítést biztosítson. Az Internet Engineering Task Force (IETF) legutóbbi tevékenységei közé tartozik a MARID (2004), amely 2005-ben két IETF által jóváhagyott kísérlethez vezetett, valamint a DomainKeys Identified Mail 2006-ban.
A STARTTLS az RFC 1869 -ben azt utasítja, hogy a munkamenetet ne paranccsal HELO, hanem paranccsal indítsa el EHLO. Ha a szerver nem támogatja a kiterjesztéseket, akkor EHLOhibával válaszol, ebben az esetben a kliensnek parancsot kell küldenie, HELOés nem kell használnia a protokollkiterjesztéseket.
Ha a szerver támogatja az ESMTP-t, akkor az üdvözlő üzeneten kívül a támogatott SMTP protokollbővítmények listáját is jelenti, például:
ehlo office.company1.tld A 250-mail.company2.tld örömmel találkozunk 250-DSN 250-ES MÉRETES 250-STARTTLS 250 HITELES BEJELENTKEZÉS EGYSZERŰ CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-FORDULAT 250-ATRN 250-NEM KÉRÉS 250-SEGÍTSÉG 250-CSŐVEZÉS 250 hello| URI- sémák | |
|---|---|
| Hivatalos | |
| nem hivatalos | |
| Alapvető TCP / IP protokollok az OSI modell rétegei szerint | |
|---|---|
| Fizikai | |
| csatornázott | |
| hálózat | |
| Szállítás | |
| ülés | |
| Reprezentáció | |
| Alkalmazott | |
| Egyéb alkalmazva | |
| A TCP és UDP portok listája | |