Simple Mail Transfer Protocol - Simple Mail Transfer Protocol

"SMTP" omdirigerer her. For e -mailleveringsvirksomheden, se SMTP (virksomhed) . For kort meddelelsesoverførselsprotokol, se GSM 03.40 .

Internet protokol suite
Påføringslag
Transportlag
Internet lag
Link lag

Den Simple Mail Transfer Protocol ( SMTP ) er en internet standard kommunikationsprotokol for elektronisk post transmission. Mail -servere og andre meddelelsesoverførselsagenter bruger SMTP til at sende og modtage mailbeskeder. E- mail-klienter på brugerniveau bruger typisk kun SMTP til at sende meddelelser til en mailserver til videresendelse og sender typisk udgående e-mail til mailserveren på port 587 eller 465 pr. RFC  8314 . For at hente meddelelser er IMAP (som erstattede den ældre POP3 ) standard, men proprietære servere implementerer også ofte proprietære protokoller, f.eks. Exchange ActiveSync .

Siden SMTPs introduktion i 1981 er den blevet opdateret, ændret og udvidet flere gange. Protokolversionen i almindelig brug i dag har en udvidelig struktur med forskellige udvidelser til godkendelse , kryptering , binær dataoverførsel og internationaliserede e -mail -adresser . SMTP -servere bruger normalt Transmission Control Protocol på portnummer 25 (til almindelig tekst) og 587 (til krypteret kommunikation).

Historie

Forgængere til SMTP

Forskellige former for en-til-en elektronisk besked blev brugt i 1960'erne. Brugere kommunikerede ved hjælp af systemer udviklet til specifikke mainframe -computere . Efterhånden som flere computere blev forbundet med hinanden, især i den amerikanske regerings ARPANET , blev der udviklet standarder for at tillade udveksling af meddelelser mellem forskellige operativsystemer. SMTP voksede ud af disse standarder udviklet i løbet af 1970'erne.

SMTP spore sine rødder til to implementeringer, der er beskrevet i 1971: Mail Box-protokollen, hvis gennemførelse har været omstridt, men diskuteres i RFC  196 og andre RFC'er, og det SNDMSG programmet, som ifølge RFC  2235 , Ray Tomlinson af BBN opfundet til TENEX computere til at sende mailbeskeder på tværs af ARPANET. Færre end 50 værter var forbundet til ARPANET på dette tidspunkt.

Yderligere implementeringer omfatter FTP Mail og Mail Protocol, begge fra 1973. Udviklingsarbejdet fortsatte gennem 1970'erne, indtil ARPANET overgik til det moderne internet omkring 1980.

Original SMTP

I 1980 udgav Jon Postel RFC  772, som foreslog Mail Transfer Protocol som en erstatning for brugen af File Transfer Protocol (FTP) til mail. RFC  780 fra maj 1981 fjernede alle referencer til FTP og tildelte port 57 til TCP og UDP , en tildeling, der siden er blevet fjernet af IANA . I november 1981 udgav Postel RFC  788 "Simple Mail Transfer Protocol".

SMTP-standarden blev udviklet på samme tid som Usenet , et en-til-mange kommunikationsnetværk med nogle ligheder.

SMTP blev meget udbredt i begyndelsen af ​​1980'erne. På det tidspunkt var det et supplement til Unix to Unix Copy Program (UUCP), som var bedre egnet til at håndtere e -mailoverførsler mellem maskiner, der var periodisk forbundet. SMTP fungerer derimod bedst, når både afsendelses- og modtagermaskiner er tilsluttet netværket hele tiden. Begge brugte en butik og fremad mekanisme og er eksempler på push -teknologi . Selvom Usenets nyhedsgrupper stadig blev spredt med UUCP mellem servere, er UUCP som en posttransport praktisk talt forsvundet sammen med de " bangstier ", den brugte som headings til routing af beskeder.

Sendmail , frigivet med 4.1cBSD i 1982, kort tid efter at RFC  788 blev offentliggjort i november 1981, var en af ​​de første mailoverførselsagenter , der implementerede SMTP. Efterhånden som BSD Unix blev det mest populære operativsystem på Internettet, blev Sendmail den mest almindelige MTA (mail transfer agent).

Den originale SMTP-protokol understøtter kun uautentificeret ukrypteret 7-bit ASCII-tekstkommunikation, der er modtagelig for trivielt man-in-the-middle-angreb , spoofing og spamming , og kræver, at alle binære data skal kodes til læsbar tekst før transmission. På grund af fraværet af en ordentlig godkendelsesmekanisme var hver SMTP -server ved design et åbent postrelæ . Den Internet Mail Consortium (IMC) rapporterede, at 55% af mailservere var åbne relæer i 1998, men mindre end 1% i 2002. På grund af spam bekymringer fleste e-mail-udbydere Bloklist åbne relæer, hvilket gør originale SMTP væsentlige upraktisk til almindelig brug på internettet .

Moderne SMTP

