Email adresse - Email address

En e -mail -adresse identificerer en e -mail -boks, hvortil meddelelser leveres. Mens tidlige meddelelsessystemer brugte en række forskellige formater til adressering, følger e -mail -adresser i dag et sæt specifikke regler, der oprindeligt var standardiseret af Internet Engineering Task Force (IETF) i 1980'erne og opdateret af RFC  5322 og 6854 . Udtrykket e-mail-adresse i denne artikel refererer til addr-spec i RFC 5322, ikke til adresse eller postkasse ; dvs. en rå adresse uden et visningsnavn .

En e-mail-adresse, såsom john.smith@example.com , består af en lokal del , symbolet @og et domæne , som kan være et domænenavn eller en IP-adresse, der er omsluttet af parenteser. Selvom standarden kræver, at den lokale del er store og små bogstaver, opfordrer den også til, at modtagende værter leverer beskeder på en uafhængig måde, f.eks. At mailsystemet på domænet example.com behandler John.Smith som ækvivalent med john.smith ; nogle postsystemer behandler dem endda som svarende til johnsmith . Mailsystemer begrænser ofte brugernes valg af navn til en delmængde af de teknisk tilladte tegn.

Med introduktionen af internationaliserede domænenavne skrider indsatsen frem for at tillade ikke-ASCII-tegn i e-mail-adresser.

Besked transport

En e -mail -adresse består af to dele, en lokal del og et domæne; hvis domænet er et domænenavn frem for en IP -adresse, bruger SMTP -klienten domænenavnet til at slå IP -adressen til mailudveksling op. Det generelle format for en e-mail-adresse er local-part @ domain , f.eks. Jsmith@[192.168.1.2], jsmith@example.com . SMTP -klienten sender meddelelsen til mailudvekslingen, som kan videresende den til en anden mailudveksling, indtil den i sidste ende ankommer til værten i modtagerens mailsystem.

Overførslen af ​​elektronisk post fra forfatterens computer og mellem mailværter på Internettet anvender Simple Mail Transfer Protocol (SMTP), defineret i RFC  5321 og 5322 , og udvidelser såsom RFC 6531. Postkasserne kan tilgås og administreres af applikationer på personlige computere, mobile enheder eller webmail -websteder ved hjælp af SMTP -protokollen og enten Post Office Protocol (POP) eller Internet Message Access Protocol (IMAP).

