Protokoll for enkel postoverføring

Enkel e-postoverføringsprotokoll
Familie Internett-protokollfamilie
Funksjon Sender e -postmeldinger
havner 25/TCP
587/TCP (alternativ for e-postklienter)
465/TCP (SMTPS)
Plassering i protokollstabelen
App SMTP
Transport TCP
Nett IP ( IPv4 og IPv6 )
standarder
RFC 821 ( 1982 )
RFC 2821 ( 2001 )
RFC 5321 ( 2008 )

Simple Mail Transfer Protocol ( SMTP ) er en nettverksprotokoll som brukes til å utveksle e-postmeldinger mellom datamaskiner eller andre enheter (PDAer, mobiltelefoner, skrivere, etc.) . Det er med andre ord en Internett-tilkoblingsprotokoll. Det finnes i applikasjonslaget til OSI-modellen [ 1 ] , det siste laget i denne modellen som gir grensesnittet mellom kommunikasjonsapplikasjonene og nettverket som overfører meldingene [ 2 ] . Det ble opprinnelig definert i august 1982 av RFC 821 (for overføring) og RFC 822 (for melding). Dette var to offisielle Internett-standarder som henholdsvis ble erstattet av RFC 2821 og RFC 2822 , som igjen ble erstattet av RFC 5321 og RFC 5322 standarder . [ 3 ]

Driften av denne protokollen skjer online, slik at den fungerer i e-posttjenester. Denne protokollen har imidlertid noen begrensninger når det gjelder mottak av meldinger på destinasjonsserveren (kø av mottatte meldinger). Som et alternativ til denne begrensningen, utføres denne protokollen normalt i forhold til andre, for eksempel POP eller IMAP, og gir SMTP den spesifikke oppgaven å sende og motta post ved å bruke de andre protokollene nevnt ovenfor (POP eller IMAP).

Historikk

I 1982 ble det første SMTP-baserte systemet for utveksling av e-post på ARPANET designet , definert i RFC 821 og RFC 822 forespørsel om kommentarer . Den første av dem definerer denne protokollen og den andre formen for meldingen som denne protokollen skal transportere.

Strukturen til SMTP er basert på klient-server- modellen , der en klient sender en melding til en eller flere servere for å motta et svar. Kommunikasjon mellom klient og server består utelukkende av tekstlinjer som består av Unicode -tegn , selv om den opprinnelig var sammensatt av ASCII- tegn . Maksimal størrelse tillatt for disse linjene er 1000 tegn.

Serversvar består av en tresifret numerisk kode, etterfulgt av forklarende tekst. Nummeret er rettet mot en automatisk behandling av responsen med automat, mens teksten lar et menneske tolke responsen.

I SMTP-protokollen er alle kommandoer, svar eller data linjer med tekst, de er avgrenset med tegnet < CRLF >. Alle replikaer har en numerisk kode på begynnelsen av den sentrale linjen.

E-postbehandlingsmodell

E-post sendes av en e-postklient (MUA, Mail User Agent ) til en e-postserver (MSA, Mail Submission Agent ) ved hjelp av SMTP over port 587. de tillater sending gjennom port 25. Derfra leverer MSA e-posten til sin postoverføring agent bedre kjent som MTA (Mail Transfer Agent, Mail Transfer Agent ) . Ved noen anledninger er disse to agentene forskjellige tilfeller, selv om det skal bemerkes at de kommer fra samme programvare som de ble lansert fra, bare at de presenterer forskjellige alternativer innenfor samme maskin.

Den lokale behandlingen som presenteres kan gjøres på en enkelt maskin eller deles mellom flere applikasjoner; i dette andre tilfellet kan de involverte prosessene dele filer; her brukes SMTP for meldingsoverføring internt, med hver av vertene konfigurert til å bruke følgende applikasjon som en grasiøs vert. For å oppnå plassering av målserveren, må forgrenings-MTA bruke domenenavnsystemet (DNS) for å utføre oppslag av den interne postutvekslingsposten kjent som MX-posten for mottakerdomenet (delen av adressen til høyre ). Det er på dette tidspunktet at den returnerte MX-posten inneholder navnet på målverten. [ referanse nødvendig ]

