| SMTP | |
|---|---|
| Navn | Simple Mail Transfer Protocol |
| Niveau (ifølge OSI-modellen ) | Anvendt |
| Familie | TCP/IP |
| Port/ID |
25/TCP, 587/TCP 465/TCP (SMTP over SSL) |
| Formål med protokollen | Sender e-mail |
| Specifikation | RFC 5321 |
| Vigtigste implementeringer (klienter) | MUA ( The Bat!, MS Outlook , MS Outlook Express , Mozilla Thunderbird , Claws Mail osv.) |
| Kerneimplementeringer ( servere ) | MTA ( sendmail , postfix , OpenSMTPD , qmail , exim , Microsoft Exchange Server , MDaemon ) |
| Udvidelsesmuligheder | Tilføje. kommandoer ( RFC 2449 ) |
| Mediefiler på Wikimedia Commons | |
SMTP ( engelsk Simple Mail Transfer Protocol - en simpel mailoverførselsprotokol) er en udbredt netværksprotokol designet til at overføre e-mail over TCP /IP-netværk.
SMTP blev først beskrevet i RFC 821 (1982); den seneste opdatering i RFC 5321 (2008) inkluderer en skalerbar udvidelse - ESMTP ( Extended SMTP ) . I øjeblikket refererer udtrykket "SMTP-protokol" normalt til dets udvidelser. SMTP-protokollen er designet til at transmittere udgående post ved hjælp af TCP -port 25.
Mens elektroniske postservere og andre meddelelsesrelæagenter bruger SMTP til at sende og modtage e-mailbeskeder, bruger e-mailklientapplikationer på brugerniveau generelt kun SMTP til at sende meddelelser til e-mailserveren til videresendelse. For at modtage meddelelser bruger klientprogrammer normalt enten POP ( Post Office Protocol ) eller IMAP ( Internet Message Access Protocol ) eller proprietære systemer (såsom Microsoft Exchange og Lotus Notes / Domino ) til at få adgang til kontoen ,
I 1960'erne blev der brugt forskellige former for elektronisk kommunikation. Folk kommunikerede med hinanden ved hjælp af systemer designet til specifikke mainframes . Efterhånden som flere og flere computere blev forbundet, især på den amerikanske regerings netværk, ARPANET , blev standarder udviklet, så brugere på forskellige systemer kunne skrive elektroniske beskeder til hinanden. Disse standarder, udviklet i 1970'erne, blev grundlaget for SMTP.
Rødderne til SMTP kan spores tilbage til to implementeringer beskrevet i 1971, Mail Box Protocol og SNDMSG, som blev "opfundet" af Ray Tomlinson fra BBN Technologies til TOPS-20/TENEX-computere, der sendte beskeder over ARPANET (på det tidspunkt) mindre end 50 værter).
Yderligere implementeringer omfatter FTP Mail og Mail Protocol, udviklet i 1973. Udviklingen fortsatte gennem 1970'erne, indtil ARPANET udviklede sig til det moderne internet omkring 1980. Samme år foreslog Jon Postel Mail Transport Protocol. , takket være hvilken FTP ophørte med at være grundlaget for overførsel af post. SMTP offentliggjort i RFC 821 (også skrevet af Postel) i august 1982.
SMTP-standarden blev udviklet omkring samme tid som Usenet , et datanetværk med nogle ligheder med SMTP. SMTP blev meget brugt i begyndelsen af 1980'erne. På det tidspunkt var det en tilføjelse til det Unix-baserede Unix to Unix CoPy (UUCP) mailprogram, som var mere velegnet til at håndtere transmissionen af elektroniske beskeder mellem periodisk tilsluttede enheder. På den anden side fungerer SMTP fantastisk, når både sende- og modtageenhederne er forbundet på netværket hele tiden. Begge enheder bruger en lager- og fremadgående mekanisme og er eksempler på push-teknologi . Mens Usenet- nyhedsgrupper stadig udbredes mellem servere, der bruger UUCP, er UUCP-mail reelt forsvundet sammen med "bang-stien" (sekvensen af værtsmaskiner på netværket, som en besked skal tage for at nå sin destination), der blev brugt som routing-headers. Sender Rewrite-artiklen giver teknisk baggrundsinformation om historien om tidlig SMTP og kilderouting før RFC 1123 .
Sendmail var en af de første (hvis ikke den første) meddelelsesoverførselsagenter til at implementere SMTP. Andre populære serverprogrammer, der understøtter SMTP, omfatter Postfix , qmail , Novell GroupWise , Exim , Novell NetMail, Microsoft Exchange Server , Sun Java System Messaging Server.
Indsendelse af meddelelser ( RFC 2476 ) og SMTP-AUTH ( RFC 2554 ) blev introduceret i 1998 og 1999. og beskrev nye tendenser inden for transmission af elektroniske meddelelser. I starten var SMTP-servere typisk interne i en organisation, idet de modtog beskeder fra eksterne organisationer og videresendte organisationens beskeder til omverdenen. Men med tiden udvidede SMTP-servere (meddelelsesoverførselsagenter) faktisk deres funktioner og blev til sidst meddelelsesleveringsagenter for brugere-mail-applikationer , hvoraf nogle nu videresendte e-mails uden for organisationen (f.eks. ønsker en virksomhedsleder, mens han var på rejse, for at sende e-mail ved hjælp af virksomhedens SMTP-server).
Dette problem, som en konsekvens af World Wide Webs hurtige udvikling og popularitet , betød, at SMTP skulle inkludere specifikke regler og metoder til at videresende meddelelser og give brugerne tilladelse til at forhindre misbrug såsom videresendelse af uopfordret post ( spam ).
Da denne protokol oprindeligt var en tekstgrænseflade ( ASCII ), fungerede den ikke godt med binære filer og tegn fra mange ikke-engelske sprog. Standarder såsom Multipurpose Internet Mail Extensions ( MIME ) blev udviklet til at kode binære filer til transmission over SMTP. Post-Sendmail-videresendelsesagenter implementerede typisk også den rene 8-bit mulighed, så en alternativ "bare send otte"-strategi kan bruges til at sende vilkårlige tekstdata (i enhver otte-bit ASCII-lignende tegnkodning) over SMTP. Der var dog stadig et problem med krakozyabr , forårsaget af forskellig visning af tegnsæt af producenter, selvom postadresserne i sig selv stadig tillod brugen af udelukkende ASCII. I dag understøtter rene 8-bit overførselsagenter typisk udvidelsen 8BITMIME, som gør overførsel af binære filer næsten lige så let som almindelig tekst. SMTPUTF8-udvidelsen blev for nylig oprettet til at understøtte UTF-8- kodet tekst , hvilket gør det muligt at inkludere internationalt indhold og adresser ved hjælp af scripts som kyrillisk eller kinesisk.
Mange prominente personer har bidraget til den centrale SMTP-specifikation, herunder Jon Postel , Eric Allman , Dave Crocker, Ned Fried, Randall Jellens, John Klensin og Keith Moore.
E- mail præsenteres af en mailklient (MUA, mail user agent ) til en mailserver (MSA, mail submission agent) ved hjælp af SMTP på TCP port 587. Derfra leverer MSA’en mail til sine message transfer agents (MTA’er). , mail overførselsagent ). Ofte er disse to agenter bare forskellige forekomster af den samme software, der kører med forskellige indstillinger på den samme enhed. Lokal behandling kan udføres både på en separat maskine og opdelt mellem forskellige enheder; i det første tilfælde deler de involverede processer filer, i det andet tilfælde bruges SMTP til at videresende beskeden internt, hvor hver vært er konfigureret til at bruge den næste enhed som en mellemvært . Hver proces er i sig selv en MTA, det vil sige en SMTP-server.
Edge MTA skal finde målværten. Den bruger Domain Name System ( DNS ) til at slå op på MX-poster (mail exchanger) for modtagerens domæne (den del af adressen til højre for @-symbolet). Den returnerede mail-MX-post indeholder navnet på målværten. MTA'en forbinder derefter til udvekslingsserveren som en SMTP-klient.
Når MX-målet modtager en indgående besked, sender det den videre til en postleveringsagent ( MDA ) for at levere beskeden lokalt. MDA giver mulighed for at gemme beskeder i det passende postkasseformat. Modtagelse af post kan igen udføres af både flere og én computer - billedet viser de to nærmeste postkasser for hver sag. MDA kan levere beskeder direkte til lageret eller overføre dem over netværket ved hjælp af SMTP eller enhver anden måde, inklusive Local Mail Transfer Protocol ( LMTP ), en afledt af SMTP, designet til dette formål.
Efter levering til den lokale mailserver, gemmes beskeden til batchsøgning af godkendte mailklienter (MUA'er). Beskeden hentes af slutbrugerapplikationer (mail-klienter) ved hjælp af IMAP -protokollen (Internet Message Access Protocol), som letter adgangen til beskeder og administrerer lagret post, eller ved hjælp af POP -protokollen (Post Office Protocol), som normalt bruger den traditionelle mbox filformat eller proprietære systemer som Microsoft Exchange/Outlook eller Lotus Notes/Domino. Netværksmailklienter kan bruge begge metoder, men søgeprotokollen er ofte ikke op til officielle standarder.
SMTP definerer transmissionen af en besked, ikke dens indhold. Den specificerer således meddelelsesindpakningen og dens parametre (såsom afsenderen af indpakningen), men ikke selve meddelelsens overskrift eller brødtekst. STD 10 og RFC 5321 definerer SMTP (indpakningen), mens STD 11 og RFC 5322 definerer meddelelsen (header og body), officielt omtalt som Internet Message Format.
SMTP er en forbindelseskrævet tekstbaseret protokol, hvorved afsenderen af en meddelelse kommunikerer med modtageren ved at udstede kommandolinjer og modtage de nødvendige data gennem en pålidelig kanal, som normalt er en TCP-forbindelse (Transmission Control Protocol - transmissionskontrolprotokol) . En SMTP-session består af kommandoer sendt af SMTP - klienten og tilsvarende svar fra SMTP -serveren . Når en session åbnes, udveksler serveren og klienten sine parametre. En session kan omfatte nul eller flere SMTP-operationer (transaktioner).
En SMTP-operation består af tre kommando-/svarsekvenser (se eksempel nedenfor). Beskrivelse af sekvenser:
Ud over mellemsvar for DATA-kommandoen kan hvert serversvar være positivt (svarkode 2xx) eller negativt. Sidstnævnte kan til gengæld være permanent (kode 5xx) eller midlertidig (kode 4xx). SMTP-serverens manglende afsendelse af meddelelsen er en permanent fejl. i dette tilfælde skal klienten sende en afvist e-mail. Efter nulstilling - et positivt svar, vil beskeden højst sandsynligt blive afvist. Serveren kan også indikere, at der forventes yderligere data fra klienten (kode 3xx).
Den oprindelige vært (SMTP-klient) kan enten være en slutbruger-mailklient (funktionelt defineret som en mailagent - MUA) eller en beskedoverførselsagent (MTA) på serveren, dvs. serveren fungerer som en klient i den tilsvarende session for at videresende beskeden. Fuldt funktionelle servere opretholder meddelelseskøer for at gentransmittere en meddelelse i tilfælde af fejl.
MUA kender SMTP-serveren til udgående post fra dens indstillinger. SMTP-serveren, der fungerer som en klient, det vil sige videresender meddelelser, bestemmer, hvilken server der skal oprettes forbindelse til ved at slå DNS MX (Mail eXchange)-postressourcen op for hver modtagers domæne . I tilfælde af at en MX-record ikke findes, falder kompatible MTA'er (ikke alle) tilbage til en simpel A-record . Forwardere kan også konfigureres til at bruge Smart-værter.
SMTP-serveren, der fungerer som en klient, etablerer en TCP-forbindelse til serveren på port 25, designet til SMTP . MUA'en skal bruge port 587 for at oprette forbindelse til Message Delivery Agent (MSA). Den største forskel mellem MTA og MSA er, at SMTP-godkendelse kun er påkrævet for sidstnævnte.
SMTP er blot en leveringsprotokol. Den kan ikke hente beskeder fra en ekstern server efter behov. Andre protokoller såsom POP og IMAP er udviklet til hentning af post og postkassehåndtering. SMTP giver dog mulighed for at starte meddelelseskøbehandling på en ekstern server, hvorved det anmodende system kan modtage alle meddelelser, der er dirigeret til det (se Remote Message Queue Starting nedenfor). POP og IMAP foretrækkes, når brugerens computer ikke altid er tændt eller er midlertidigt forbundet til internettet.
Remote Message Queue Starting er en SMTP-funktion, der gør det muligt for en fjernvært at begynde at behandle serverens meddelelseskø, så den kan modtage meddelelser, der er beregnet til den ved hjælp af TURN-kommandoen. Denne funktion blev dog betragtet som usikker og blev udvidet i RFC 1985 af ETRN-teamet, som arbejder mere sikkert med en DNS-informationsbaseret godkendelsesmetode .
ODMR (On-Demand Mail Relay - mail relay on demand) er en SMTP-udvidelse standardiseret i RFC 2645 , der gør det muligt at videresende en besked til en godkendt bruger.
Mange brugere, hvis tegnsæt adskiller sig fra latin, står over for kravet om en e-mailadresse på latin. For at løse dette problem blev RFC 6531 oprettet , som giver internationaliseringsmuligheder for SMTP - en udvidelse af SMTPUTF8. RFC 6531 understøtter multibyte- og ikke-ASCII-tegn i en postadresse, for eksempel: δοκιμή@παράδειγμα.δοκιμή eller 测试@测试.测试. Den nuværende støtte er begrænset, men der er stor interesse for udbredt anvendelse af RFC 6531 og relaterede RFC'er i lande med store brugerbaser, der ikke har latin som deres oprindelige script.
Mailklienten skal kende IP-adressen på SMTP-serveren, som gives som en del af konfigurationen (normalt i form af et DNS-navn). Serveren vil levere udgående beskeder på vegne af brugeren.
Serveradministratorer skal kontrollere, hvilke klienter der kan bruge serveren. Dette giver dem mulighed for at bekæmpe misbrug såsom spam. To løsninger er almindeligt anvendt:
I dette tilfælde vil internetudbyderens SMTP-server ikke tillade adgang til brugere "udenfor" internetudbyderens netværk. Mere præcist kan serveren kun acceptere brugere, hvis IP-adresse er leveret af internetudbyderen, hvilket svarer til at kræve en internetforbindelse gennem denne internetudbyder. En mobilbruger kan ofte være på et andet netværk end deres internetudbyder, og derfor vil der ikke blive sendt beskeder.
Dette system har flere varianter. For eksempel giver en organisations SMTP-server muligvis kun adgang til brugere på det samme netværk, mens de blokerer andre brugere. Serveren kan også udføre en række kontroller af klientens IP-adresse. Disse metoder blev almindeligvis brugt af organisationer og institutioner, såsom universiteter, til intern brug af serveren. Men de fleste af dem bruger nu godkendelsesmetoderne beskrevet nedenfor.
Ved at begrænse adgangen til bestemte adresser kan serveradministratorer nemt bestemme adressen på enhver ubuden gæst. Hvis brugeren kan bruge forskellige internetudbydere til at oprette forbindelse til internettet, bliver denne form for begrænsning upraktisk, og det er upraktisk at ændre den konfigurerede udgående SMTP-serveradresse. Det er yderst ønskeligt at kunne bruge klientindstillingsoplysninger, som ikke skal ændres.
I stedet for den tidligere beskrevne placeringsbegrænsning kræver moderne SMTP-servere typisk, at brugerne godkendes, før de får adgang. Selvom dette system er mere fleksibelt, understøtter det mobile brugere og giver dem et fast valg af konfigureret udgående mailserver.
En server, der er tilgængelig for det brede netværk og ikke giver disse typer adgangsbegrænsninger, kaldes et åbent relæ . Nu betragtes sådanne servere som dårlige manerer.
Serveradministratorer vælger, om klienter vil bruge port 25 eller 587 til at videresende udgående e-mail. Specifikationer og mange servere understøtter begge porte. Selvom nogle servere understøtter port 465 til sikker SMTP, er det at foretrække at bruge standardporte og ESMTP-kommandoer, hvis en sikker session er nødvendig mellem klient og server.
Nogle servere er konfigureret til at afvise alle relæer på port 25, men brugere, der er godkendt på port 587, har tilladelse til at videresende beskeder til enhver gyldig adresse.
Nogle internetudbydere opfanger port 25 og videresender trafik til deres egen SMTP-server, uanset destinationsadressen. Deres brugere kan således ikke få adgang til serveren uden for internetudbyderens netværk på port 25.
Nogle servere understøtter autentificeret adgang på en anden port end 25, hvilket giver brugerne mulighed for at oprette forbindelse til dem, selvom port 25 er blokeret.
C: - klient, S: - servere
S: (afventer forbindelse) C: (Forbinder til serverport 25) S:220 mail.company.tld ESMTP er glad for at se dig! C: HELO S:250 domænenavn bør være kvalificeret C:MAIL FRA: <someusername@somecompany.ru> S:250 someusername@somecompany.ru afsender accepteret C:RCPT TIL: <bruger1@company.tld> S:250 bruger1@company.tld ok C:RCPT TIL: <bruger2@company.tld> S:550 user2@company.tld ukendt brugerkonto C:DATA S:354 Indtast mail, afslut med "." på en linje for sig selv C:Fra: Nogle bruger <someusername@somecompany.ru> C:To:Bruger1 <bruger1@virksomhed.tld> C:Emne:emne C:Indholdstype: tekst/almindelig C: C: Hej! C:. S:250 769947 besked accepteret til levering C: AFSLUT S:221 mail.company.tld CommuniGate Pro SMTP lukker forbindelse S: (lukker forbindelsen)Som følge af en sådan session vil brevet blive leveret til user1@company.tld, men vil ikke blive leveret til user2@company.tld, fordi en sådan adresse ikke eksisterer.
Mange klienter anmoder om de SMTP-udvidelser, der understøttes af serveren ved hjælp af en kommando HELOfra den udvidede SMTP-specifikation ( RFC 1870 ). HELObruges kun hvis serveren ikke reagerede på EHLO. Moderne klienter kan bruge SIZE-nøglen til ESMTP-udvidelsen til at anmode om den maksimale meddelelsesstørrelse, der vil blive accepteret. Ældre klienter og servere kan forsøge at sende alt for store beskeder, som vil blive afvist efter at have forbrugt netværksressourcer, inklusive forbindelsestid. Brugere kan manuelt foruddefinere den maksimale størrelse, der accepteres af ESMTP-servere. Klienten erstatter kommandoen HELOmed EHLO.
S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hej bob.example.org [192.0.2.201] S: 250-STØRRELSE 14680064 S: 250-PIPELINING S: 250 HJÆLPsmtp2.example.com annoncerer, at det vil acceptere en besked, der ikke er større end 14.680.064 oktetter (8-bit bytes). Afhængigt af serverens faktiske brug accepterer den muligvis ikke en meddelelse af denne størrelse i øjeblikket. I det enkleste tilfælde vil ESMTP-serveren kun annoncere den maksimale STØRRELSE, når den interagerer med brugeren via HELO.
Enhanced SMTP (ESMTP) (nogle gange kaldet Enhanced SMTP) er en protokoludvidelsesdefinition for SMTP-standarden. ESMTP blev defineret i november 1995 i IETF RFC 1869, som etablerede en fælles ramme for alle eksisterende og fremtidige udvidelser. ESMTP definerer en konsistent og kontrolleret måde, hvormed ESMTP-klienter og -servere kan identificeres, og servere kan angive, hvilke udvidelser de understøtter. Den originale SMTP-protokol understøttede kun uautentificerede ukrypterede ASCII-tekstbeskeder, modtagelige for man-in-the-middle-angreb, spoofing og spamming og kræver, at alle binære data kodes til læsbar tekst før transmission. En række yderligere udvidelser angiver forskellige mekanismer til løsning af disse problemer.
Klienter lærer server-understøttede muligheder ved at bruge EHLO-hilsenen i stedet for den originale HELO. Klienter falder kun tilbage til HELO, hvis serveren ikke understøtter SMTP-udvidelserne. Moderne klienter kan bruge nøgleordet SIZE i ESMTP-udvidelsen til at bede serveren om den maksimale meddelelsesstørrelse, der vil blive accepteret. Ældre klienter og servere kan forsøge at sende meddelelser, der er for store og vil blive afvist efter opbrug af netværksressourcer, inklusive forbindelsestid til netværkslinks, som faktureres pr. minut. Brugere kan forudbestemme den maksimale tilladte størrelse for ESMTP-servere manuelt. Klienten erstatter HELO-kommandoen med EHLO-kommandoen.
Native SMTP understøtter kun en enkelt ASCII-teksttekst, så alle binære data skal kodes som tekst i den pågældende meddelelsestekst før transmission og derefter afkodes af modtageren. Binære tekstkodninger såsom uuencode og BinHex blev almindeligt brugt.
8BITMIME-kommandoen blev udviklet til at løse dette problem. Det blev standardiseret i 1994 som RFC 1652. Det letter den gennemsigtige udveksling af e-mail-meddelelser, der indeholder oktetter uden for syv-bit ASCII-tegnsættet ved at kode dem som dele af MIME-indhold, normalt Base64-kodet.
On-Demand Mail Relay (ODMR) er en SMTP-udvidelse standardiseret i RFC 2645, der gør det muligt for en periodisk tilsluttet SMTP-server at modtage e-mail i kø for den, når den er tilsluttet.
Native SMTP understøtter kun ASCII-e-mail-adresser, hvilket er ubelejligt for brugere, hvis eget script ikke er baseret på det latinske alfabet, eller som bruger diakritiske tegn uden for ASCII-tegnsættet. Denne begrænsning er blevet fjernet med udvidelser for at tillade UTF-8 i adressenavne. RFC 5336 introducerede den eksperimentelle UTF8SMTP-kommando og blev senere afløst af RFC 6531, som introducerede SMTPUTF8-kommandoen. Disse udvidelser understøtter multibyte- og ikke-ASCII-tegn i e-mail-adresser, såsom dem med diakritiske tegn og andre sprogtegn, såsom græsk og kinesisk. Den nuværende støtte er begrænset, men der er stor interesse for udbredt anvendelse af RFC 6531 og relaterede RFC'er i lande som Kina med store brugerbaser, hvor latin (ASCII) er et udenlandsk script.
Ligesom SMTP er ESMTP en protokol, der bruges til at overføre internetmail. Den bruges som en inter-server transportprotokol og (med påtvunget begrænset adfærd) som en e-mail-afsendelsesprotokol. Den primære godkendelsesfunktion for ESMTP-klienter er at åbne en transmission med kommandoen EHLO (Extended HELLO) i stedet for HELO (Hej, original RFC 821-standard). Serveren vil reagere med succes (kode 250), fejl (kode 550) eller fejl (kode 500, 501, 502, 504 eller 421), afhængigt af dens konfiguration. ESMTP-serveren returnerer en 250 OK-kode i et flerlinjesvar med sit domæne og en liste over nøgleord for at angive, hvilke udvidelser den understøtter. En RFC 821-kompatibel server returnerer en 500 fejlkode, så ESMTP-klienter kan prøve enten HELO eller QUIT. Hver tjenesteudvidelse er defineret i et godkendt format i efterfølgende RFC'er og registreret hos Internet Assigned Numbers Authority (IANA). De første definitioner var RFC 821 supplerende tjenester: SEND, SOML (send eller mail), SAML (send og mail), EXPN, HELP og TURN. Formatet for yderligere SMTP-verber er også blevet indstillet for nye parametre i MAIL og RCPT. Nogle relativt almindelige søgeord (som ikke alle svarer til kommandoer), der bruges i dag:
ESMTP-formatet blev omformuleret i RFC 2821 (erstatter RFC 821) og opdateret til den seneste definition i RFC 5321 i 2008. Understøttelse af EHLO-kommandoen på servere blev obligatorisk, og HELO markerede en obligatorisk rollback. Ikke-standardiserede, uregistrerede tjenesteudvidelser kan bruges ved bilateral aftale, disse tjenester er angivet med et EHLO-meddelelsesnøgleord, der begynder med "X" og med eventuelle yderligere parametre eller verber markeret på samme måde. SMTP-kommandoer skelner ikke mellem store og små bogstaver. De er kun med store bogstaver her for at fremhæve. En SMTP-server, der kræver en særlig metode til brug af store bogstaver, er imod standarden.
Den originale SMTP-specifikation indeholdt ikke et middel til at godkende afsendere. Efterfølgende blev der i RFC 2554 indført en udvidelse. SMTP-udvidelsen (ESMTP) giver e-mail-klienter mulighed for at specificere en serversikkerhedsmekanisme, godkendelse og en SASL - sikkerhedsprofil (Simple Authentication and Security Layer) til efterfølgende meddelelsesoverførsler.
Microsoft-produkter implementerer deres egen protokol - SPA (Secure Password Authentication) ved hjælp af SMTP-AUTH-udvidelsen.
Upraktiskheden af udbredt implementering og styring af SMTP-AUTH betyder imidlertid, at problemet med spam ikke kan løses med det.
En omfattende ændring af SMTP, såvel som en fuldstændig udskiftning af den, anses for upraktisk på grund af den enorme installerede base af SMTP. Internet Mail 2000 var en af kandidaterne til en sådan erstatning.
Spam fungerer gennem en række faktorer, herunder substandard MTA-implementeringer, sikkerhedssårbarheder i operativsystemer (forværret af en vedvarende bredbåndsforbindelse), der gør det muligt for spammere at fjernstyre og sende spam fra en slutbrugers computer.
Der er flere forslag til sideprotokoller for at hjælpe SMTP-arbejdet. Anti-Spam Research Group (ASRG), en afdeling af Internet Technology Research Group, arbejder på mailgodkendelse og andre forslag for at give enkel godkendelse, der er fleksibel, let og skalerbar. De seneste aktiviteter i Internet Engineering Task Force (IETF) omfatter MARID (2004), der førte til to IETF-godkendte eksperimenter i 2005, og DomainKeys Identified Mail i 2006.
STARTTLS i RFC 1869 instruerer at starte en session ikke med en kommando HELO, men med en kommando EHLO. Hvis serveren ikke understøtter udvidelserne, vil den reagere med en EHLOfejl, i hvilket tilfælde klienten skal sende en kommando HELOog ikke bruge protokoludvidelserne.
Hvis serveren understøtter ESMTP, vil den ud over hilsenen rapportere en liste over understøttede SMTP-protokoludvidelser, for eksempel:
ehlo office.company1.tld 250-mail.company2.tld er glad for at møde dig 250-DSN 250-STØRRELSE 250-STARTTLS 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-TURN 250-ATRN 250-NO-ANMELDELSE 250-HJÆLP 250-RØRLEDNING 250 hej| URI- ordninger | |
|---|---|
| Officiel | |
| uofficiel | |
| Grundlæggende TCP / IP-protokoller efter lag af OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliseret | |
| netværk | |
| Transportere | |
| session | |
| Repræsentation | |
| Anvendt | |
| Andet anvendt | |
| Liste over TCP- og UDP-porte | |