Elektronisk post har eksisteret i en eller anden form helt tilbage fra 1960\u2019erne. Folk efterlod beskeder til hinanden ved hj\u00e6lp af en r\u00e6kke forskellige metoder p\u00e5 mainframe-computere, men det var f\u00f8rst i august 1982, da Information Sciences Institute offentliggjorde The Simple Mail Transfer Protocol (SMTP; RFC 821), at der blev foresl\u00e5et en standardiseret metode til afsendelse og modtagelse af e-mail.<\/p>\n
<\/p>\n
SMTP blev hurtigt popul\u00e6rt p\u00e5 ARPANET, hvor det afl\u00f8ste \u00e6ldre og mere komplicerede metoder til at overf\u00f8re e-post fra den ene mainframe til den anden, og blev f\u00f8rste gang underst\u00f8ttet i slutningen af 1982 af den tidlige Mail Transfer Agent Sendmail i BSD 4.1c.
\nProtokollen er siden da blevet revideret og udvidet med j\u00e6vne mellemrum, men den grundl\u00e6ggende metode til at sende e-mails er stort set forblevet u\u00e6ndret.<\/p>\n
Protokollen er en tekstbaseret protokol, der oprindeligt ikke underst\u00f8ttede overf\u00f8rsel af bin\u00e6re data. Det faktum, at den var tekstbaseret, gjorde imidlertid protokollen nem at implementere og vedligeholde. MIME (Multipurpose Internet Mail Extensions) blev popul\u00e6rt i slutningen af 80\u2019erne til kodning og afsendelse af bin\u00e6re data via SMTP. I dag er SMTP den dominerende protokol til afsendelse og modtagelse af e-mail p\u00e5 internettet, og indg\u00e5ende kendskab til denne protokol er afg\u00f8rende for enhver netv\u00e6rksadministrator.<\/p>\n
Da SMTP er tekstbaseret, er det betydeligt nemmere at l\u00e6re protokollen end mange andre, og det eneste, der kr\u00e6ves for at kommunikere direkte med en SMTP-server, er et program, der kan sende ASCII-data via TCP\/IP-port 25, f.eks. Telnet.<\/p>\n
E-mails sendes via SMTP i en transaktion, hvilket vil sige, at hvis afsendelsen af meddelelsen ikke gennemf\u00f8res fuldt ud og uden at generere en fejl, kasseres meddelelsen. RFC 821 beskriver en transaktion som best\u00e5ende af tre faser: angivelse af en afsender, angivelse af en eller flere modtagere og derefter selve afsendelsen af meddelelsen. Det er dog nemmere at opfatte en SMTP-transaktion som best\u00e5ende af 5 faser:<\/p>\n
H\u00e5ndtryk<\/b><\/p>\n
N\u00e5r der oprettes forbindelse til en SMTP-server p\u00e5 port 25, skal afsenderen af en besked vente p\u00e5, at modtageren accepterer forbindelsen og identificerer sig i f\u00f8lgende format:<\/p>\n
220 [dom\u00e6ne] [Serviceoplysninger]
\nEksempel: 220 example.com Klar til brug<\/p><\/blockquote>\nAfsenderen skal derefter identificere sig over for modtageren ved hj\u00e6lp af HELO-kommandoen.<\/p>\n
HELO [dom\u00e6ne]
\nEksempel: HELO example.com<\/p><\/blockquote>\nMailserverne forventer, at hver enkelt server identificerer sig ved hj\u00e6lp af et dom\u00e6nenavn, som kan bruges til at verificere serverens identitet ved at foretage en MX-opslag. Den modtagende server m\u00e5 dog ikke afvise forbindelsen p\u00e5 dette tidspunkt, selvom afsenderens identitet ikke kan verificeres, og skal derfor svare med:<\/p>\n
250 [Besked]
\nEksempel: 250 example.com Hej bob@example.com<\/p><\/blockquote>\nSvarkode 250 er det generelle \u2018OK\u2019-svar fra en SMTP-server, der angiver, at den sidste handling er gennemf\u00f8rt uden problemer.<\/p>\n
Afsenderadresse:<\/b><\/p>\n
N\u00e5r de to servere har gennemf\u00f8rt deres h\u00e5ndtryk, er SMTP-transaktionen g\u00e5et i gang, og vi kan begynde at sende kommandoer til serveren. Hvis du vil se, hvilke kommandoer serveren underst\u00f8tter, skal du sende kommandoen HELP, hvorefter SMTP-serveren b\u00f8r svare med en besked, der angiver, hvilke kommandoer der underst\u00f8ttes.<\/p>\n
For at vi kan sende en besked til en bruger p\u00e5 denne server, skal vi dog f\u00f8rst angive en svaradresse. Svaradressen skal angives f\u00f8rst, s\u00e5 eventuelle fejl under SMTP-transaktionen kan rapporteres til denne adresse. Til dette bruger vi kommandoen \u2018MAIL FROM:\u2019:<\/p>\n
MAIL FRA:
\nEksempel: MAIL FROM:<\/p><\/blockquote>\nBem\u00e6rk tegnene \u00bbmindre end\u00ab og \u00bbst\u00f8rre end\u00ab. If\u00f8lge RFC 821 skal disse indeholde selve e-mail-adressen. Hvis adressen accepteres, returnerer SMTP et 250 OK-svar.<\/p>\n
Send til modtagere<\/b><\/p>\n
N\u00e5r vi har angivet en svaradresse, giver SMTP os mulighed for at identificere modtagerne af meddelelsen. Til dette bruger vi kommandoen \u2018RCPT TO:\u2019:<\/p>\n
RCPT TIL:
\nEksempel: RCPT TIL:<\/p><\/blockquote>\nFor at angive flere modtagere skal du blot gentage denne kommando for hver modtager. Hvis modtageren accepterer e-mails til denne bruger og kan modtage beskeden p\u00e5 nuv\u00e6rende tidspunkt, b\u00f8r den svare med et 250 OK-svar. Hvis der imidlertid ikke accepteres e-post for denne bruger, vil der blive sendt et 550-fejlsvar eller den relevante fejlkode. Modtager vi et 250 OK-svar, kan vi forts\u00e6tte med at sende beskeddataene.<\/p>\n
Send beskeddata<\/b><\/p>\n
Det er ret nemt at sende data via SMTP, men meddelelsesformaterne kan v\u00e6re ret komplicerede, is\u00e6r n\u00e5r der sendes bin\u00e6re vedh\u00e6ftede filer. For at begynde at sende data skal vi indtaste kommandoen \u2018DATA\u2019, hvorefter serveren skal svare med 354 Intermediate reply. F.eks.:<\/p>\n
354 Indtast en besked, der slutter med \u201c.\u201d p\u00e5 en linje for sig selv<\/p><\/blockquote>\n
Den enkleste besked, vi kan sende, er en almindelig tekstbesked, som ikke kr\u00e6ver, at vi bruger MIME-formatet med flere dele. Alle beskeder, uanset om de er i almindelig tekst eller ej, afsluttes ved at sende en linje, der udelukkende indeholder et punktum. Inden en besked sendes, kan du desuden sende nogle header-oplysninger, s\u00e5som Dato, Emne, Til, Cc og Fra.<\/p>\n
Eksempel:<\/p>\n
DATA
\n354 Indtast en besked, der slutter med \u201c.\u201d p\u00e5 en linje for sig selv
\nEmne: Dette er emnelinjen i den planlagte SMS-besked
\nOg dette er selve teksten i almindelig tekstbeskeden.<\/p><\/blockquote>\nHvis anmodningen accepteres, returnerer SMTP-serveren et 250 OK-svar eller en fejlkode, hvis transaktionen er mislykket eller ufuldst\u00e6ndig. Bem\u00e6rk punktummet i slutningen af linjen i meddelelsens br\u00f8dtekst; det er kun, n\u00e5r der findes et punktum alene p\u00e5 en linje, at serveren holder op med at lytte efter data. Hvis afsenderens server sender en besked, der vil medf\u00f8re, at datasessionen lukkes f\u00f8r tid \u2013 fordi beskeden indeholder et enkelt punktum p\u00e5 en linje \u2013 b\u00f8r den tilf\u00f8je et ekstra punktum til linjen.<\/p>\n
Afslutning af transaktionen<\/b><\/p>\n
Indtil dette tidspunkt betragtes alt, hvad der er sendt til den modtagende SMTP-server, som midlertidigt. Hvis kommandoen \u2018QUIT\u2019 ikke sendes, f\u00f8r forbindelsen lukkes, vil destinationsserveren blot slette alle meddelelsesdata, der er blevet gemt. Oprindeligt blev den brugt som en elegant m\u00e5de at lukke en forbindelse p\u00e5, men i dag bruges den ofte til at angive, at en transaktion er afsluttet, idet mange mailservere venter p\u00e5 QUIT-kommandoen, f\u00f8r de s\u00e6tter mailen i k\u00f8, s\u00e5 Message Transfer Agent kan videresende den. N\u00e5r du har sendt QUIT-kommandoen, b\u00f8r destinationsserveren sende et 221-svar for at bekr\u00e6fte, at transaktionen er afsluttet, og at forbindelsen lukkes.<\/p>\n
Hvis du er ved at s\u00e6tte dig ind i SMTP-protokollen, anbefales det, at du l\u00e6ser RFC 821, 2476 og 2554. Du b\u00f8r huske p\u00e5 \u2013 is\u00e6r n\u00e5r du l\u00e6ser RFC 821 \u2013 at e-mail-serverne har \u00e6ndret sig markant siden 1982, blandt andet som f\u00f8lge af misbrug fra spammere.<\/p>","protected":false},"excerpt":{"rendered":"
Electronic Mail has existed in one form or another as far back as the 1960’s. People would leave messages for one another using a number of different methods on mainframe computers but it wasn’t until August 1982 when the Information Sciences Institute published The Simple Mail Transfer Protocol (SMTP; RFC 821) that a standardized method Read more about Att SMTP Server – The SMTP Protocol<\/span>[...]<\/a><\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-71","post","type-post","status-publish","format-standard","hentry","category-smtp-servers"],"_links":{"self":[{"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/posts\/71","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/comments?post=71"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/posts\/71\/revisions"}],"predecessor-version":[{"id":72,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/posts\/71\/revisions\/72"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/media?parent=71"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/categories?post=71"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/tags?post=71"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}