MTA blir deretter med på utvekslingsserveren som en SMTP-klient. Når MX godtar den innkommende meldingen, gir den den igjen til en postleveringsagent (MDA) for videre lokal postlevering. MDA, i tillegg til å levere meldinger, er også i stand til å lagre meldinger i et postboksformat, og mottak av e-post kan gjøres ved hjelp av mange datamaskiner. Det er to måter en MDA kan levere meldinger på: enten ved å sende dem direkte til lagring, eller ved å videresende dem over et nettverk ved hjelp av SMTP. Når e-posten er levert til den lokale e-postserveren, lagres den for batchhenting. Gjenopprettingen oppnås gjennom sluttbrukerapplikasjoner, kjent som e-postklienter, som bruker Internet Message Access Protocol (IMAP), denne protokollen som letter både tilgang til sending og håndtering av lagret e-post.

Porter

Serveradministratorer kan velge om klienter bruker TCP-port 25 (SMTP) eller port 587 (Submission) for å videresende utgående e-post til en første e-postserver. [ 4 ] Spesifikasjonene og mange servere støtter begge deler. Selv om noen servere støtter port 465 for sikker eldre SMTP i strid med spesifikasjonene, er det å foretrekke å bruke standardportene og standard SMTP-kommandoer i henhold til RFC 3207 , hvis en sikker sesjon mellom klient og server må brukes.

Noen servere er konfigurert til å avvise all videresending på port 25, men gyldige brukere som autentiserer på port 587 kan videresende e-post til enhver gyldig adresse. Noen Internett - leverandører avskjærer port 25, og omdirigerer trafikk til sin egen SMTP - server, uavhengig av destinasjonsadressen. Dette betyr at det ikke er mulig for brukerne dine å få tilgang til en SMTP-server utenfor Internett-leverandørens nettverk gjennom port 25.

Noen SMTP-servere støtter autentisert tilgang på en annen port enn 587 eller 25 for å tillate brukere å koble seg til dem selv om port 25 er blokkert, men 587 er standard og bredt støttet port for brukere å sende ny e-post. Microsoft Exchange Server 2013 SMTP kan lytte på portene 25, 587, 465, 475 og 2525, avhengig av serveren og om rollene er kombinert på en enkelt server. [ referanse nødvendig ] Portene 25 og 587 brukes til å gi klienttilkobling til transporttjenesten på frontenden av Client Access Server (CAS)-rollen. Portene 25, 465 og 475 brukes av Mailbox Transport-tjenesten. Men når postboksrollen kombineres med CAS-rollen på en enkelt server, brukes port 2525 av SMTP-postboksrollen fra CAS front-end transporttjeneste, mens CAS fortsetter å bruke port 25. Port 465 brukes av postkassen Transporttjeneste for å motta proxy-klientforbindelser fra CAS-rollen. Port 475 brukes av postkassefunksjonen til å kommunisere direkte med andre postkassefunksjoner, og overføre post mellom postkassetransportsendetjenesten og postkassetransportleveringstjenesten. [ 5 ]

SMTP. En SMTP-transaksjon består av tre kommando-/svarsekvenser (se eksempel nedenfor).