I november 1995 definerede RFC  1869 Extended Simple Mail Transfer Protocol (ESMTP), som etablerede en generel struktur for alle eksisterende og fremtidige udvidelser, der havde til formål at tilføje de funktioner, der mangler i den originale SMTP. ESMTP definerer konsekvente og håndterbare midler, hvormed ESMTP -klienter og servere kan identificeres, og servere kan angive understøttede udvidelser.

Beskedindlevering ( RFC  2476 ) og SMTP-AUTH ( RFC  2554 ) blev introduceret i 1998 og 1999, der begge beskriver nye tendenser inden for levering af e-mails. Oprindeligt var SMTP -servere typisk interne i en organisation, der modtog mail til organisationen udefra og videresendte meddelelser fra organisationen til ydersiden . Men efterhånden som tiden gik, udvidede SMTP -servere (e -mailoverførselsagenter) i praksis deres roller til at blive beskedindleveringsagenter for Mail -brugeragenter , hvoraf nogle nu videresendte e -mail fra en organisations yderside . (f.eks. ønsker en virksomhedsleder at sende e -mail på en rejse ved hjælp af virksomhedens SMTP -server.) Dette problem, en konsekvens af den hurtige udvidelse og popularitet af World Wide Web , betød, at SMTP skulle indeholde specifikke regler og metoder til videresendelse af mail og godkendelse af brugere for at forhindre misbrug såsom videresendelse af uopfordret e -mail ( spam ). Arbejdet med at sende beskeder ( RFC  2476 ) blev oprindeligt startet, fordi populære mailservere ofte ville omskrive e -mail i et forsøg på at løse problemer i den, f.eks. Ved at tilføje et domænenavn til en ukvalificeret adresse. Denne adfærd er nyttig, når beskeden, der rettes, er en indledende indsendelse, men farlig og skadelig, når meddelelsen stammer fra andre steder og videresendes. Ren adskillelse af post i indsendelse og videresendelse blev set som en måde at tillade og tilskynde til omskrivning af indsendelser, samtidig med at omskrivning af relæ blev forbudt. Efterhånden som spam blev mere udbredt, blev det også set som en måde at give tilladelse til, at mail sendes ud fra en organisation, samt sporbarhed. Denne adskillelse af relæ og indsendelse blev hurtigt et fundament for moderne e -mail -sikkerhedspraksis.