Når transmission e-mails , post bruger agenter (MUAs) og mail transfer agents (MTA'er) bruger Domain Name System (DNS) til at kigge op en ressource Record (RR) for modtagerens domæne. En mailvekslerressourcepost ( MX -post ) indeholder navnet på modtagerens mailserver. I mangel af en MX -post angiver en adressepost ( A eller AAAA ) mailværten direkte.

Den lokale del af en e -mail -adresse har ingen betydning for mellemliggende e -mail -relæsystemer end den endelige mailbox -vært. E-mail-afsendere og mellemliggende relæ-systemer må ikke antage, at det er ufølsomt for store og små bogstaver, da den endelige postkasse-vært muligvis behandler det som sådan. En enkelt postkasse modtager muligvis mail til flere e -mail -adresser, hvis den er konfigureret af administratoren. Omvendt kan en enkelt e -mail -adresse være alias til en distributionsliste til mange postkasser. E-mail-aliasser , elektroniske mailinglister , underadressering og catch-all- adresser, sidstnævnte er postkasser, der modtager beskeder uanset den lokale del, er almindelige mønstre for at nå en række forskellige leveringsmål.

Adresserne, der findes i overskriftsfelterne i en e -mail -meddelelse, bruges ikke direkte af mailudvekslinger til at levere beskeden. En e -mail -besked indeholder også en beskedkonvolut, der indeholder oplysningerne til mail -routing. Selvom konvolut- og overskriftsadresser kan være ens, ses forfalskede e -mail -adresser - også kaldet forfalskede e -mail -adresser - ofte i spam , phishing og mange andre internetbaserede svindel. Dette har ført til flere initiativer, der har til formål at gøre sådanne forfalskninger af svigagtige e -mails lettere at få øje på.

Syntaks

Formatet på en e-mailadresse er local-part@domain , hvor den lokale del kan være op til 64 oktetter lang, og domænet maksimalt må have 255 octets. De formelle definitioner findes i RFC 5322 (afsnit 3.2.3 og 3.4.1) og RFC 5321 - med en mere læsbar form angivet i informations -RFC 3696 og de tilhørende fejl.

En e -mail -adresse kan også have et tilknyttet visningsnavn for modtageren, der går forud for adressespecifikationen, nu omgivet af vinklede parenteser, for eksempel: John Smith <john.smith@example.org> .

Tidligere former for e -mail -adresser til andre netværk end Internettet inkluderede andre notationer, f.eks. Dem , der kræves af X.400 , og UUCP -bang -stienotation, hvor adressen blev givet i form af en sekvens af computere, hvorigennem meddelelsen skulle blive videresendt. Dette blev brugt i vid udstrækning i flere år, men blev afløst af internetstandarderne, der blev bekendtgjort af Internet Engineering Task Force (IETF).

Lokal del

Den lokale del af e-mailadressen kan være uden citat eller være indeholdt i anførselstegn.

Hvis den ikke er citeret, kan den bruge et af disse ASCII -tegn:

  • store og små latinske bogstaver Atil Zog atilz
  • cifre 0til9
  • tegn, der kan udskrives !#$%&'*+-/=?^_`{|}~
  • dot ., forudsat at det ikke er det første eller sidste tegn, og forudsat at det ikke vises i rækkefølge (f.eks. John..Doe@example.comer ikke tilladt).

Hvis det er citeret, kan det indeholde mellemrum, vandret fane (HT), enhver ASCII-grafik undtagen Backslash og Quote og et citeret par, der består af en Backslash efterfulgt af HT, Space eller enhver ASCII-grafik; det kan også deles mellem linjer hvor som helst, hvor HT eller mellemrum vises. I modsætning til unoterede lokale-dele, adresser ".John.Doe"@example.com, "John.Doe."@example.comog "John..Doe"@example.comer tilladt.

Den maksimale samlede længde af den lokale del af en e-mail-adresse er 64 oktetter.

Bemærk, at nogle mailservere understøtter wildcard -genkendelse af lokale dele, typisk tegnene efter et plus og sjældnere tegnene efter et minus, så fred+bah@domæne og fred+foo@domæne kan ende i den samme indbakke som fred+@domæne eller endda som fred@domain. Dette kan være nyttigt til mærkning af e -mails til sortering (se nedenfor) og til spamkontrol. Seler {og }bruges også på den måde, men sjældnere.

  • mellemrum og specialtegn "(),:;<>@[\]er tilladt med begrænsninger (de er kun tilladt inde i en citeret streng, som beskrevet i afsnittet nedenfor, og i den citerede streng skal ethvert omvendt skråstreg eller dobbeltcitat være efterfulgt af en omvendt skråstreg);
  • kommentarer er tilladt med parenteser i hver ende af den lokale del; f.eks. john.smith(comment)@example.comog (comment)john.smith@example.combegge svarer til john.smith@example.com.

Ud over de ovennævnte ASCII-tegn er internationale tegn over U+007F, kodet som UTF-8 , tilladt af RFC 6531, selvom selv postsystemer, der understøtter SMTPUTF8 og 8BITMIME, kan begrænse, hvilke tegn der skal bruges ved tildeling af lokale dele.

En lokal del er enten en Dot-string eller en Quoted-string; det kan ikke være en kombination. Citerede strenge og tegn bruges imidlertid ikke almindeligt. RFC 5321 advarer også om, at "en vært, der forventer at modtage e-mail, SKAL undgå at definere postkasser, hvor den lokale del kræver (eller bruger) formen for streng-streng".

Den lokale del postmasterbehandles specielt-det er ufølsomt for store og små bogstaver og skal videresendes til domænemailadministratoren. Teknisk set er alle andre lokale dele store og små bogstaver jsmith@example.comog JSmith@example.comangiver derfor forskellige postkasser; mange organisationer behandler imidlertid store og små bogstaver som ækvivalente. RFC 5321 advarer faktisk om, at "en vært, der forventer at modtage mail, SKAL undgå at definere postkasser, hvor ... den lokale del er store og små bogstaver".

På trods af den brede vifte af specialtegn, der er teknisk gyldige, accepterer organisationer, mailservices, mailservere og mailklienter i praksis ofte ikke dem alle. For eksempel tillader Windows Live Hotmail kun oprettelse af e -mail -adresser ved hjælp af alfanumerik, dot ( .), understregning ( _) og bindestreg ( -). Almindeligt råd er at undgå at bruge nogle specialtegn for at undgå risikoen for afviste e -mails.

Domæne

Den domænenavn del af en e-mail-adresse skal overholde strenge retningslinjer: det skal matche kravene til en værtsnavn , en liste over dot-separeret DNS etiketter, hvor hver etiket er begrænset til en længde på 63 tegn og består af:

  • store og små latinske bogstaver Atil Zog atil z;
  • cifre 0til 9, forudsat at topdomænenavne ikke er alle-numeriske;
  • bindestreg -, forudsat at det ikke er det første eller sidste tegn.

Denne regel er kendt som LDH -reglen (bogstaver, cifre, bindestreg). Derudover kan domænet være en IP -adresse bogstaveligt, omgivet af firkantede parenteser [], såsom jsmith@[192.168.2.1]eller jsmith@[IPv6:2001:db8::1], selvom dette sjældent ses undtagen i e -mail -spam . Internationaliserede domænenavne (som er kodet for at overholde kravene til et værtsnavn ) giver mulighed for præsentation af ikke-ASCII-domæner. I postsystemer, der er kompatible med RFC 6531 og RFC 6532, kan en e-mail-adresse være kodet som UTF-8 , både en lokal del og et domænenavn.

Kommentarer er tilladt i domænet såvel som i den lokale del; for eksempel john.smith@(comment)example.comog john.smith@example.com(comment)svarer til john.smith@example.com.

Reserverede domæner

RFC  2606 specificerer, at visse domæner, f.eks. Dem, der er beregnet til dokumentation og test, ikke skal kunne løses, og at mail som følge heraf adresseres til postkasser i dem og deres underdomæner ikke kan leveres. Bemærk til e-mail er eksempel , ugyldig , example.com , example.net og example.org .

Eksempler

Gyldige e -mail -adresser
simple@example.com
very.common@example.com
disposable.style.email.with+symbol@example.com
other.email-with-hyphen@example.com
fully-qualified-domain@example.com
user.name+tag+sorting@example.com(kan gå til user.name@example.comindbakken afhængigt af mailserveren)
x@example.com (lokal del med ét bogstav)
example-indeed@strange-example.com
test/test@test.com (skråstreger er et tegn, der kan udskrives, og er tilladt)
admin@mailserver1(lokalt domænenavn uden TLD , selvom ICANN stærkt fraråder dotless e -mail -adresser)
example@s.example(se listen over internet-topdomæner )
" "@example.org (mellemrum mellem citaterne)
"john..doe"@example.org (citeret dobbelt prik)
mailhost!username@example.org (bangified værtrute brugt til uucp -mailere)
user%example.com@example.org (% undslap mailrute til user@example.com via example.org)
user-@example.org (lokal del, der slutter med ikke-alfanumerisk tegn fra listen over tilladte udskrivbare tegn)


Ugyldige e -mail -adresser
Abc.example.com (ingen @ tegn)
A@b@c@example.com (kun én @ er tilladt uden for anførselstegn)
a"b(c)d,e:f;g<h>i[j\k]l@example.com (ingen af ​​specialtegnene i denne lokale del er tilladt uden for anførselstegn)
just"not"right@example.com (citerede strenge skal være prikseparerede eller det eneste element, der udgør den lokale del)
this is"not\allowed@example.com (mellemrum, anførselstegn og omvendte skråstreger må kun eksistere, når de er inden for citerede strenge og forud for et skråstreg)
this\ still\"not\\allowed@example.com (selvom den er undsluppet (forud for en skråstreg), skal mellemrum, anførselstegn og omvendte skråstreger stadig være indeholdt af anførselstegn)
1234567890123456789012345678901234567890123456789012345678901234+x@example.com (lokal del er længere end 64 tegn)
i_like_underscore@but_its_not_allowed_in_this_part.example.com (Underscore er ikke tilladt i domænedelen)
QA[icon]CHOCOLATE[icon]@test.com (ikontegn)

Fælles lokal del-semantik

Ifølge RFC 5321 2.3.11 Postkasse og adresse, "... SKAL den lokale del kun tolkes og tildeles semantik af den vært, der er angivet i adressens domæne." Det betyder, at der ikke kan antages antagelser om betydningen af ​​den lokale del af en anden mailserver. Det er helt op til konfigurationen af ​​mailserveren.

Normalisering i lokal del

Fortolkning af den lokale del af en e -mail -adresse er afhængig af de konventioner og politikker, der er implementeret på mailserveren. For eksempel, hvis følsomhed kan skelne mellem postkasser kun afviger i kapitalisering af tegn i den lokale del, selv om dette ikke er meget almindeligt. Gmail ignorerer alle prikker i den lokale del af en @gmail.com- adresse med henblik på at bestemme kontoidentitet.

Underadressering

Nogle mailtjenester understøtter et tag, der er inkluderet i den lokale del, således at adressen er et alias til et præfiks for den lokale del. For eksempel angiver adressen joeuser+tag@example.com den samme leveringsadresse som joeuser@example.com . RFC 5233, henviser til denne konvention som underadressering , men den er også kendt som plusadressering , tagget adressering eller mailudvidelser .

Adresser til denne formular ved hjælp af forskellige adskillere mellem basisnavnet og tagget understøttes af flere e -mail -tjenester, herunder Andrew Project (plus), Runbox (plus), Gmail (plus), Rackspace (plus), Yahoo! Mail Plus (bindestreg), Apples iCloud (plus), Outlook.com (plus), ProtonMail (plus), Fastmail (plus og underdomæneadressering), postale.io (plus), Pobox (plus), MeMail (plus), MMDF (lig), Qmail og Courier Mail Server (bindestreg). Postfix og Exim tillader konfiguration af en vilkårlig separator fra det juridiske tegnsæt.

Teksten til tag kan bruges til at anvende filtrering, eller at skabe engangsbrug , eller engangs e-mail adresser .

I praksis kan formvalidering af nogle websteder afvise tegn som f.eks. "+" I en e -mail -adresse - forkert behandle dem som ugyldige tegn. Dette kan føre til, at en forkert bruger modtager en e-mail, hvis "+" lydløst fjernes af et websted uden advarsel eller fejlmeddelelser. For eksempel kan en e-mail, der er beregnet til den brugerindtastede e-mailadresse foo+bar@example.com, blive sendt forkert til foobar@example.com. I andre tilfælde kan der opstå en dårlig brugeroplevelse, hvis nogle dele af et websted, f.eks. En brugerregistreringsside, tillader "+" - tegnet, mens andre dele, f.eks. En side til afmelding fra et websteds mailingliste, ikke gør det.

Validering og verifikation

E -mail -adresser bliver ofte anmodet om som input til webstedet som validering af brugerens eksistens. Andre valideringsmetoder er tilgængelige, såsom validering af mobiltelefonnummer, validering af post og faxvalidering.

En e-mailadresse er generelt anerkendt for at have to dele forbundet med et at-sign ( @ ), selvom tekniske specifikationer beskrevet i RFC 822 og efterfølgende RFC'er er mere omfattende.

Syntaktisk korrekte, verificerede e -mail -adresser garanterer ikke, at der findes en e -mail -boks. Så mange mailservere bruger forkert andre teknikker og kontrollerer postkassens eksistens i forhold til relevante systemer, f.eks. Domænenavnsystemet for domænet, eller ved hjælp af tilbagekaldsbekræftelse til at kontrollere, om postkassen findes. Tilbagekaldelsesbekræftelse er en ufuldkommen løsning, da den kan være deaktiveret for at undgå et angreb på bibliotekshøst .

Flere valideringsteknikker kan bruges til at validere en bruger -e -mail -adresse. For eksempel,

  • Bekræftelseslink: Validering af e-mailadresser opnås ofte til oprettelse af konti på websteder ved at sende en e-mail til den brugerleverede e-mailadresse med et særligt midlertidigt hyperlink. Ved modtagelse åbner brugeren linket og aktiverer straks kontoen. E -mail -adresser er også nyttige som midler til at levere beskeder fra et websted, f.eks. Brugerbeskeder, brugerhandlinger, til e -mail -indbakken.
  • Formelle og uformelle standarder: RFC 3696 giver specifikke råd til validering af internetidentifikatorer, herunder e -mail -adresser. Nogle websteder forsøger i stedet at evaluere gyldigheden af ​​e -mailadresser gennem vilkårlige standarder, f.eks. Ved at afvise adresser, der indeholder gyldige tegn, såsom + og / eller håndhæve vilkårlige længdebegrænsninger. E-mailadresse-internationalisering giver et meget større antal tegn end mange nuværende valideringsalgoritmer tillader, f.eks. Alle Unicode-tegn over U+0080, kodet som UTF-8 .
  • Algoritmiske værktøjer: Store websteder, bulkmailere og spammere kræver effektive værktøjer til at validere e -mail -adresser. Sådanne værktøjer afhænger af heuristiske algoritmer og statistiske modeller .
  • Afsenders omdømme: En e -mails afsenders omdømme kan bruges til at forsøge at kontrollere, om afsenderen er troværdig eller en potentiel spam. Faktorer, der kan indarbejdes i en vurdering af afsenderens omdømme, omfatter kvaliteten af ​​tidligere kontakt med eller indhold leveret af og engagementniveauer for afsenderens IP -adresse eller e -mailadresse.
  • Browserbaseret verifikation: HTML5-formularer, der er implementeret i mange browsere, tillader validering af e-mailadresse at blive håndteret af browseren.

Nogle virksomheder tilbyder tjenester til at validere en e -mail -adresse, ofte ved hjælp af en applikationsprogrammeringsgrænseflade , men der er ingen garanti for, at den vil give nøjagtige resultater.

Internationalisering

Den IETF gennemfører en teknisk og standarder arbejdsgruppe afsat til internationalisering spørgsmål af email-adresser, med titlen Email Adresse Internationalisering (EAI, også kendt som IMA, Internationaliseret mail-adresse). Denne gruppe producerede RFC  6530 , 6531 , 6532 og 6533 og arbejder videre med yderligere EAI-relaterede RFC'er.

IETFs EAI-arbejdsgruppe offentliggjorde RFC 6530 "Overview and Framework for Internationalized Email", som gjorde det muligt at bruge ikke-ASCII-tegn i både de lokale dele og domænet for en e-mailadresse. RFC 6530 sørger for e-mail baseret på UTF-8- kodningen, som tillader hele Unicode- repertoiret . RFC 6531 giver en mekanisme til SMTP -servere til at forhandle transmission af SMTPUTF8 -indholdet.

De grundlæggende EAI-koncepter involverer udveksling af mail i UTF-8. Selvom det oprindelige forslag indeholdt en nedgraderingsmekanisme for ældre systemer, er dette nu droppet. De lokale servere er ansvarlige for den lokale del af adressen, mens domænet ville være begrænset af reglerne for internationaliserede domænenavne , selvom det stadig sendes i UTF-8. Mail -serveren er også ansvarlig for enhver kortlægningsmekanisme mellem IMA -formularen og ethvert ASCII -alias.

EAI gør det muligt for brugere at have en lokaliseret adresse i et modersmålsscript eller et tegnsæt samt en ASCII-formular til kommunikation med ældre systemer eller til scriptuafhængig brug. Applikationer, der genkender internationaliserede domænenavne og mailadresser, skal have faciliteter til at konvertere disse repræsentationer.

Der forventes en betydelig efterspørgsel efter sådanne adresser i Kina, Japan, Rusland og andre markeder, der har store brugerbaser i et ikke-latinbaseret skrivesystem.

For eksempel, ud over .i -topdomænet, fik Indiens regering i 2011 godkendelse til ".bharat", (fra Bhārat Gaṇarājya ), skrevet i syv forskellige scripts til brug af Gujrati, Marathi, Bangali, Tamil, Telugu, Punjabi og Urdu -højttalere. Det indiske firma XgenPlus.com hævder at være verdens første EAI -postkasseudbyder, og regeringen i Rajasthan leverer nu en gratis e -mail -konto på domænet राजस्थान.भारत til hver statsborger. Et førende mediehus Rajasthan Patrika lancerede deres IDN -domæne पत्रिका.भारत med e -mail, der kan kontaktes.

Internationaliseringseksempler

Nedenstående eksempeladresser håndteres ikke af RFC 5322 -baserede servere, men er tilladt af RFC 6530. Servere, der overholder dette, vil kunne håndtere disse:

Internationaliseringsstøtte

  • Postfix mailer understøtter internationaliseret mail siden 2015-02-08 med en stabil version 3.0.0.
  • Google har support til at sende e-mails til og fra internationaliserede domæner, men tillader ikke registrering af ikke-ASCII-e-mailadresser.
  • Microsoft tilføjede lignende funktionalitet i Outlook 2016
  • DataMail lancerer internationaliseret e -mail support til 8 indiske sprog ved hjælp af XgenPlus e -mail platform i Indien.

Standarddokumenter

  • RFC  821 - Simple Mail Transfer Protocol (forældet af RFC 2821)
  • RFC  822 - Standard for formatet på ARPA Internet tekstbeskeder (forældet af RFC 2822) (Errata)
  • RFC  1035 - Domænenavne, implementering og specifikation (Errata)
  • RFC  1123 - Krav til internetværter, applikationer og support (opdateret af RFC 2821, RFC 5321) (Errata)
  • RFC  2142 - Postkassenavne til almindelige tjenester, roller og funktioner (Errata)
  • RFC  2821 - Simple Mail Transfer Protocol (Obsoletes RFC 821, Updates RFC 1123, Obsoleted by RFC 5321) (Errata)
  • RFC  2822 - Internetmeddelelsesformat (forældet RFC 822, forældet af RFC 5322) (Errata)
  • RFC  3696 - Anvendelsesteknikker til kontrol og omdannelse af navne (Errata)
  • RFC  4291 - IP Version 6 Addressing Architecture (Opdateret af RFC 5952) (Errata)
  • RFC  5321 - Simple Mail Transfer Protocol (Forældet RFC 2821, opdaterer RFC 1123) (Errata)
  • RFC  5322 - Internetmeddelelsesformat (forældet RFC 2822, opdateret af RFC 6854) (Errata)
  • RFC  5952 - En anbefaling til IPv6 -adressetekstrepræsentation (opdateringer RFC 4291) (Errata)
  • RFC  6530 - Oversigt og rammer for internationaliseret e -mail (forældede RFC 4952, 5504, 5825)
  • RFC  6531 - SMTP -udvidelse til internationaliseret e -mail (forældede RFC 5336)
  • RFC  6854 - Opdater til internetmeddelelsesformat for at tillade gruppesyntaks i "Fra:" og "Afsender:" overskriftsfelter (opdateringer RFC 5322)

Se også

Noter

Referencer

eksterne links