De er:

  • MAIL FROM : kommando for å angi returadressen, også kjent som returbane, avsender eller konvolutt. Dette er adressen for avskjedsmeldinger.
  • RCPT TO : kommando, for å angi en mottaker av denne meldingen. Denne kommandoen kan gis flere ganger, én gang for hver mottaker. Disse adressene er også en del av konvolutten.
  • DATA : for å sende tekstmeldingen. Dette er innholdet i meldingen, snarere enn konvolutten. Den består av en meldingshode og meldingsteksten atskilt med en tom linje. DATA er faktisk en gruppe kommandoer, og serveren svarer to ganger: én gang for riktig datakommando, for å bekrefte at den er klar til å motta teksten, og andre gang etter den endelige datastrømmen, for å godta eller avvise hele meldingen.

  • Når en klient oppretter en forbindelse med SMTP-serveren, venter den på at SMTP-serveren sender en melding "220-tjeneste klar" eller "421-tjeneste ikke tilgjengelig" .
  • Et HELO sendes fra klienten. Dette identifiserer serveren. Dette kan brukes til å sjekke om du koblet til riktig SMTP-server.
  • Klienten starter e-posttransaksjonen med kommandoen MAIL FROM . Som et argument for denne kommandoen, kan du sende e-postadressen som serveren vil varsle om feil ved å sende e-posten (for eksempel MAIL FROM:<kilde@vert0> ). Så hvis serveren sjekker at opprinnelsen er gyldig, svarer serveren "250 OK" .
  • Vi har allerede fortalt serveren at vi ønsker å sende en e-post, nå må vi fortelle hvem. Kommandoen for dette er RCPT TO:<destination@host> . Du kan sende så mange RCPT-bestillinger du vil for å motta posten. For hver mottaker vil serveren svare "250 OK" eller "550 Ingen slik bruker her" hvis mottakeren ikke blir funnet.
  • Etter at alle RCPT-er er sendt, sender klienten en DATA -kommando for å indikere at innholdet i meldingen sendes neste gang. Serveren svarer "354 Start e-postinndata, avslutt med <CRLF>.<CRLF>" Dette forteller klienten hvordan den skal varsle slutten av meldingen.
  • Nå sender klienten brødteksten i meldingen, linje for linje. Når den er ferdig, ender den med en <CRLF>.<CRLF> (siste linjen vil være et punktum), som serveren vil svare "250 OK" på , eller en passende feilmelding.
  • Etter sending vil klienten, hvis den ikke trenger å sende flere e-poster, med QUIT -kommandoen kutte forbindelsen. Du kan også bruke TURN -kommandoen , som gjør klienten til serveren, og serveren blir klienten. Til slutt, hvis den har flere meldinger å sende, gjentar den prosessen til den er fullført.

SMTP-serveren kan støtte utvidelsene definert i RFC 1651 , i dette tilfellet kan HELO-kommandoen erstattes av EHLO-kommandoen, slik at serveren vil svare med en liste over støttede utvidelser. Hvis serveren ikke støtter utvidelsene, vil den svare med en "500 Syntax error, command unrecognized" melding.

Kommandoer
  • HELO, for å åpne en økt med serveren
  • EHLO, for å åpne en økt, i tilfelle serveren støtter utvidelser definert i RFC 1651
  • MAIL FRA, for å angi hvem som sender meldingen
  • RCPT TIL, for å indikere mottakeren av meldingen
  • DATA, for å indikere begynnelsen av meldingen, vil den avsluttes når det er en linje med bare et punktum.
  • AVSLUTT, for å avslutte økten
  • RSET Avbryter gjeldende transaksjon og sletter alle poster.
  • SEND Starter en transaksjon der meldingen leveres til en terminal.
  • SOML Meldingen leveres til en terminal eller postkasse.
  • SAML Meldingen leveres til en terminal og en postkasse.
  • VRFY Ber serveren om å bekrefte et helt argument.
  • EXPN Ber serveren om bekreftelse av argumentet.
  • HELP Lar deg be om informasjon om en kommando.
  • NOOP Ikke si noe, den brukes til å holde økten åpen
  • TURN Ber serveren om å bytte roller.

Av de tre sifrene i den numeriske koden, indikerer den første kategorien for svaret, med følgende kategorier definert:

  • 2XX, er operasjonen som ble bedt om av den forrige kommandoen, fullført
  • 3XX, bestillingen er akseptert, men serveren venter på at klienten skal sende den nye data for å fullføre operasjonen
  • 4XX, for et feilsvar, men vent til instruksjonen gjentas
  • 5XX, for å indikere en permanent feiltilstand, så kommandoen bør ikke gjentas

