Mail SMTP-porter - betydning, funksjoner og beskrivelse. De mest interessante tingene om SMTP, POP3 og IMAP
I dag vil vi fortelle deg i detalj om de mest brukte Internett-protokollene - POP3, IMAP og SMTP. Hver av disse protokollene har et bestemt formål og funksjonalitet. La oss prøve å finne ut av det.
POP3-protokollen og dens porter
Post Office Protocol 3 (POP3) er en standard postprotokoll designet for motta e-poster Med ekstern server e-postklient.POP3 lar deg lagre en e-postmelding på datamaskinen din og til og med lese den hvis du er frakoblet. Det er viktig å merke seg at hvis du bestemmer deg for å bruke POP3 for å koble til regnskap post, vil brev som allerede er lastet ned til datamaskinen din bli slettet fra e-postserveren. For eksempel hvis du bruker flere datamaskiner for å koble til én e-postkonto, så er kanskje ikke POP3 det beste valget i denne situasjonen. På den annen side, siden e-post lagres lokalt, på en spesifikk brukers PC, tillater dette optimalisering diskplass på e-postserversiden.
Som standard bruker POP3-protokollen følgende porter:
- Port 110 er standard POP3-port. Det er ikke trygt.
- Port 995 – Denne porten bør brukes hvis du ønsker å etablere en sikker tilkobling.
IMAP-protokoll og porter
Internet Message Access Protocol (IMAP) er en e-postprotokoll utviklet for å få tilgang til e-post fra en lokal e-postklient. IMAP og POP3 er de mest populære protokollene på Internett som brukes til mottar e-post. Begge disse protokollene støttes av alle moderne e-postklienter (MUA - Mail User Agent) og WEB-servere.
Mens POP3 tillater e-posttilgang fra bare ett program, tillater IMAP tilgang fra flere klienter. Av denne grunn er IMAP mest tilpasningsdyktig i tilfeller der flere brukere trenger tilgang til samme e-postkonto.
Som standard bruker IMAP-protokollen følgende porter:
- Port 143– standard port. Ikke trygt.
- Port 993– port for sikker tilkobling.
SMTP-protokollen og dens porter
Simple Mail Transfer Protocol (SMTP) er en standardprotokoll for sende e-postmeldinger via Internett.
Denne protokollen beskrevet i RFC 821 og RFC 822, først publisert i august 1982. Innenfor rammen av RFC-dataene må adresseformatet være i formatet brukernavn@domenenavn. Postlevering ligner arbeidet til en vanlig posttjeneste: for eksempel et brev til adressen [e-postbeskyttet], vil bli tolket som følger: ivan_ivanov er adressen, og merionet.ru er postnummer. Hvis Domenenavn mottakerens domenenavn er forskjellig fra avsenderens domenenavn, da vil MSA (Mail Submission Agent) sende brevet gjennom Mail Transfer Agent (MTA). Hovedideen til MTA er å omdirigere brev til en annen domenesone, lik hvordan tradisjonell post sender brev til en annen by eller region. En MTA mottar også post fra andre MTAer.
SMTP-protokollen bruker følgende porter.
SMTP(Simple Mail Transfer Protocol - enkel postoverføringsprotokoll) er nettverksprotokoll, designet for overføring av e-post over TCP/IP-nettverk. ESMTP(English Extended SMTP) - en skalerbar utvidelse av SMTP-protokollen. For øyeblikket refererer "SMTP-protokollen" vanligvis til ESMTP og dens utvidelser. SMTP bruker TCP-porter 25.
SMTP-protokollen bruker enkle ASCII-tekstkommandoer og returnerer tre-tegns kodede tekstmeldingssvar. SMTP-protokollen er beskrevet i Internet Request For Comment (RFC) nummer 821, som ble utviklet av Internet Engineering Task Force (IETF) og publisert 21. august 1982. Siden den gang har den gjennomgått flere modifikasjoner, men generelt har de grunnleggende kommandoene i protokollen ikke endret seg.
Grunnleggende SMTP-klientkommandoer
HELO Team
Per definisjon er SMTP-protokollkommandoer fire tegn lange. Hilsenen som sendes av klienten til serveren er HELO-kommandoen. Kommandoformatet er som følger:
HELO domenenavn
Hensikten med HELO-kommandoen er å presentere klienten for SMTP-serveren. Dessverre ble denne tilgangsmetoden utviklet i det første stadiet utvikling av Internett, da det ikke fantes noe slikt stort nummer forsøk på uautorisert inntreden datasystemer. Som du kan se, kan klienten kalle seg et hvilket som helst navn på kommandolinjen. Dette har ført til at de fleste SMTP-servere for tiden bruker denne kommandoen rent formelt. Hvis de prøver å identifisere klienten, aktiveres en omvendt DNS-oppslagsmekanisme for å bestemme klientens faktiske vertsnavn for domenenavnsystem fra IP-adressen. Vanligvis av sikkerhetsmessige årsaker SMTP-servere tilkobling nektes til verter hvis IP-adresse ikke løses til et tilsvarende vertsnavn. Sender denne kommandoen, varsler klienten serveren om at den ønsker å opprette en forbindelse med den. Ved å svare på denne kommandoen, varsler serveren på sin side at en ny forbindelse er opprettet med klienten og er klar til å akseptere påfølgende kommandoer fra den.
Når du arbeider med SMTP-protokollen, må du skille mellom SMTP-klienter. Klientbrukere og klientverter er ikke det samme. Når du oppretter en e-postmelding, er brukeren av e-postsystemet også en klient til sin lokale vert. Når e-postmeldingen er sendt, er den ikke lenger en klient for SMTP-prosessen. Nå utfører hans lokale vertsdatamaskin meldingsleveringsprosessen og fungerer selv som SMTP-klient. Når en lokal vert kobler til en ekstern vert for å overføre en melding ved hjelp av SMTP-protokollen, fungerer den som en klient for SMTP-prosessen. HELO-kommandoen annonserer navnet på den lokale verten som klienten, ikke den faktiske brukeren som sendte meldingen. Ganske ofte blir disse begrepene forvirret, noe som gjør det vanskelig å løse problemer som oppstår i e-postsystemer.
AUTH kommando
Å utvide en SMTP-samtale med AUTH-kommandoen er beskrevet i RFC 4954.
PLAIN (Bruker Base64-koding.)
LOGG PÅ (Bruker Base64-koding.)
GSSAPI (Generic Security Services Application Program Interface)
DIGEST-MD5 (Autentisering av Digest-tilgang)
Den eneste forskjellen mellom PLAIN og LOGIN er at i det første alternativet overføres pålogging + passord på én linje, og i det andre alternativet - først pålogging, deretter passord. Men alle av dem er nødvendigvis kodet i Base64.
MAIL kommando
MAIL-kommandoen brukes til å etablere en e-postøkt med serveren etter at HELO-kommandoen er sendt. Den indikerer hvem meldingen kommer fra. MAIL-kommandoformatet er som følger:
MAIL omvendt vei
Argumentet omvendt sti spesifiserer ikke bare avsenderen av meldingen, men spesifiserer også en rute som meldingen kan returneres gjennom hvis den ikke kan leveres. Hvis avsenderen er brukeren på klientdatamaskinen som startet SMTP-økten, vil kommandoformatet være som følger:
POST FRA: [e-postbeskyttet]
Merk at FROM-feltet spesifiserer e-postadressen til meldingsavsenderen, inkludert det fulle navnet på klientvertsdatamaskinen. Denne informasjonen må være til stede i FRA-feltet i e-postmeldingen (men mer om det senere). Hvis en e-postmelding gikk gjennom flere noder på vei fra avsender til mottaker, vil hver av dem legge til informasjon om seg selv i feltet
Team RCPT
RCPT-kommandoen spesifiserer mottakerne av en melding. Flere brukere kan motta samme melding. Vanligvis spesifiseres hver mottaker på en egen linje med RCPT-kommandoen. RCPT-kommandoformatet er som følger:
RCPT fremoverbane
Forover-sti-argumentet spesifiserer hvor e-posten videresendes. Vanligvis vil dette inkludere hele e-postadressen, men kan også inkludere det lokale SMTP-serverbrukernavnet. Tenk for eksempel på følgende kommando:
RCPT TIL: haley
Denne kommandoen spesifiserer at meldingen skal sendes til brukeren haley på SMTP-serveren som behandler meldingene. På samme måte kan du sende meldinger til brukere av andre datamaskiner som ikke er brukere av SMTP-serveren som meldingen sendes til. Tenk for eksempel på følgende kommando:
RCPT TIL: [e-postbeskyttet]
En kommando sendt til en SMTP-server kalt shardrach.smallorg.org tvinger serveren til å bestemme om meldingen skal leveres. Siden brukeren ikke er registrert på lokal server shardrach, så må serveren bestemme hva som skal gjøres med meldingen neste gang. I dette tilfellet er det tre mulige handlinger for shardrach-verten. La oss se nærmere på dem.
Shardrach-verten kan videresende meldingen til mottakeren og returnere et bekreftende svar til avsenderen (OK). I dette tilfellet legger han navnet sitt til feltet
Host shardrach kan ikke videresende meldingen og varsler avsenderen, samtidig som den bekrefter at vertsadressen meshach.smallorg.org er riktig. Så avsenderen kan prøve å sende meldingen på nytt direkte til meshach.smallorg.org.
Host shardrach kan ikke videresende meldingen og sender et varsel om at denne operasjonen ikke kan utføres med denne serveren. Deretter bør årsakene til det som skjedde analyseres av systemadministratoren.
I de tidlige dagene av Internett var praksisen å sende e-postmeldinger blindt mellom datamaskiner rundt om i verden som brukte den originale e-postmeldingsalgoritmen.
DATA kommando
Denne kommandoen er den viktigste i SMTP-protokollen. Etter å ha behandlet MAIL- og RCPT-kommandoene, brukes DATA-kommandoen til å overføre informasjonsdelen av meldingen. DATA-kommandoformatet er som følger:
Alt som følger denne kommandoen tolkes som en melding som skal overføres. SMTP-serveren legger vanligvis til meldingshodet med et tidsstempel og returbaneinformasjon. Klientprogrammet indikerer slutten av meldingen ved å sende en linje etterfulgt av en enkelt prikk. Formatet på denne linjen er som følger:
Etter å ha mottatt denne sekvensen, "forstår" SMTP-serveren at overføringen av meldingen er fullført og bør returnere en svarkode som vil varsle klienten om at meldingen har blitt akseptert.
SEND kommando
SEND-kommandoen brukes til å sende e-postmeldinger direkte til terminalen til den registrerte brukeren av systemet. Denne kommandoen utføres bare når brukeren er pålogget og er vanligvis en popup-melding, lik skrivekommandoen i UNIX. Denne kommandoen har en alvorlig ulempe: med sin hjelp kan en ekstern bruker enkelt finne ut hvem som for øyeblikket er logget på systemet. Denne "muligheten" har lenge vært aktivt utnyttet av hackere for å få Internett-bruker-IDer fra intetanende ofre som er logget på systemet. På grunn av sikkerhetshensyn inneholder de fleste SMTP-programvarepakker i dag ikke lenger denne kommandoen.
RSET kommando
RSET-kommandoen er en forkortelse for reset. Hvis klienten blir forvirret over svarene den mottar fra serveren, eller bestemmer seg for at tilkoblingen har gått tapt, kan den utstede en RSET-kommando og returnere økten til startpunktet - ved å utføre HELO-kommandoen. I dette tilfellet vil alle tidligere sendte kommandoer - MAIL, RCPT og DATA bli kansellert. Svært ofte brukes denne kommandoen som en " siste utvei" når klienten enten mistet kommandosekvensen eller mottok et uventet svar fra serveren.
VRFY
VRFY-kommandoen er en forkortelse for verify. Den kan brukes til å bestemme om en server kan levere e-post til en bestemt mottaker før RCPT-kommandoen utføres. Formatet på denne kommandoen er som følger:
VRFY brukernavn
Ved aksept av denne kommandoen avgjør SMTP-serveren om den har en bruker på den lokale serveren med fornavn. Hvis en slik bruker blir funnet, vil serveren returnere et svar med brukerens fullstendige e-postadresse. Hvis det ikke er en slik bruker på den lokale serveren, kan SMTP-serveren enten returnere et negativt svar til klienten eller indikere at den vil videresende alle meldinger til en ekstern bruker. Dette avhenger av om SMTP-serveren vil videresende meldinger til den eksterne klienten.
VRFY-kommandoen kan være effektivt verktøy ved feilsøking av e-postproblemer. Ganske ofte, når de sender e-postmeldinger, staver brukere destinasjonen eller vertsnavnet feil og lurer på hvorfor meldingene deres ikke ble mottatt. Det første de vil gjøre er selvfølgelig å klage til administratoren postsystemet til den motbydelige ytelsen til e-postsystemet. Som e-postsystemadministrator kan du sjekke funksjonaliteten til e-postadresser på to måter. Først ved å bruke DNS-vertskommandoen, som lar deg bestemme riktigheten av domenenavnet og tilstedeværelsen av en e-postserver som betjener domenet. Og for det andre kan du gå med bruker telnet til port 25 på e-postserveren og utfør deretter VRFY-kommandoen, som vil avgjøre om brukernavnet er riktig. Oppføring 5.3 viser et eksempel på bruk av VRFY-kommandoen for å validere brukernavn.
1 [riley@ shadrach riley] $ telnet localhost 25 2 Prøver 127.0.0.1... 3 Koblet til localhost. 4 Escape-tegnet er "^]" . 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/ 8.9.3; Thu, 26 Aug 1999 19:20:16 -050 6 HELO localhost 7 250 shadrach.smallorg.org Hei localhost [127.0.0.1], hyggelig å møte deg 8 VRFY rich 9 250< rich@ shadrach,smallorg.org>10 VRFY prez@ mechach.smallorg.org 11 252< prez@ mechach.smallorg.org>12 VRFY jessica 13 550 jessica... Bruker ukjent 14 AVSLUTT 15 221 shadrach.smallorg.org avsluttende forbindelse 16 Forbindelse stengt av -utenlandsk vert. 17 [riley@shadrach riley]$Linje 8-13 viser utdata fra VRFY-kommandoen. Linje 8 forsøker å utføre en VRFY på lokal bruker rik. SMTP-serversvaret på linje 9 bekrefter at en bruker med det navnet finnes i systemet, og klientens fullstendige e-postadresse returneres. Linje 10 viser et annet alternativ for å spesifisere VRFY-kommandoen. Her prøver klienten å gi en VRFY-kommando til en bruker på en ekstern datamaskin. Svaret mottatt på linje 11 fra shadrach-systemet er forskjellig fra resultatet mottatt på linje 9. Serverresponsseksjonen diskuterer betydningen av kodene som returneres av serveren mer detaljert. I vårt tilfelle, merk at shadrach-systemet varsler klienten om at e-post vil bli videresendt til brukerprez på den eksterne serveren meshach.smallorg.org. Linje 12 viser et forsøk på å sjekke et ikke-eksisterende navn i meshach-systemet. SMTP-serverens svar på linje 13 er selvforklarende.
Sjekk brukerens eksistens ved å bruke bash og curl. $ekko -e "VRFY [e-postbeskyttet]\nAVSLUTT"| curl telnet:// mail.example.com:25 220 mail.1-talk.com ESMTP Postfix 252 2.0.0 brukernavn@ example.com 221 2.0.0 Bye
NOOP Team
NOOP-kommandoen er en forkortelse for ingen operasjon. Denne kommandoen har ingen effekt på SMTP-serveren bortsett fra at serveren returnerer en positiv svarkode til den. Den brukes når du tester en tilkobling uten å videresende en melding.
AVSLUTT kommando
QUIT-kommandoen gjør akkurat det den sier, dvs. informerer SMTP-serveren om at klientdatamaskinen er ferdig denne timen og ønsker å stenge forbindelsen. SMTP-serveren må svare på denne kommandoen og deretter starte og lukke TCP-tilkoblingen. Hvis serveren aksepterer QUIT-kommandoen under overføring av e-post, må alle data som sendes under økten ødelegges og vil ikke nå mottakeren.
Meldingsformat (e-post)
Standard overskriftsfelt i henhold til RFC 822
RFC 822 krever at en melding deles i to deler. Den første delen kalles overskriften. Alle data som identifiserer meldingen legges inn i den. Den andre delen kalles brødteksten i meldingen. Overskriften består av datafelter som brukes ettersom tilleggsinformasjon er nødvendig i meldingen. Overskriftsfelt og meldingstekst må skilles tom linje. Det er ingen spesifikk rekkefølge for overskriftsfelt, dvs. Overskriftsfeltene kan plasseres i hvilken som helst rekkefølge. I tillegg kan overskriftsfelt gjentas i samme melding. Figuren viser generell form e-postmelding som oppfyller kravene i RFC 822.
Meldingsformat i henhold til RFC 822
Mottatt overskriftsfelt
Formatet for Mottatt:-overskriftsfelt er som følger:
Mottatt: fra vertsnavn etter vertsnavn via fysisk bane med protokoll-ID meldings-id for endelig e-postdestinasjon
Mottatt overskrift-feltet brukes til å identifisere SMTP-serverne som var involvert i prosessen med å levere meldingen fra avsender til mottaker. Hver server legger til sitt eget Mottatt-felt i e-postmeldingen, og indikerer spesifikk informasjon om seg selv. Underfeltene i Mottatt-feltet indikerer banen, protokollen og datamaskinene som deltok i overføringen av meldingen.
Overskriftsfelt for returbane
Formatet til dette overskriftsfeltet er som følger:
Retursti: rute
Den siste SMTP-serveren i videresendingskjeden legger til et returbanefelt i meldingen. Hensikten er å bestemme ruten som meldingen nådde mottakeren gjennom. Hvis meldingen ble sendt direkte til mottakerens server, vil kun én adresse vises i dette feltet. Ellers vises den her full liste servere som meldingen gikk gjennom for å nå mottakeren. Kan avvike fra MAIL FRA (det vil si at returadressen kan spesifiseres forskjellig fra avsenderens adresse).
Opphavsmannens overskriftsfelt
Opphavsmann-feltet angir adressen til meldingsavsenderen. Denne informasjonen er svært nyttig i situasjoner der meldinger har blitt avvist flere ganger av private nettverk før de når Internett. Formatet på dette feltet er som følger:
Svar til: adresse
Opphavsmannen-feltet er bare et lite hjelpefelt i de flerfargede overskriftsfeltene. Den kan brukes som en mer den enkle måten for små SMTP-pakker. Dette eliminerer behovet for mer komplekse overskriftsfelt som identifiserer avsenderen.
Send overskriftsfelt på nytt
Resent header-feltet identifiserer en e-postmelding som av en eller annen grunn måtte sendes på nytt av klienten. Formatet på dette feltet er som følger:
Send-svar-til: adresse
Autentiske overskriftsfelt
Overskriftsfeltdataene identifiserer avsenderen av e-postmeldingen. Autentisk feltformat:
Fra: brukernavn Avsender: brukernavn
Fra:-feltet identifiserer forfatteren av meldingen. Vanligvis er feltene Fra: og Avsender: samme bruker, så bare ett av disse feltene er faktisk obligatoriske. I tilfellet der avsenderen av e-posten ikke er forfatteren av meldingen, men den bare sendes fra hans adresse, må begge feltene fortsatt spesifiseres - dette sikrer at meldingen returneres til avsenderen dersom levering til adressaten var umulig . Send på nytt autentiske overskriftsfelt
Resent-authentic-feltene identifiserer avsenderen av en melding som av en eller annen grunn ble overført av klientprogrammet. Formatet på disse feltene er som følger:
Sendt-fra: dato-klokkeslett Gjensendt-avsender: dato-klokkeslett Feltene Sendt-fra: og Gjensendt-avsender: fungerer på samme måte som feltene Fra: og Avsender:. De gjenspeiler bare at meldingen ble videresendt av klienten av en ukjent årsak.
Datoer overskriftsfelt
Datohodefelt brukes til å sette et tidsstempel på meldingen når den overføres fra klienten til serveren. Datoer-feltene har følgende format:
Dato: dato-klokkeslett Gjensendt-dato: dato-klokkeslett Dato:-feltet vil videresende informasjonen i meldingshodet nøyaktig som den opprinnelige meldingen. Dette alternativet kan være nyttig når du sporer tidspunktet for svar, spesielt flere svar.
Destinasjonsoverskriftsfelt
Destinasjonshodefeltene indikerer e-postadressene til meldingsmottakerne. Disse feltene er rent informasjonsmessige. SMTP-serveren vil uansett ikke sende en melding til brukerens postboks før den mottar RCPT-kommandoen utstedt for den brukeren (se avsnittet "Grunnleggende SMTP-klientkommandoer"). Formatet på disse feltene er som følger:
Til: adresse Gjensendt-til: adresse CC: adresse Gjensendt-CC: adresse BCC: adresse Gjensendt-BCC: adresse
Feltene Til:, CC: og BCC: angir standard e-postbehandlingsalgoritme. De fleste e-postpakker bruker denne terminologien for å klassifisere meldingsmottakere. CC-felt: Ligner på et notat, og mottakerne som er spesifisert i det skal motta en "kopi" av meldingen. Et annet nytt konsept introdusert av e-postsystemer er BCC: eller blind karbonkopi. Feltet "usynlig kopi" indikerer også mottakeren av en kopi av meldingen, men adressen hans er ikke synlig for utenforstående (dette er ikke helt etisk). Det har vært en del debatt om dette alternativet angående dataetikk, men i dag støtter nesten alle e-postprogrammer denne funksjonen.
Valgfrie overskriftsfelt
Valgfrie felt er felt som identifiserer meldingen mer detaljert til SMTP-serveren, men som i henhold til RFC 822 ikke er til stede i meldingen. Imidlertid er disse feltene nå utbredt og mange av dere vil måtte håndtere dem. Formatet til noen av dem er som følger:
Message-ID: message-id Resent-Message-ID: message-id In-Reply-To: message-id Referanser: message-id Nøkkelord: tekst - liste Emne: tekst Kommentarer: tekst Kryptert: ord
Det mest nyttige og mest brukte av dette settet er Emne:-feltet. De fleste e-postprogrammer lar avsenderen legge inn en én-linjes emnelinje som beskriver innholdet i meldingen til mottakeren. Denne tekstlinjen brukes ganske ofte av e-postklientprogrammer når de genererer lister over mottatte meldinger. Et annet valgfritt felt hjelper også med å identifisere e-postmeldingen. Dette feltet er Message-ID: (Message Identifier). Dette feltet tildeler et unikt identifikasjonsnummer til meldingen, som deretter kan vises i den returnerte meldingen. Spesialkrypteringsfelt Kryptert: indikerer om meldingen er kryptert av sikkerhetshensyn, og i Nøkkelord: kan angis søkeord, som kan brukes når du søker etter spesifikk tekst som finnes i en(e) melding(er).
Binære data og MIME
MIME-kodingsalgoritmen tar hensyn til typen binær fil som konverteres og gir også tilleggsinformasjon om filen til dekoderen. MIME-algoritmen lar binære data plasseres direkte i en standard postmelding, som definert av RFC 822. Fem nye overskriftsfelt er opprettet for å beskrive de binære dataene som er innebygd i en melding i RFC 822-format. E-postprogrammer som støtter MIME-standarden må håndtere alle disse nye headertypene på riktig måte.
MIME-versjon overskriftsfelt
Det første av de valgfrie overskriftsfeltene inneholder MIME-versjonen som avsenderen brukte da meldingen ble kodet. For øyeblikket er dette feltet alltid 1.0.
Innhold-overføring-koding-feltet
Innhold-Transfer-Encoding header-feltet spesifiserer hvordan binære data er omsluttet i en ASCII-tekstmelding. I dag er det sju på ulike måter koding av binære data, men base64-koding er den vanligste. Denne kodingsmetoden konverterer 6-bits blokker med binære data til 8-biters blokker som leses som ASCII-tekst.
Innhold-ID-feltet
Dette overskriftsfeltet brukes til å identifisere MIME-økter med en spesifikk ID-kode når innholdet er komplekst.
Innhold-beskrivelse-feltet
Innholdsbeskrivelse-overskriftsfeltet brukes til tekstbeskrivelse i format ASCII-data, plassert i e-postmeldingen. Dette er nyttig når du sender dokumenter laget ved hjelp av et tekstbehandlingsprogram eller grafikk som ikke er annerledes hvis base64 er kodet.
Innholdstype overskriftsfelt
Innholdstype overskriftsfelt
Dette tittelfeltet er der hovedhandlingen i stykket vårt finner sted. Dette feltet identifiserer dataene i MIME-meldingen. Det er for øyeblikket syv hoveddataklasser identifisert i MIME. Hver klasse har sine egne underklasser, som mer detaljert karakteriserer typen data i meldingen.
Tekstdatatypen identifiserer ASCII-data som skal leses i sin rå form. Det er også to underklasser her - ren tekst, dvs. uformatert ASCII-tekst, og beriket tekst, som inkluderer formateringselementer som ligner på beriket tekst tekstformat. Siste programmer For å jobbe med e-post kan de til og med jobbe med rikt tekstformat (RTF).
Meldingsdatatypen lar et e-postprogram sende enkle meldinger i formatet RFC 822. Underklasser av denne typen er: rfc822, som indikerer at vedlegget er en vanlig melding som er i samsvar med RFC 822; partial, som lar deg dele lange meldinger i flere deler, og ekstern-kropp, som lar deg plassere en peker til et objekt som ikke er en del av meldingen.
Bildedatatypen spesifiserer vedlegget av binære data, som representerer et grafisk bilde, til en melding. Det er for øyeblikket definert to underklasser for denne typen - jpeg og gif.
Videodatatypen spesifiserer følgelig at dataene vedlagt meldingen er videodata. Det er for øyeblikket bare en underklasse definert for denne typen, mpeg-formatet.
Lyddatatypen angir meldingsinnholdet som lyddata ( lydfiler). Også her er det så langt kun definert én grunnleggende underklasse, som tilsvarer én ISDN-kanal med en samplingsfrekvens på 8 KHz.
Type Applikasjonsdata samsvarer med binære data knyttet til en melding som er et vedlegg (f.eks. regneark Microsoft Excel eller dokumenter laget ved hjelp av en tekstbehandler Microsoft Word). Til dags dato har to underklasser av denne typen data blitt definert - postscript og octet-stream. Ganske ofte brukes oktettstrømunderklassen når du legger ved applikasjonsdata til en melding, for eksempel Microsoft Word-dokumenter eller elektroniske Microsoft-tabeller Utmerke.
Den flerdelte datatypen identifiserer meldinger som inneholder flere forskjellige datatyper. Dette formatet er ganske vanlig i e-postprogrammer som støtter meldingsutgang på flere måter, for eksempel ASCII-tekst. HTML-tekst eller lydfil. En grenseidentifikator skiller ulike typer data. Samtidig identifiseres hver datatype av et spesifikt datatypeoverskriftsfelt. Den flerdelte datatypen har fire underklasser.
Den blandede underklassen indikerer at hver del av meldingen er uavhengig og skal alle presenteres for mottakeren i den rekkefølgen de ble satt inn av avsenderen. Den parallelle underklassen indikerer at hver del av meldingen er uavhengig og alle kan presenteres for mottakeren i hvilken som helst rekkefølge. Den neste underklassen, alternativ, spesifiserer at alle deler av meldingen er de samme dataene, men presentert i en annen form. I dette tilfellet kan mottakeren velge det beste middelet for å se de mottatte dataene. Digest-underklassen ligner på mange måter den blandede underklassen, men spesifiserer at meldingsteksten alltid er representert i RFC822-format.
1 $ telnet localhost 25 2 Prøver 127.0.0.1... 3 Koblet til localhost. 4 Escape-tegnet er "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Man, 30. august 1999 07:36:58 -050 6 HELO localhost 7 258 shadrach.smallorg.org Hei localhost, hyggelig å møte deg 8 MAIL FROM:rich@localhost 9 250 rich@localhost... Avsender ok 10 RCPT TIL: rik 11 250 rik... Mottaker ok 12 DATA 13 354 Skriv inn e-post, avslutt med "." på en linje for seg selv 14 Fra: "Rich Blum"
Oppføring 5.6. Eksempel på SMTP-økt med flere MIME-vedlegg (html, txt) Eksempelmeldingen vist i oppføring 5.6 er en MIME-melding som har to deler. Linje 18 viser datatypen til meldingen. Den flerdelte/alternative typen indikerer at meldingen inneholder ulike typer data som er atskilt med grense1-skilletegnet. Den første typen data starter på linje 21 og er enkel ASCII-tekst som kan leses av nesten alle e-postprogram.
Den andre typen data starter på linje 27 og er rik tekst som bruker et rik tekstformat.
Siden MIME-typen som er spesifisert for meldingen er flerdelt/alternativ, er det helt opp til e-postprogrammet å bestemme hvilken versjon av vedlegget som skal vises.
Forbedret SMTP-protokoll
Siden introduksjonen i 1982 har SMTP-protokollen gjort en utmerket jobb med å sende meldinger mellom datamaskiner på Internett. Men over tid ble begrensningene som ligger i protokollen merkbare. Så, i stedet for å erstatte standardprotokollen, som ble mye brukt på den tiden, ble det besluttet å forbedre noen av funksjonene til SMTP-protokollen. Samtidig ble det besluttet å la alle SMTP-spesifikasjoner være i sin opprinnelige form og bare legge til nye funksjoner til dem.
I 1995 ble RFC 1869 utgitt, som definerte en metode for å utvide mulighetene til SMTP-protokollen, kalt Enhanced SMTP Services.
Utvidet SMTP implementeres som følger. I begynnelsen av en SMTP-økt har HELO-kommandoen blitt erstattet med en invitasjonskommando - EHLO. Når SMTP-serveren mottar en slik kommando, betyr det at klienten kan sende utvidede SMTP-kommandoer til den. Liste 5.7 viser en eksempeløkt som bruker EHLO samt tilleggskommandoer.
1 $ telnet localhost 25 2 Prøver 127.0.0.1... 3 Koblet til localhost. 4 Escape-tegnet er "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Man, 30 Aug 1999 16:36:48 -050 6 EHLO localhost 7 250-shadrach.smallorg.org Hei localhost, hyggelig å møte deg 8 250-EXPN 9 250-VERB 10 250-8BITMIME 10 250-250 13 250-ONEX 14 250-ETRN 15 250-XUSR 16 250 HJELP 17 HJELP DSN 18 214-POST FRA:
Linje 6 spesifiserer SMTP-kommandoen EHLO for å koble til SMTP-serveren. Linje 7–16 viser serverens svar. Merk at serveren signaliserer at flere kommandoer er tilgjengelige for bruk, dvs. Økten foregår i "utvidet" modus. En av de nye gruppene med kommandoer kallesre. Disse parameterne kan brukes med MAIL- og RCPT-kommandoene for å vise leveringsstatusen til en spesifikk e-postmelding. For oss som administratorer av postsystemet er imidlertid ETRN-kommandoen av størst interesse.
TURN-kommandoen er allerede nevnt tidligere. Denne kommandoen er veldig effektiv, men dessverre ikke sikker. For å kompensere for denne mangelen, definerer RFC 1985 en ny implementering av TURN-kommandoen som gir større sikkerhet. ETRN-kommandoen lar en SMTP-klient sende en forespørsel til en SMTP-server for å starte en annen SMTP-forbindelse med klienten for å sende meldinger til den. Den eneste forskjellen mellom ETRN-kommandoen og TURN-kommandoen er at forespørselen ikke er å bruke en eksisterende tilkobling, men å åpne en ny SMTP-sesjon. På denne måten kan SMTP-serveren koble til klientdatamaskinen ved hjelp av vanlige navneoppløsningsalgoritmer DNS-systemer. I dette tilfellet er åpningen av en ny tilkobling ikke basert på navnet som klientdatamaskinen er registrert under på serveren, men på det virkelige vertsnavnet til klienten. I dette tilfellet, hvis en hacker etablerer en uautorisert SMTP-tilkobling og bruker ETRN-kommandoen, vil SMTP-serveren ganske enkelt opprette en ny tilkobling med ekte klient og send ham en e-post. Som et resultat var det ingen personskader. ETRN-kommandoformatet er som følger:
Her kan navnets rolle være enten vertsnavnet eller domenenavnet (hvis det er en forespørsel om å motta post for hele domenet). ETRN-teamet er en veldig god hjelp for en e-postadministrator. Hvis Internett-leverandøren din lagrer e-post for e-postserveren din, kan du ved å bruke denne kommandoen varsle den om at den er klar til å motta e-post som samles inn for deg. Det er flere måter å implementere en slik algoritme på. En av dem er bruken av spesielle Perl-programmer, som følger med sendmail-programmet. Dens arbeid er nettopp at etter å ha opprettet en forbindelse med Internett-leverandøren, utsteder den ETRN-kommandoen med navnet på domenet ditt som et argument. Etter å ha mottatt denne kommandoen, initierer leverandørens SMTP-server en annen SMTP-tilkobling med din lokale SMTP-server (over samme PPP-tilkobling) og sender all e-post beregnet for ditt domene som den har i køen for sending.
For å utveksle informasjon mellom datamaskiner ble det utviklet standarder for overføring og behandling av informasjon, som ble kalt nettverksprotokoller. De vanligste protokollene er IP, ICMP, TCP, UDP, SMTP, POP/POP3, IMAP, HTTP/HTTPS og FTP, men det finnes andre, mindre kjente, som SSH, TELNET og andre.
For at to personer skal snakke, må de snakke samme språk. De trenger imidlertid ikke å følge grammatikk og formelle språkstrukturer strengt for å forstå hverandre. For å utveksle informasjon mellom datamaskiner må alt være klart definert og strukturert. Derfor bør standarder for overføring og behandling av ulike typer informasjon benyttes. Protokollene er etablert ved internasjonal avtale og garanterer utveksling av informasjon mellom alle datamaskiner hvor som helst. Det finnes mange forskjellige protokoller for ulike behov og typer informasjon.
IP, ICMP, TCP og UDP
IP (Internet Protocol) og TCP (Transmission Control Protocol) er to helt forskjellige protokoller som vanligvis er knyttet til hverandre. Kombinasjoner av flere protokoller brukes ofte, siden funksjonene til forskjellige protokoller kan kombineres på en slik måte at man får en løsning på problemet. I kombinasjon utfører hver protokoll operasjoner på sitt eget lag.
Ved overføring av informasjon over Internett er den delt inn i små deler - Internett-pakker, som overføres uavhengig av hverandre. Dette fremskynder overføringen av informasjon betydelig på grunn av det faktum at forskjellige deler kan overføres langs forskjellige ruter, hvoretter de settes sammen igjen ved mottakspunktet til en enkelt helhet. Dette er også et tiltak for å hindre tap av informasjon under overføring. TCP-protokollen er ansvarlig for å lage Internett-pakker til og fra remontering V i riktig rekkefølge på mottaksstedet, og verifiserer også integriteten til informasjonen. Hvis noen pakker går tapt under overføring, blir de overført på nytt.
Internet Protocol (IP) brukes til å levere informasjon til ønsket adresse. Hver datamaskin som har en Internett-tilkobling har sin egen unik adresse– . Hver pakke som sendes inneholder en leveringsadresse. En Internett-pakke kan passere gjennom mange rutere før den når destinasjonen. Internett-protokollen er ansvarlig for å rute pakken til den angitte datamaskinen. IP oppretter ikke fysiske forbindelser mellom datamaskiner. Den kan brukes sammen med andre protokoller som skaper tilkoblinger.
For å overføre små biter av informasjon kan du bruke UDP-protokoll(User Datagram Protocol - brukerdatagramprotokoll). Den brukes også i forbindelse med Internett-protokollen, men er mye enklere enn TCP. I motsetning til TCP, garanterer ikke UDP levering av pakker i den nødvendige rekkefølgen og dupliserer ikke overføringen av tapte pakker; følgelig bruker den mindre systemressurser, og overføringshastigheten er betydelig høyere. Den brukes i applikasjoner som krever store gjennomstrømning kommunikasjonslinjer, eller kort dataleveringstid, for eksempel for lyd- eller videokommunikasjon.
Det finnes også en helt annen lavnivåprotokoll – ICMP (Internet Control Message Protocol). Den brukes først og fremst til diagnostiske eller tjenesteformål, for eksempel rapportering av feil og andre eksepsjonelle situasjoner som oppstår under dataoverføring, for eksempel at den forespurte tjenesten ikke er tilgjengelig, eller at verten eller ruteren ikke svarer.
E-postprotokoller – SMTP, POP, IMAP
Sending og mottak av e-post krever egne protokoller. E-post sendes vanligvis ved hjelp av SMTP (Simple Mail Transfer Protocol). Den brukes også til å overføre e-post mellom e-postservere. Når du setter opp e-postklienter (for eksempel Outlook Express), må du spesifisere SMTP-serveradressen. For å motta e-post fra serveren postkasse E-postklienter bruker vanligvis POP-protokollen (Post Office Protocol). For øyeblikket er dens tredje utgave (versjon) i kraft, som kalles POP3 (Post Office Protocol Version 3 - post office protocol, versjon 3). For å kunne motta e-post må du spesifisere POP3-serveradressen når du setter opp e-postklienten. SMTP- og POP3-serveradressene kan være de samme eller ikke; de bør sjekkes med e-postleverandøren din. SMTP- og POP3-protokollene fungerer sammen med TCP-protokollen for å overføre og levere post over Internett.
Det finnes også en mer funksjonell, men mindre kjent protokoll for å lese e-post – IMAP (Internet Message Access Protocol – Internet Email Access Protocol). Denne protokollen lar deg få tilgang til meldinger som er lagret i en postboks på serveren uten å måtte laste den opp til lokal datamaskin. Dette er veldig praktisk når du trenger tilgang til postboksmeldinger fra flere datamaskiner. IMAP fungerer også sammen med TCP-protokoll.
HTTP- og HTTPS-protokoller
Nettsider bruker HyperText Markup Language (HTML). HTML-sider overføres over Internett ved hjelp av en standard kalt HyperText Transfer Protocol (HTTP). Grunnlaget for HTTP er klient-server-teknologien, det vil si at brukeren starter en tilkobling til serveren for å be om informasjon, og serveren venter på at tilkoblingen skal motta forespørselen, behandler forespørselen og returnerer en melding med resultatet. HTTP fungerer sammen med TCP-protokollen. Adresser ved hjelp av HTTP-protokoll start med "http:".
Relatert til HTTP-protokollen er HTTPS (HTTP over TLS). Den gir kryptering under dataoverføring for å beskytte konfidensiell informasjon. URL-er som bruker HTTP-protokollen begynner med "https:".
Filoverføringsprotokoll – FTP
File Transfer Protocol (FTP) er laget for å overføre filer til datanettverk fra en datamaskin til en annen. Det gir muligheten til å enkelt administrere filer på en ekstern datamaskin. Dette er en ganske gammel protokoll som ble satt i drift før verdensveven(WWW-verden Wide Web). For tiden brukes den hovedsakelig til å laste opp filer til webservere, men det finnes også fillagringer som opererer ved hjelp av FTP-protokollen. Den fungerer sammen med TCP-protokollen. URL-er som bruker FTP-protokollen begynner med "ftp:".
For samtidig drift av servere ved hjelp av protokoller SMTP, POP, IMAP, HTTP, HTTPS, FTP osv. er ikke nødvendig i det hele tatt individuelle datamaskiner eller IP-adresser. Alle disse serverne kan installeres på én datamaskin med én IP-adresse. Dette oppnås på grunn av det faktum at hver protokoll bruker sin egen.
I flere tiår har Internett-brukere brukt e-post til å utveksle meldinger og brev. Fram til begynnelsen av 90-tallet av forrige århundre ble elektroniske meldinger som regel brukt av ansatte i store organisasjoner. Med omfattende databehandling og spredningen av World Wide Web, har e-poster blitt en del av vanlige brukeres liv.
Utviklingen av Internett-teknologier har ført til fremveksten av såkalte postprotokoller som brukes til nettverkskorrespondanse. De gjør det mulig å behandle store bokstaver, og gir brukerne alle slags tjenester.
Det er ikke begrenset av noen spesifikke dataoverføringsundersystemer. Dens drift krever bare en pålitelig kanal for flyten av overføringen mens de opprettholder orden.
SMTP brukes hovedsakelig til å sende brev og brukerforespørsler til serveren, hvoretter e-post sendes til mottakere. For å motta brev må du jobbe med postklienten IMAP-protokoll eller POP3.
Hva brukes den til?
Dette er standard postprotokoll i dag. Alle bruker det utsendelser og servere.
Virtuell nettstedshosting for populære CMS:
Prinsippet for drift av protokollen.
SMTP er en tekstprotokoll, dens driftsprinsipp krever en tilkobling der brukeren som sender e-posten kontakter mottakeren ved hjelp av en bestemt kommandolinje. Og data mottas gjennom bruk av en pålitelig kommunikasjonskanal. Vanligvis er denne kommunikasjonskanalen en TCP-forbindelse.
En arbeidsprotokolløkt består av en rekke kommandoer sendt av SMTP-postklienten og serverens svar på dem. Under en arbeidsøkt utveksler både klienten og serveren de nødvendige parameterne.
En protokolloperasjon inkluderer en kombinasjon som består av følgende sekvenser av kommandoer og svar:
- MAIL FROM-kommandoen - indikerer retur-e-postadressen;
- RCPT TO kommando - bestemmer mottakeren av et bestemt brev;
- DATA er kommandoen som er ansvarlig for å sende teksten til en e-postmelding. Dette er hoveddelen av brevet, som inkluderer overskriften og hoveddelen av brevet, atskilt med en tom linje.
Den første SMTP-klienten kan godt være mottakerens e-postklient, eller en e-postoverføringsagent på serveren.
Hvordan andre e-postprotokoller fungerer.
SMTP er bare en protokoll for å levere korrespondanse på nettverket. Han kan ikke, på kommando, ta en e-postmelding fra en ekstern server eller på en eller annen måte administrere en e-postboks.
Det finnes andre protokoller for dette, som IMAP og POP. Bruken av dem er å foretrekke når du kobler til et nettverk midlertidig eller når PC-en slås på med jevne mellomrom.
POP.
Post Office Protocol er en enkel nettverksprotokoll som inkluderer tre smaker: POP, POP2 og POP3. De er designet for å levere korrespondanse til brukeren fra en sentral e-postserver, slette e-post fra serveren og identifisere brukeren. En kombinasjon av pålogging og passord brukes for identifikasjon. Det er verdt å merke seg at alle tre protokollene ikke er utskiftbare.
Protokollen inkluderer SMTP, som brukes til å overføre utgående post.
I henhold til POP3 lagres brev som kommer til en bestemt e-post på serveren til de lastes ned til PC-en i neste økt. Når nedlastingen har skjedd, blir det mulig å lese meldingene mens du kobler fra nettverket. POP3 regnes for å være den raskeste e-postprotokollen.
IMAP.
Ved å bruke Internet Message Access Protocol blir det mulig å lagre meldinger i filkataloger på serveren og søke etter eventuelle meldingsstrenger direkte der.
Denne protokollen er egnet for brukere hvis datamaskiner bruker en kontinuerlig tilkobling til Internett. Det skiller seg fra POP ved at når nye meldinger skannes, er det kun overskriftene som lastes ned.
datamaskin fra lokal datamaskin. Simple Mail Transfer Protocol (SMTP) har blitt brukt til å utveksle e-postmeldinger mellom forskjellige datamaskiner siden 1982. Den enkle bruken og portabiliteten til ulike plattformer har gjort denne protokollen til standarden for utveksling av elektroniske meldinger mellom datasystemer på Internett. For å forstå hvordan det fungerer, la oss se på hva det er.Beskrivelse av SMTP-protokollen
SMTP-protokollen ble designet for å fungere i ulike nettverk for transport av e-post. Internett har imidlertid blitt et av de mest brukte, med en TCP/IP-forbindelse etablert gjennom port 25. De fleste versjoner av Linux OS installerer automatisk en programvarepakke for å støtte SMTP ved installasjon av ulike tjenester. For å verifisere at den eksterne serveren er i stand til å fungere ved hjelp av SMTP-protokollen, kan du logge på port 25 ved hjelp av telnet-programmet. Hvis et svar mottas fra denne porten, kjører SMTP-protokollen på serveren. På en lokal server kan du gjøre det samme ved å koble til ved hjelp av telnet til port 25 på localhost. Et eksempel på en telnet-økt med en Linux-basert server er vist i Listing 5.1.
1 $ telnet localhost 25 2 Prøver 127.0.0.1... 3 Koblet til localhost. 4 Escape-tegnet er "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Ons, 25. aug 1999 18:35:33 -0500 6 AVSLUTT 7 221 shadrach.smallorg.org stengeforbindelse 8 Forbindelse stengt av utenlandsk vert. $9 Oppføring 5.1. Eksempel på telnet-økt med port 25
Linje 1 viser formatet til en telnet-kommando som bruker localhost og TCP-port 25. Linje 5 viser et typisk svar fra en Linux-server som kjører SMTP-programvare. Nummeret som starter svaret er den tresifrede svarkoden. Denne koden kan brukes til å feilsøke e-postproblemer. Det som følger er navnet på SMTP-serveren og en beskrivelse av SMTP-programvarepakken som distribueres av Sendmail Consortium. Linje 6 inneholder QUIT-kommandoen for å lukke telnet-økten. SMTP-serveren skal da gi en melding om øktlukking og avslutte TCP-tilkoblingen. Fra dette eksemplet kan du se at SMTP bruker enkle ASCII-tekstkommandoer og returnerer tre-tegns kodede tekstmeldingssvar. SMTP-protokollen er beskrevet i Internet Request For Comment (RFC) nummer 821, som ble utviklet av Internet Engineering Task Force (IETF) og publisert 21. august 1982. Siden den gang har den gjennomgått flere modifikasjoner, men generelt har de grunnleggende kommandoene i protokollen ikke endret seg.
Grunnleggende SMTP-klientkommandoer
Etter at en TCP-sesjon er etablert, sender SMTP-serveren en spesiell melding om etablering av tilkobling til klienten (som vist i oppføring 5.1). Fra dette tidspunktet styres forbindelsen mellom de to datamaskinene av klienten som er koblet til serveren. Klienten kontrollerer tilkoblingen ved å bruke et sett med spesialkommandoer som den sender til serveren. Serveren må på sin side svare riktig på hver kommando som sendes til den. RFC 821 beskriver de grunnleggende kommandoene for en SMTP-klient som serveren må svare på på en bestemt måte. Selv om flere utvidelser til SMTP-protokollen har blitt introdusert siden dette dokumentet ble skrevet, støttes de ennå ikke av alle e-postservere. I denne delen vil vi bare fremheve det viktigste SMTP-kommandoer, definert i RFC 821. Avsnittet "SMTP Protocol Extensions" diskuterer noen av tilleggene implementert i nyere versjoner av SMTP-pakken.
Kommandoformatet i SMTP er enkelt:
kommando,
der kommando er en fire-tegns SMTP-protokollkommando, og parameter er en valgfri parameter som spesifiserer datatypen i kommandoen. I tabellen 5.1 viser de grunnleggende kommandoene til SMTP-protokollen. Deretter vil vi se på disse kommandoene mer detaljert.
| Team | Beskrivelse |
|---|---|
| HELO | Åpner en invitasjon fra en klient |
| POST | Identifiserer avsenderen av meldingen |
| RCPT | Definerer meldingsmottakere |
| DATA | Definerer begynnelsen av en melding |
| SENDE | Sender en melding til terminalen |
| SOML | Send-eller-post |
| SAML | Send-og-post |
| RSET | Tilbakestiller SMTP-tilkoblingen |
| VRFY | Sjekker systemets brukernavn |
| EXPN | Ber om en liste over aliaser |
| HJELP | Ber om en liste over kommandoer |
| NEI | Ingen operasjon - Gjør ingenting |
| SLUTTE | Stopp SMTP-økt |
| SVING | Rollevending i SMTP (klient blir server) |
HELO Team
Per definisjon er SMTP-protokollkommandoer fire tegn lange. Hilsenen som sendes av klienten til serveren er HELO-kommandoen. Kommandoformatet er som følger:
HELO domenenavn
Hensikten med HELO-kommandoen er å presentere klienten for SMTP-serveren. Dessverre ble denne tilgangsmetoden utviklet i den innledende fasen av utviklingen av Internett, da det ennå ikke var så mange forsøk på uautorisert penetrering i datasystemer. Som du kan se, kan klienten kalle seg et hvilket som helst navn på kommandolinjen. Dette har ført til at de fleste SMTP-servere for tiden bruker denne kommandoen rent formelt. Hvis de prøver å identifisere klienten, aktiveres en omvendt DNS-oppslagsmekanisme for å bestemme klientens faktiske vertsnavn for domenenavnsystem fra IP-adressen. Vanligvis, av sikkerhetsgrunner, vil SMTP-servere nekte tilkoblinger til verter hvis IP-adresse ikke løses til et tilsvarende vertsnavn. Ved å sende denne kommandoen, varsler klienten serveren om at den ønsker å opprette en forbindelse med den. Ved å svare på denne kommandoen, varsler serveren på sin side at en ny forbindelse er opprettet med klienten og er klar til å akseptere påfølgende kommandoer fra den.
Klientbrukere og klientverter
Når du arbeider med SMTP-protokollen, må du skille mellom SMTP-klienter. Klientbrukere og klientverter er ikke det samme. Når du oppretter en e-postmelding, er brukeren av e-postsystemet også en klient av ham lokal vert. Når e-postmeldingen er sendt, er den ikke lenger en klient for SMTP-prosessen. Nå håndterer hans lokale vertsdatamaskin meldingsleveringsprosessen og fungerer selv som en SMTP-klient. Når en lokal vert kobler til en ekstern vert for å overføre en melding ved hjelp av SMTP-protokollen, fungerer den som en klient for SMTP-prosessen. HELO-kommandoen erklærer navnet som klienten lokal vert, og ikke den faktiske brukeren som sendte meldingen. Ganske ofte blir disse begrepene forvirret, noe som gjør det vanskelig å løse problemer som oppstår i e-postsystemer.
MAIL kommando
MAIL-kommandoen brukes til å starte en e-postøkt med serveren etter at HELO-kommandoen er sendt. Den indikerer hvem meldingen kommer fra. MAIL-kommandoformatet er som følger:
MAIL omvendt vei
Argumentet omvendt sti spesifiserer ikke bare avsenderen av meldingen, men spesifiserer også en rute som meldingen kan returneres gjennom hvis den ikke kan leveres. Hvis avsenderen er brukeren på klientdatamaskinen som startet SMTP-økten, vil kommandoformatet være som følger:
POST FRA: [e-postbeskyttet]
Merk at FROM-feltet spesifiserer e-postadressen til meldingsavsenderen, inkludert det fulle navnet på klientvertsdatamaskinen. Denne informasjonen må være til stede i FRA-feltet i e-postmeldingen (men mer om det senere). Hvis en e-postmelding gikk gjennom flere noder på vei fra avsender til mottaker, vil hver av dem legge til informasjon om seg selv i feltet