Da denne protokol udelukkende startede ASCII- tekstbaseret, handlede den ikke godt med binære filer eller tegn på mange ikke-engelske sprog. Standarder såsom Multipurpose Internet Mail Extensions ( MIME ) blev udviklet til at kode binære filer til overførsel via SMTP. Mailoverførselsagenter (MTA'er) udviklet efter Sendmail havde også en tendens til at blive implementeret 8-bit-clean , så den alternative "bare send otte" -strategi kunne bruges til at overføre vilkårlige tekstdata (i enhver 8-bit ASCII-lignende tegnkodning) via SMTP. Mojibake var stadig et problem på grund af forskellige tegnsætstilknytninger mellem leverandører, selvom e -mailadresserne selv stadig kun tillod ASCII . 8-bit-clean MTA'er i dag har en tendens til at understøtte 8BITMIME-udvidelsen, hvilket gør det muligt at overføre nogle binære filer næsten lige så let som almindelig tekst (grænser for linjelængde og tilladte oktetværdier gælder stadig, så MIME-kodning er nødvendig for de fleste ikke-tekst data og nogle tekstformater). I 2012 blev SMTPUTF8udvidelsen oprettet for at understøtte UTF-8- tekst, der tillader internationalt indhold og adresser i ikke- latinske scripts som kyrillisk eller kinesisk .

Mange mennesker bidrog til de centrale SMTP -specifikationer, blandt dem Jon Postel , Eric Allman , Dave Crocker, Ned Freed , Randall Gellens, John Klensin og Keith Moore .

Postbehandlingsmodel

Blå pile skildrer implementering af SMTP -variationer

E-mail indgives af en mail-klient ( mail user agent , MUA) til en mail-server ( mail indsendelse agent , MSA) ved hjælp af SMTP på TCP port 587. De fleste mailboks udbydere stadig tillade indsendelse på traditionel port 25. MSA leverer posten til sin mailoverførselsagent ( mailoverførselsagent , MTA). Ofte er disse to agenter forekomster af den samme software lanceret med forskellige muligheder på den samme maskine. Lokal behandling kan enten udføres på en enkelt maskine eller deles mellem flere maskiner; mailagentprocesser på en maskine kan dele filer, men hvis behandlingen er på flere maskiner, overfører de meddelelser mellem hinanden ved hjælp af SMTP, hvor hver maskine er konfigureret til at bruge den næste maskine som en smart vært . Hver proces er en MTA (en SMTP -server) i sig selv.

Grænse -MTA bruger DNS til at slå MX -posten (mailveksler) op for modtagerens domæne (delen af e -mail -adressen til højre for @). MX -posten indeholder navnet på mål -MTA. Baseret på målværten og andre faktorer vælger den afsendende MTA en modtagerserver og opretter forbindelse til den for at fuldføre mailudvekslingen.

Beskedoverførsel kan forekomme i en enkelt forbindelse mellem to MTA'er eller i en række humle gennem mellemled. En modtagende SMTP -server kan være den ultimative destination, et mellemliggende "relæ" (det vil sige, at den gemmer og videresender meddelelsen) eller en "gateway" (det vil sige, at den kan videresende meddelelsen ved hjælp af en anden protokol end SMTP). I henhold til RFC  5321 afsnit 2.1 er hvert hop en formel overdragelse af ansvaret for meddelelsen, hvorved den modtagende server enten skal levere beskeden eller korrekt rapportere manglen på at gøre det.

Når den sidste hop accepterer den indgående besked, overdrager den den til en postleveringsagent (MDA) for lokal levering. En MDA gemmer beskeder i det relevante postkasseformat . Som ved afsendelse kan denne modtagelse udføres ved hjælp af en eller flere computere, men i diagrammet ovenfor er MDA afbildet som en boks nær postvekslerboksen. En MDA kan levere meddelelser direkte til lagring eller videresende dem over et netværk ved hjælp af SMTP eller anden protokol, såsom Local Mail Transfer Protocol (LMTP), et derivat af SMTP designet til dette formål.

Når den er leveret til den lokale mailserver, gemmes den til batchhentning af godkendte mailklienter (MUA'er). Mail hentes af slutbrugerprogrammer, kaldet e-mail-klienter, ved hjælp af Internet Message Access Protocol (IMAP), en protokol, der både letter adgang til mail og administrerer gemt mail, eller Post Office Protocol (POP), der typisk bruger den traditionelle mbox- mail filformat eller et proprietært system, f.eks. Microsoft Exchange / Outlook eller Lotus Notes / Domino . Webmail -klienter kan bruge begge metoder, men hentningsprotokollen er ofte ikke en formel standard.

SMTP definerer besked transport , ikke budskabet indhold . Således definerer den postkonvolutten og dens parametre, såsom konvolutafsenderen , men ikke overskriften (undtagen sporinformation ) eller selve meddelelsens brødtekst. STD 10 og RFC  5321 definerer SMTP (konvolutten), mens STD 11 og RFC  5322 definerer meddelelsen (header og brødtekst), der formelt kaldes Internet Message Format .

Protokoloversigt

SMTP er en forbindelsesorienteret , tekstbaseret protokol , hvor en mailsender kommunikerer med en mailmodtager ved at udstede kommandostrenge og levere nødvendige data via en pålidelig ordnet datastrømskanal, typisk en TCP-forbindelse ( Transmission Control Protocol ). En SMTP -session består af kommandoer, der stammer fra en SMTP -klient ( startagenten , afsenderen eller senderen) og tilsvarende svar fra SMTP -serveren (lytteragenten eller modtageren), så sessionen åbnes, og sessionsparametre udveksles. En session kan indeholde nul eller flere SMTP -transaktioner. En SMTP -transaktion består af tre kommando-/svar -sekvenser:

  1. MAIL- kommando, for at etablere returadressen, også kaldet retursti, omvendt sti, bounce-adresse , mfrom eller konvolutafsender.
  2. RCPT -kommando, for at etablere en modtager af meddelelsen. Denne kommando kan udstedes flere gange, en for hver modtager. Disse adresser er også en del af konvolutten.
  3. DATA for at signalere begyndelsen på meddelelsesteksten ; meddelelsens indhold i modsætning til dens kuvert. Den består af et beskedoverskrift og et meddelelseslegeme adskilt af en tom linje. DATA er faktisk en gruppe af kommandoer, og serveren svarer to gange: én gang til selve DATA-kommandoen for at anerkende, at den er klar til at modtage teksten, og anden gang efter end-of-data-sekvensen for enten at acceptere eller afvise hele beskeden.

Udover mellemsvaret for DATA kan hver servers svar enten være positivt (2xx svarkoder) eller negativt. Negative svar kan være permanente (5xx -koder) eller forbigående (4xx -koder). En afvisning er en permanent fejl, og klienten skal sende en bounce -meddelelse til den server, den har modtaget den fra. Et fald er et positivt svar efterfulgt af kassering af beskeder frem for levering.

Den initierende vært, SMTP-klient, kan være enten en slutbrugers e-mail klient , funktionelt identificeres som et postbruger middel (MUA), eller et relæ servers mail transfer agent (MTA), der er en SMTP-server, der fungerer som en SMTP klient i den relevante session for at videresende mail. Fuldt kompatible SMTP -servere opretholder køer af meddelelser til genforsøg af meddelelsestransmissioner, der resulterede i forbigående fejl.

En MUA kender SMTP -serveren til udgående mail fra dens konfiguration. En relæserver bestemmer typisk, hvilken server der skal oprettes forbindelse til, ved at slå op på MX (Mail eXchange) DNS -ressource -posten for hver modtagers domænenavn . Hvis der ikke findes en MX -post, søger en konform relaying -server (ikke alle) i stedet A -posten . Relayservere kan også konfigureres til at bruge en smart vært . En relæserver starter en TCP- forbindelse til serveren på den " velkendte port " til SMTP: port 25 eller til tilslutning til en MSA, port 587. Hovedforskellen mellem en MTA og en MSA er, at forbindelse til en MSA kræver SMTP -godkendelse .

SMTP vs mailhentning

SMTP er kun en leveringsprotokol. Ved normal brug "skubbes" mail til en destinationsmail-server (eller næste-hop-mail-server), når den ankommer. Mail dirigeres baseret på destinationsserveren, ikke de enkelte bruger (e), som den er adresseret til. Andre protokoller, såsom Post Office Protocol (POP) og Internet Message Access Protocol (IMAP), er specielt designet til brug for individuelle brugere, der henter beskeder og administrerer postkasser . For at tillade, at en intermitterende tilsluttet mailserver kan hente beskeder fra en fjernserver på forespørgsel, har SMTP en funktion til at starte behandling af e-mailkø på en fjernserver (se Fjernmeddelelseskø starter nedenfor). POP og IMAP er uegnede protokoller til videresendelse af post via periodisk tilsluttede maskiner; de er designet til at fungere efter den endelige levering, når oplysninger, der er kritiske for den korrekte funktion af mailrelæ ("postkuvert") er blevet fjernet.

Fjernmeddelelseskø starter

Remote Message Queue Start gør det muligt for en ekstern vært at starte behandlingen af ​​mailkøen på en server, så den kan modtage beskeder bestemt til den ved at sende en tilsvarende kommando. Den oprindelige TURNkommando blev anset for usikker og blev udvidet i RFC  1985 med ETRNkommandoen, der fungerer mere sikkert ved hjælp af en godkendelsesmetode baseret på oplysninger om domænenavnssystem .

Udgående mail SMTP -server

En e -mail -klient skal kende IP -adressen til den oprindelige SMTP -server, og denne skal angives som en del af dens konfiguration (normalt angivet som et DNS -navn). Denne server leverer udgående meddelelser på brugerens vegne.

Adgangsbegrænsninger til udgående mailserver

Serveradministratorer skal pålægge en vis kontrol over, hvilke klienter der kan bruge serveren. Dette gør dem i stand til at håndtere misbrug, f.eks. Spam . To løsninger har været almindeligt anvendt:

  • I fortiden, mange systemer indførte begrænsninger i anvendelsen af placering af klienten, kun tillader brug af kunder, hvis IP-adresse er en, den server administratorer kontrol. Brug fra enhver anden klients IP -adresse er ikke tilladt.
  • Moderne SMTP -servere tilbyder typisk et alternativt system, der kræver godkendelse af klienter med legitimationsoplysninger, før de giver adgang.

Begrænsning af adgang efter sted

Under dette system tillader en internetudbyders SMTP -server ikke adgang for brugere, der er uden for internetudbyderens netværk. Mere præcist tillader serveren muligvis kun adgang til brugere med en IP -adresse leveret af internetudbyderen, hvilket svarer til at kræve, at de er forbundet til internettet ved hjælp af den samme internetudbyder. En mobilbruger er ofte på et andet netværk end det, der er hos deres normale internetudbyder, og finder derefter, at afsendelse af e -mail mislykkes, fordi det konfigurerede SMTP -servervalg ikke længere er tilgængeligt.

Dette system har flere variationer. For eksempel kan en organisations SMTP -server kun levere service til brugere på det samme netværk og håndhæve dette ved at firewall blokere adgang for brugere på det bredere internet. Eller serveren kan udføre områdekontrol af klientens IP -adresse. Disse metoder blev typisk brugt af virksomheder og institutioner som f.eks. Universiteter, der kun leverede en SMTP -server til udgående mail til brug internt i organisationen. Imidlertid bruger de fleste af disse organer nu klientgodkendelsesmetoder, som beskrevet nedenfor.

Hvor en bruger er mobil og kan bruge forskellige internetudbydere til at oprette forbindelse til internettet, er denne form for brugsbegrænsning besværlig, og det er upraktisk at ændre den konfigurerede udgående e -mail -SMTP -serveradresse. Det er yderst ønskeligt at kunne bruge e -mail -klientkonfigurationsoplysninger, der ikke skal ændres.

Klientgodkendelse

Moderne SMTP -servere kræver typisk godkendelse af klienter ved hjælp af legitimationsoplysninger, før de tillader adgang, frem for at begrænse adgangen efter placering som beskrevet tidligere. Dette mere fleksible system er venligt over for mobilbrugere og giver dem mulighed for at have et fast valg af konfigureret udgående SMTP -server. SMTP -godkendelse , ofte forkortet SMTP AUTH, er en udvidelse af SMTP for at logge ind ved hjælp af en godkendelsesmekanisme.

Havne

Kommunikation mellem mailservere bruger generelt standard TCP -port 25, der er beregnet til SMTP.

Mail klienter dog generelt ikke bruge dette i stedet at bruge specifikke "indsendelse" porte. Mailtjenester accepterer generelt indsendelse af e -mail fra klienter på en af:

Port 2525 og andre kan blive brugt af nogle individuelle udbydere, men har aldrig været officielt understøttet.

Mange internetudbydere blokerer nu al udgående port 25 -trafik fra deres kunder. Hovedsageligt som en anti-spam-foranstaltning, men også for at helbrede de højere omkostninger, de har, når de lader den stå åben, måske ved at opkræve mere af de få kunder, der kræver, at den er åben.

Eksempel på SMTP -transport

Et typisk eksempel på at sende en besked via SMTP til to postkasser ( alice og theboss ) placeret i det samme maildomæne ( eksempel.com ) gengives i den følgende sessionsudveksling. (I dette eksempel er samtaledelene præfikseret med S: og C: for henholdsvis server og klient . Disse etiketter er ikke en del af udvekslingen.)

Efter at beskedafsenderen (SMTP -klient) etablerer en pålidelig kommunikationskanal til meddelelsesmodtageren (SMTP -server), åbnes sessionen med en hilsen fra serveren, der normalt indeholder sit fuldt kvalificerede domænenavn (FQDN), i dette tilfælde smtp.example .com . Klienten starter sin dialog ved at reagere med en HELOkommando, der identificerer sig i kommandoens parameter med dens FQDN (eller en adresse bogstavelig, hvis ingen er tilgængelig). 

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}

Klienten underretter modtageren om meddelelsens oprindelige e -mail -adresse i en MAIL FROMkommando. Dette er også retur- eller afvisningsadressen , hvis meddelelsen ikke kan leveres. I dette eksempel sendes e -mail -meddelelsen til to postkasser på den samme SMTP -server: en for hver modtager, der er angivet i felterne To:og og Cc:header. Den tilsvarende SMTP -kommando er RCPT TO. Hver vellykket modtagelse og udførelse af en kommando bekræftes af serveren med en resultatkode og svarbesked (f.eks. 250 Ok).

Overførslen af ​​mailbeskedens brødtekst initieres med en DATAkommando, hvorefter den transmitteres ordret linie for linje og afsluttes med en afslutning af datasekvens. Denne sekvens består af en ny-linje ( <CR><LF>), en enkelt punktum ( .), efterfulgt af en anden ny-linje ( <CR><LF>). Da et meddelelsestekst kan indeholde en linje med kun en periode som en del af teksten, sender klienten to perioder hver gang en linje starter med en periode; tilsvarende erstatter serveren hver sekvens af to perioder i begyndelsen af ​​en linje med en enkelt. Sådan undslippe metode kaldes dot-stuffing .

Serverens positive svar på end-of-data, som eksemplificeret, indebærer, at serveren har taget ansvaret for at levere beskeden. En meddelelse kan fordobles, hvis der er et kommunikationsfejl på dette tidspunkt, f.eks. På grund af strømforsyning: Indtil afsenderen har modtaget dette 250 Oksvar, må den antage, at meddelelsen ikke blev leveret. På den anden side, efter at modtageren har besluttet at acceptere meddelelsen, må den antage, at meddelelsen er blevet leveret til den. I løbet af dette tidsrum har begge agenter således aktive kopier af beskeden, som de vil forsøge at levere. Sandsynligheden for, at der opstår en kommunikationsfejl nøjagtigt på dette trin, er direkte proportional med mængden af ​​filtrering, som serveren udfører på meddelelsesteksten, oftest til anti-spam-formål. Den begrænsende timeout er angivet til 10 minutter.

Den QUITkommando afslutter sessionen. Hvis e -mailen har andre modtagere placeret andre steder, ville klienten QUITog oprette forbindelse til en passende SMTP -server til efterfølgende modtagere, efter at den eller de aktuelle destinationer havde stået i kø. De oplysninger, som kunden sender i HELOog MAIL FROMder tilsættes kommandoer (ikke set i eksempel kode) som ekstra header felter til meddelelsen af den modtagende server. Det tilføjer henholdsvis et Receivedog Return-Pathheaderfelt.

Nogle klienter implementeres for at lukke forbindelsen, efter at meddelelsen er accepteret ( 250 Ok: queued as 12345), så de sidste to linjer kan faktisk udelades. Dette forårsager en fejl på serveren, når du prøver at sende 221 Byesvaret.

SMTP -udvidelser

Udvidelsesopdagelsesmekanisme

Kunder lærer en server understøttede muligheder ved at bruge EHLOhilsenen, som eksemplet herunder, i stedet for originalen HELO. Klienter falder kun tilbage HELO, hvis serveren ikke understøtter EHLOhilsen.

Moderne klienter kan bruge ESMTP -udvidelsesnøgleordet SIZEtil at forespørge serveren om den maksimale meddelelsesstørrelse, der accepteres. Ældre klienter og servere kan forsøge at overføre meddelelser i for stor størrelse, der vil blive afvist efter at have brugt netværksressourcer, herunder forbinde tid til netværkslinks, der betales i minuttet.

Brugere kan manuelt på forhånd bestemme den maksimale størrelse, der accepteres af ESMTP -servere. Klienten erstatter HELOkommandoen med EHLOkommandoen. 

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

Således erklærer smtp2.example.com , at det kan acceptere en fast maksimal meddelelsesstørrelse, der ikke er større end 14.680.064 oktetter (8-bit bytes).

I det enkleste tilfælde erklærer en ESMTP -server et maksimum SIZEumiddelbart efter modtagelse af en EHLO. Ifølge RFC  1870 er den numeriske parameter til SIZEudvidelsen i EHLOsvaret imidlertid valgfri. Kunder kan i stedet, når de udsender en MAIL FROMkommando, inkludere et numerisk skøn over størrelsen af ​​den besked, de overfører, så serveren kan nægte modtagelse af alt for store meddelelser.

Binær dataoverførsel

Original SMTP understøtter kun et enkelt brødtekst ASCII -tekst, derfor skal alle binære data kodes som tekst i meddelelsens brødtekst før overførsel og derefter afkodes af modtageren. Binary-til-tekst kodninger , såsom uuencode og BinHex blev typisk brugt.

8BITMIME -kommandoen blev udviklet til at løse dette. Det blev standardiseret i 1994 som RFC  1652 Det letter gennemsigtig udveksling af e-mail- meddelelser, der indeholder oktetter uden for det syv-bit ASCII- tegnsæt ved at kode dem som MIME- indholdsdele, typisk kodet med Base64 .

Mailudførelsesmekanismeudvidelser

On-Demand Mail Relæ

Hovedartikel: On-Demand Mail Relay

On-Demand Mail Relay ( ODMR ) er en SMTP-udvidelse standardiseret i RFC  2645, der tillader en intermitterende tilsluttet SMTP-server at modtage e-mail i kø for den, når den er tilsluttet.

Internationalisering udvidelse

Hovedartikel: International e -mail

Original SMTP understøtter kun e -mail -adresser, der består af ASCII -tegn, hvilket er ubelejligt for brugere, hvis native script ikke er latinbaseret, eller som bruger diakritisk ikke i ASCII -tegnsættet. Denne begrænsning blev lettet via udvidelser, der muliggjorde UTF-8 i adressenavne. RFC  5336 introducerede eksperimentel UTF8SMTPkommando og blev senere afløst af RFC  6531, der introducerede SMTPUTF8kommando. Disse udvidelser understøtter multi-byte og ikke-ASCII-tegn i e-mail-adresser, f.eks. Dem med diakritik og andre sprogtegn som f.eks. Græsk og kinesisk .

Den nuværende support er begrænset, men der er stor interesse for bred vedtagelse af RFC  6531 og de tilhørende RFC'er i lande som Kina, der har en stor brugerbase, hvor Latin (ASCII) er et fremmed skrift.

Udvidelser

Ligesom SMTP er ESMTP en protokol, der bruges til at transportere internetpost. Det bruges både som en transportserver mellem servere og (med begrænset adfærd håndhævet) som en mail-indsendelsesprotokol.

Den vigtigste identifikationsfunktion for ESMTP -klienter er at åbne en transmission med kommandoen EHLO(Extended HELLO), frem for HELO(Hej, den originale RFC  821 -standard). En server reagerer med succes (kode 250), fejl (kode 550) eller fejl (kode 500, 501, 502, 504 eller 421), afhængigt af dens konfiguration. En ESMTP-server returnerer koden 250 OK i et svar med flere linjer med sit domæne og en liste over søgeord for at angive understøttede udvidelser. En RFC 821 -kompatibel server returnerer fejlkode 500, så ESMTP -klienter kan prøve enten HELOeller QUIT.

Hver serviceudvidelse 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 valgfrie ydelser: SEND, SOML(Send eller mail), SAML(Send og Mail), EXPN, HELP, og TURN. Formatet for yderligere SMTP -verber blev indstillet og for nye parametre i MAILog RCPT.

Nogle relativt almindelige søgeord (ikke alle svarende til kommandoer), der bruges i dag, er:

ESMTP -formatet blev omarbejdet i RFC  2821 (erstatter RFC 821) og opdateret til den nyeste definition i RFC  5321 i 2008. Understøttelse af EHLOkommandoen i servere blev obligatorisk og HELOudpegede et påkrævet tilbagefald.

Ikke-standardiserede, uregistrerede serviceudvidelser kan bruges ved bilateral aftale, disse tjenester er angivet med et EHLOmeddelelsesnøgleord, der starter med "X", og med eventuelle yderligere parametre eller verber på samme måde markeret.

SMTP-kommandoer er store og små bogstaver. De præsenteres her i store bogstaver for kun at understrege. En SMTP -server, der kræver en bestemt kapitaliseringsmetode, er en overtrædelse af standarden.

8 BITTID

Mindst følgende servere annoncerer udvidelsen 8BITMIME:

Følgende servere kan konfigureres til at annoncere 8BITMIME, men udfører ikke konvertering af 8-bit data til 7-bit ved tilslutning til ikke-8BITMIME relæer:

  • Exim og qmail oversætter ikke otte-bit beskeder til syv-bit, når der gøres et forsøg på at videresende 8-bit data til ikke-8BITMIME jævnaldrende, som krævet af RFC. Dette giver ikke problemer i praksis, da stort set alle moderne mailrelæer er 8-bit rene .
  • Microsoft Exchange Server 2003 annoncerer 8BITMIME som standard, men videresendelse til en peer, der ikke er 8BITMIME, resulterer i en bounce. Dette er tilladt af RFC 6152 afsnit 3 .

SMTP-AUTH

Hovedartikel: SMTP -godkendelse

SMTP-AUTH-udvidelsen giver en adgangskontrolmekanisme. Det består af et godkendelsestrin, hvorigennem klienten effektivt logger ind på mailserveren under processen med at sende mail. Servere, der understøtter SMTP-AUTH, kan normalt konfigureres til at kræve, at klienter bruger denne udvidelse, hvilket sikrer, at afsenderens sande identitet kendes. SMTP-AUTH-udvidelsen er defineret i RFC  4954 .

SMTP-AUTH kan bruges til at give legitime brugere mulighed for at videresende mail, mens nægtet videresendelsestjeneste til uautoriserede brugere, f.eks. Spammere . Det garanterer ikke nødvendigvis ægtheden af ​​hverken SMTP -konvolutafsenderen eller RFC  2822 "From:" -hovedet. F.eks. Er spoofing , hvor en afsender udgør sig som en anden, stadig muligt med SMTP-AUTH, medmindre serveren er konfigureret til at begrænse besked fra-adresser til adresser, som denne AUTH-bruger er godkendt til.

SMTP-AUTH-udvidelsen gør det også muligt for en mailserver at angive for en anden, at afsenderen er blevet godkendt ved videresendelse af mail. Generelt kræver dette, at modtagerserveren har tillid til den afsendende server, hvilket betyder, at dette aspekt af SMTP-AUTH sjældent bruges på Internettet.

SMTPUTF8

Understøttende servere omfatter:

Sikkerhedsudvidelser

Maillevering kan forekomme både over almindelig tekst og krypterede forbindelser, men de kommunikerende parter ved muligvis ikke på forhånd om andres mulighed for at bruge sikker kanal.

STARTTLS eller "Opportunistisk TLS"

Hovedartikler: Opportunistisk TLS og e -mail -kryptering

STARTTLS -udvidelserne gør det muligt for understøttende SMTP -servere at underrette forbindelsesklienter om, at den understøtter TLS -krypteret kommunikation og giver klienter mulighed for at opgradere deres forbindelse ved at sende STARTTLS -kommandoen. Servere, der understøtter udvidelsen, får ikke i sig selv nogen sikkerhedsmæssige fordele ved implementeringen alene, da opgradering til en TLS -krypteret session er afhængig af, at den tilsluttende klient beslutter at udøve denne mulighed, derfor udtrykket opportunistisk TLS .

STARTTLS er kun effektiv mod passive observationsangreb, da STARTTLS -forhandlingen sker i ren tekst, og en aktiv angriber trivielt kan fjerne STARTTLS -kommandoer. Denne type mand-i-midten-angreb kaldes undertiden STRIPTLS , hvor krypteringsforhandlingsoplysningerne, der sendes fra den ene ende, aldrig når den anden. I dette scenario tager begge parter de ugyldige eller uventede svar som en indikation på, at den anden ikke korrekt understøtter STARTTLS, som standard til traditionel almindelig tekstoverførsel. Bemærk, at STARTTLS også er defineret for IMAP og POP3 i andre RFC'er, men disse protokoller tjener forskellige formål: SMTP bruges til kommunikation mellem meddelelsesoverførselsagenter, mens IMAP og POP3 er for slutklienter og meddelelsesoverførselsagenter.

Electronic Frontier Foundation opretholder en "STARTTLS Everywhere" -liste, der på samme måde som " HTTPS Everywhere " -listen tillader afhængige parter at opdage andre, der understøtter sikker kommunikation uden forudgående kommunikation.

RFC  8314 erklærede officielt ren tekst forældet og anbefaler altid at bruge TLS, tilføjelse af porte med implicit TLS.

SMTP MTA Streng transportsikkerhed

En nyere 2018 RFC  8461 kaldet "SMTP MTA Strict Transport Security (MTA-STS)" har til formål at løse problemet med aktiv modstander ved at definere en protokol for mailservere til at erklære deres evne til at bruge sikre kanaler i bestemte filer på serveren og specifik DNS TXT -registreringer. Den afhængige part ville regelmæssigt kontrollere eksistensen af ​​en sådan post og cache den i det tidsrum, der er angivet i posten, og aldrig kommunikere over usikre kanaler, før rekorden udløber. Bemærk, at MTA-STS-registreringer kun gælder for SMTP-trafik mellem mailservere, mens kommunikation mellem en brugers klient og mailserveren er beskyttet af Transport Layer Security med SMTP/MSA, IMAP, POP3 eller HTTPS i kombination med en organisatorisk eller teknisk politik. Grundlæggende er MTA-STS et middel til at udvide en sådan politik til tredjemand.

I april 2019 annoncerede Google Mail support til MTA-STS.

SMTP TLS -rapportering

En række protokoller tillader sikker levering af meddelelser, men de kan mislykkes på grund af fejlkonfigurationer eller bevidst aktiv interferens, hvilket kan føre til ikke -leverede meddelelser eller levering via ukrypterede eller uautentificerede kanaler. RFC  8460 "SMTP TLS Reporting" beskriver en rapporteringsmekanisme og et format til deling af statistik og specifikke oplysninger om potentielle fejl med modtagerdomæner. Modtagerdomæner kan derefter bruge disse oplysninger til både at opdage potentielle angreb og diagnosticere utilsigtede fejlkonfigurationer.

I april 2019 annoncerede Google Mail support til SMTP TLS -rapportering.

Spoofing og spam

Hovedartikler: Anti-spam-teknikker og e-mail-godkendelse

Det originale design af SMTP havde ingen mulighed for at godkende afsendere eller kontrollere, at servere havde tilladelse til at sende på deres vegne, med det resultat, at e -mail -forfalskning er mulig og almindeligt anvendt i spam og phishing via e -mail .

Lejlighedsvis fremsættes forslag om at ændre SMTP omfattende eller erstatte den fuldstændigt. Et eksempel på dette er Internet Mail 2000 , men hverken den eller nogen anden har gjort store fremskridt i lyset af netværkseffekten af den enorme installerede base af klassisk SMTP.

I stedet anvender mailservere nu en række teknikker, såsom strengere håndhævelse af standarder som RFC  5322 , DomainKeys Identified Mail , Sender Policy Framework og DMARC , DNSBL'er og greylisting til at afvise eller karantæne mistænkelige e -mails .

Implementeringer

Der er også SMTP -proxyimplementering som f.eks. Nginx .

Hovedartikler: Liste over mailserversoftware og sammenligning af mailservere

Relaterede anmodninger om kommentarer

  • RFC  1123 - Krav til internetværter - applikation og support (STD 3)
  • RFC  1870 - SMTP -serviceudvidelse til meddelelse om størrelsesdeklaration (оsoletes: RFC  1653 )
  • RFC  2505 -Anbefalinger til spam mod SMTP MTA'er (BCP 30)
  • RFC  2821 - Simple Mail Transfer Protocol
  • RFC  2920 - SMTP Service Extension til Command Pipelining (STD 60)
  • RFC  3030 - SMTP -serviceudvidelser til transmission af store og binære MIME -beskeder
  • RFC  3207 - SMTP Service Extension til Secure SMTP over Transport Layer Security (forældet RFC  2487 )
  • RFC  3461 - SMTP -serviceudvidelse til meddelelser om leveringsstatus (forældede RFC  1891 )
  • RFC  3463 - Forbedrede statuskoder til SMTP (forældede RFC  1893 , opdateret af RFC  5248 )
  • RFC  3464 - Et udvideligt meddelelsesformat til meddelelser om leveringsstatus (forældede RFC  1894 )
  • RFC  3798 - Meddelelse Disposition Notification (opdateringer RFC  3461 )
  • RFC  3834 - Anbefalinger til automatiske svar på elektronisk post
  • RFC  3974 - SMTP Operationel erfaring i blandede IPv4/v6 -miljøer
  • RFC  4952 - Oversigt og rammer for internationaliseret e -mail (opdateret af RFC  5336 )
  • RFC  4954 - SMTP Service Extension til godkendelse (forældede RFC  2554 , opdateringer RFC  3463 , opdateret af RFC  5248 )
  • RFC  5068 - Operationer til indsendelse af e -mails: Krav til adgang og ansvarlighed (BCP 134)
  • RFC  5248 - Et register for SMTP -forbedrede mailsystemstatuskoder (BCP 138) (opdateringer RFC  3463 )
  • RFC  5321 - Simple Mail Transfer Protocol (forældede RFC  821 aka STD 10, RFC  974 , RFC  1869 , RFC  2821 , opdateringer RFC  1123 )
  • RFC  5322 - Internetmeddelelsesformat (forældede RFC  822 aka STD 11 og RFC  2822 )
  • RFC  5504 - Nedgraderingsmekanisme til internationalisering af e -mailadresser
  • RFC  6409 - Beskedindberetning til mail (STD 72) (forældede RFC  4409 , RFC  2476 )
  • RFC  6522 - Multipart/rapportindholdstypen til rapportering af administrative systemmeddelelser i mailsystem (forældet RFC  3462 , og til gengæld RFC  1892 )
  • RFC  6531 - SMTP -udvidelse til internationaliserede e -mail -adresser (opdateringer RFC  2821 , RFC  2822 , RFC  4952 og RFC  5336 )
  • RFC  8314 - Cleartext betragtes som forældet: Brug af Transport Layer Security (TLS) til indsendelse og adgang til e -mail

Se også

Noter

Referencer

eksterne links