Når serveren mottar meldingen som slutter med en prikk, kan den lagre den hvis den er for en mottaker som tilhører domenet , eller sende den på nytt til en annen server slik at den til slutt når en server i mottakerens domene.

Eksempel på en SMTP-kommunikasjon

Først må det opprettes en forbindelse mellom avsender (klient) og mottaker (server). Dette kan gjøres automatisk med et e-postklientprogram eller via en telnet -klient .

Følgende eksempel viser en typisk tilkobling. Den er navngitt med bokstaven C til klienten og med S til serveren.

S: 220 SMTP-server C: HELO mycomputer.mydomain.com S: 250 Hei, vær så snill å møte deg C: MAIL FRA: <[email protected]> S: 250 ok C: RCPT TIL: <[email protected]> S: 250 ok C:DATA S: 354 Avslutt data med <CR><LF>.<CR><LF> C: Emne: Emnefelt C: Fra: [email protected] C: Til: [email protected] C: Hallo. C: Dette er en test. C: Vi sees senere. C: C: . C: <CR><LF>.<CR><LF> S: 250 Ok: i kø som 12345 C: Avslutt S: 221 Ha det

Meldingsformat

Som vist i eksempelet ovenfor, sendes meldingen av klienten etter at den har sendt DATA-kommandoen til serveren. Meldingen består av to deler:

SMTP vs e-posthenting

Simple Mail Transfer Protocol (SMTP) er kun ansvarlig for å levere meldingen. Så snart de er mottatt, sendes meldingene til målpostserveren eller neste hop-postserver. E-post rutes basert på målserveren, ikke individuelle brukeradresser. Andre protokoller som Post Office Protocol (POP) og Internet Message Access Protocol (IMAP) er strukturert for individuelle brukere, meldingshenting, postboksadministrasjon. SMTP bruker en funksjon, behandlingen av e-postkøer på en ekstern server, lar en periodisk tilkoblet e-postserver sende meldinger fra en ekstern server. IMAP og POP er upassende protokoller for videresending av post fra periodisk tilkoblede maskiner, men er utformet for å fungere etter endelig levering.

Fjernstart av melding i kø

Det er en funksjon i SMTP som lar en ekstern vert starte e-postkøbehandling på serveren slik at den kan motta meldinger beregnet på den ved å sende TURN-kommandoen. Denne funksjonen anses som usikker, men bruk av ETRN-kommandoen i RFC 1985 -utvidelsen fungerer sikrere.

Mail On Demand Forwarding Request (ODMR)

On-Demand Mail Relay (ODMR) er en utvidelse til SMTP standardisert i RFC 2645 som gjør at e-post kan overføres til mottakeren etter at den er godkjent. Bruker ATRN Extended SMTP-kommandoen, tilgjengelig for dynamiske IP-adresser. Klienten utsteder EHLO- og ODMR-posttjenester AUTH-kommandoer, ODMR begynner å fungere som en SMTP-klient og begynner å sende alle meldinger adressert til en klient ved å bruke SMTP-protokollen, ved pålogging kan brannmuren eller serveren blokkere innkommende økt på grunn av dynamiske IP-er. Bare ODMR-serveren, tjenesteleverandøren, skal lytte etter SMTP-økter på en fast IP-adresse.

Internasjonalisering

Mange brukere hvis basisspråk ikke er latin, har hatt problemer med e-postkravet i Amerika. RFC 6531 ble opprettet for å løse dette problemet ved å tilby SMTPs internasjonaliseringsfunksjoner, SMTPUTF8-utvidelsen. RFC 6531 gir støtte for multibyte-tegn og ikke ASCII i e-postadresser. Internasjonaliseringsstøtten er for tiden begrenset, men det er stor interesse for å utvide RFC 6531 . RFC i land som Kina, som har en stor brukerbase i Amerika.

Utgående e-post med SMTP

En e-postklient må kjenne IP-adressen til den opprinnelige SMTP-serveren, og denne må oppgis som en del av konfigurasjonen (vanligvis gitt som et DNS- navn ). Denne serveren vil sende utgående meldinger på vegne av brukeren.

E-postservertilgang og utgangsbegrensning

I et servermiljø må administratorer ta kontrolltiltak der servere er tilgjengelige for klienter. Dette lar deg implementere sikkerhet mot mulige trusler. Tidligere påla de fleste systemer restriksjoner på bruk i henhold til plasseringen til klienten, bruken ble bare tillatt av de klientene hvis IP-adresse er en av de som kontrolleres av serveradministratorene. Moderne SMTP-servere kjennetegnes ved å tilby et alternativt system, som krever autentisering med legitimasjon fra klienter før de tillates tilgang.

Begrens tilgang etter plassering

Ved å bruke dette systemet vil ikke SMTP-serveren relatert til Internett -leverandøren tillate tilgang til brukere som er utenfor Internett-leverandørens nettverk. Nærmere bestemt kan serveren bare tillate tilgang til de brukerne hvis IP-adresse ble oppgitt av Internett-leverandøren, noe som tilsvarer å kreve at de er koblet til internett gjennom samme ISP. En mobilbruker er ofte på et annet nettverk enn Internett-leverandørens normale nettverk, og oppdager da at sending av e-post mislykkes fordi det konfigurerte SMTP-servervalget ikke lenger er tilgjengelig. Dette systemet har flere varianter, for eksempel kan organisasjonens SMTP-server kun yte tjenester til brukere på samme nettverk, dette håndheves av brannmurer for å blokkere generell brukertilgang over Internett. Eller tjenesten kan utføre tilgjengelighetskontroller på klientens IP-adresse. Disse metodene brukes vanligvis av selskaper og institusjoner som universiteter som tilbyr en SMTP-server for utgående post kun for intern bruk i organisasjonen. Imidlertid bruker de fleste av disse byråene nå klientautentiseringsmetoder, som beskrevet nedenfor. Ved å begrense tilgangen til visse IP-adresser kan serveradministratorer enkelt gjenkjenne IP-adressen til enhver angriper. Siden dette representerer en meningsfull adresse for dem, kan administratorer håndtere den mistenkelige maskinen eller brukeren. Når en bruker er mobil, og kan bruke forskjellige leverandører for å koble til internett, er denne typen bruksbegrensninger kostbare, og det er upraktisk å endre innstillingene knyttet til den utgående SMTP-serverens e-postadresse. Det er svært ønskelig å kunne bruke e-postklientkonfigurasjonsinformasjon som du ikke trenger å endre.

Sikkerhet og spam

En av begrensningene til den originale SMTP er at den ikke gir autentiseringsmetoder til avsendere, så SMTP-AUTH- utvidelsen ble definert i RFC 2554 .

Til tross for dette er spam fortsatt det største problemet. Utvidelser antas ikke å være en praktisk måte å forhindre det på. Internet Mail 2000 er et av forslagene for å erstatte den. [ referanse nødvendig ]

Ulike metoder har dukket opp for å bekjempe spam . Disse inkluderer DKIM , Sender Policy Framework (SPF) og siden 2012 domenebasert meldingsautentisering, rapportering og samsvar ( DMARC ). [ 6 ]

De tilknyttede RFC -ene

Se også

Referanser

  1. "Hva er SMTP? Definisjon og grunnleggende» . IONOS Digitalguide . Hentet 3. mars 2022 . 
  2. «OSI Layer 7 | Application Layer - The Bit Workshop» . 21. mars 2012 . Hentet 3. mars 2022 . 
  3. Offisielle Internett-protokollstandarder .
  4. Se RFC 6409 .
  5. "Meldingsprotokoller (SMTP, POP3 og IMAP4)" .  .
  6. ^ " I det første året beskytter DMARC 60 prosent av globale forbrukerpostkasser " . 6. februar 2013 . Hentet 26. februar 2014 . 

Eksterne lenker