Email cím - Email address

Az e -mail cím azonosítja azt az e -mail fiókot, amelyre az üzeneteket kézbesítik. Míg a korai üzenetküldő rendszerek sokféle formátumot használtak a címzéshez, ma az e -mail címek bizonyos szabályokat követnek, amelyeket eredetileg az Internet Engineering Task Force (IETF) szabványosított az 1980 -as években, és frissítette az RFC  5322 és 6854 . Az e-mail cím ebben a cikkben az RFC 5322-ben található addr- specre vonatkozik, nem a címre vagy a postafiókra ; azaz egy nyers cím megjelenítési név nélkül .

Az e-mail cím, például a john.smith@example.com , egy helyi részből , a @szimbólumból és egy tartományból áll , amely lehet tartománynév vagy zárójelben lévő IP-cím . Bár a szabvány előírja a helyi része legyen a kis- és nagybetűket, azt is sürgeti, hogy a befogadó állomás szállít üzeneteket esetben független módon, például azt, hogy az e-mail rendszer a tartomány example.com élvezet Kovacs.Janos egyenértékűnek Kovacs.Janos ; egyes levelezőrendszerek még a johnsmith -vel egyenértékűnek is tekintik őket . A levelezőrendszerek gyakran korlátozzák a felhasználók névválasztását a műszakilag engedélyezett karakterek egy részhalmazára.

A nemzetközivé vált domain nevek bevezetésével haladnak az erőfeszítések annak érdekében, hogy az e-mail címekben ne ASCII karakterek legyenek.

Üzenetszállítás

Az e -mail cím két részből áll, egy helyi részből és egy tartományból; ha a tartomány tartománynév, nem pedig IP -cím, akkor az SMTP -ügyfél a tartománynév segítségével keresi meg a levélváltó IP -címét. Az e-mail címek általános formátuma a helyi tartomány @ domain , például: jsmith@[192.168.1.2], jsmith@example.com . Az SMTP kliens továbbítja az üzenetet a levelezőközpontnak, amely továbbíthatja azt egy másik levélközponthoz, amíg végül meg nem érkezik a címzett levelezőrendszerének gazdagépéhez.

Az elektronikus levelek továbbítása a szerző számítógépről és az internetes levelezőgépek között az RFC  5321 és 5322 szabványban meghatározott egyszerű levéltovábbítási protokollt (SMTP) és az RFC 6531 -es kiterjesztéseket használja. A postafiókokat elérhetik és kezelhetik a személyi számítógépeken, mobil eszközökön vagy webmail -oldalakon , az SMTP protokoll és a Postahivatal (POP) vagy az Internet Message Access Protocol (IMAP) protokoll használatával.

Amikor továbbítása e-mail üzenetek , levelező kliensek (MUAs) és Mail Transfer ügynökök (MTA) használja a domain név rendszer (DNS), hogy néz ki egy Resource Record (RR) a címzett tartománya. A levélváltó erőforrásrekord ( MX rekord ) a címzett levelezőszerverének nevét tartalmazza. MX rekord hiányában egy címrekord ( A vagy AAAA ) közvetlenül meghatározza a levélgazdát .

Az e -mail cím helyi része a végső postafiók -gazdától eltérő közbenső levéltovábbító rendszerek szempontjából nincs jelentősége. Az e-mail küldők és a közbenső továbbítórendszerek nem feltételezhetik, hogy a kis- és nagybetűket megkülönböztetik, mivel a végső postafiók-gazda kezelheti vagy nem kezelheti azt. Egy postafiók több e -mail címre is kaphat levelet, ha a rendszergazda beállította. Ezzel szemben egyetlen e -mail cím lehet a sok postafiók terjesztési listájának álneve. Az e-mail álnevek , az elektronikus levelezőlisták , az alcímzés és az összes cím, az utóbbi olyan postafiók, amely a helyi résztől függetlenül fogadja az üzeneteket, gyakori minták a különböző kézbesítési célok elérésében.

Az e -mail fejlécmezőiben található címeket a levelezőközpontok nem közvetlenül használják az üzenet kézbesítésére. Az e -mail üzenet borítékot is tartalmaz, amely tartalmazza a levéltovábbításhoz szükséges információkat. Bár a boríték és a fejléc címe megegyezhet, a hamisított e -mail címeket - más néven hamisított e -mail címeket - gyakran látják a spamekben , az adathalászokban és sok más internetes csalásban. Ez számos kezdeményezéshez vezetett, amelyek célja a csaló e -mailek ilyen hamisítványainak könnyebb felismerése.

Szintaxis

Az e-mail cím formátuma a local-part@domain , ahol a helyi rész akár 64 oktett hosszú is lehet, a tartomány pedig legfeljebb 255 oktet. A formális definíciók az RFC 5322 -ben (3.2.3. És 3.4.1. Szakasz) és az RFC 5321 -ben találhatók - olvashatóbb formában az információs RFC 3696 -ban és a kapcsolódó hibákban.

Az e -mail címekhez a címzetthez tartozó megjelenített név is tartozhat, amely megelőzi a cím megadását, és most szögletes zárójelek veszik körül, például: John Smith <john.smith@example.org> .

Az interneten kívüli más hálózatok e -mail címeinek korábbi formái tartalmaztak más jelöléseket, például az X.400 által előírtakat , és az UUCP bang path jelölést, amelyben a címet egy számítógépsorozat formájában adták meg, amelyen keresztül az üzenetet közvetíteni kell. Ezt évek óta széles körben alkalmazták, de az Internet Engineering Task Force (IETF) által kihirdetett internetes szabványok felváltották .

Helyi rész

Az e-mail cím helyi része lehet idézetlen, vagy idézőjelbe kerülhet.

Ha nincs idézet, akkor az alábbi ASCII karakterek bármelyikét használhatja :

  • kis- és nagybetűs latin betűk Aa Zés aa címzetthezz
  • számjegy 0a9
  • nyomtatható karakterek !#$%&'*+-/=?^_`{|}~
  • pont ., feltéve, hogy nem az első vagy az utolsó karakter, és feltéve, hogy nem egymás után jelenik meg (pl John..Doe@example.com. nem megengedett).

Ha idézzük, akkor tartalmazhat szóközt, vízszintes fület (HT), bármely ASCII grafikát, kivéve a fordított perjelet és az idézetet, valamint egy idézőpárt, amely egy fordított perjelet, majd HT, szóköz vagy bármely ASCII grafikát tartalmaz; az is sorokra osztható, ahol a HT vagy a Space megjelenik. Ezzel szemben a nem jegyzett helyi részei, a címeket ".John.Doe"@example.com, "John.Doe."@example.comés "John..Doe"@example.comengedélyezett.

Az e-mail cím helyi részének maximális teljes hossza 64 oktett.

Ne feledje, hogy egyes levelezőszerverek támogatják a helyi részek helyettesítő karakterének felismerését, általában a pluszt követő karaktereket, és ritkábban a mínuszt követő karaktereket, így a fred+bah@domain és a fred+foo@domain ugyanabban a postaládában kerülhet, mint a fred+@domain vagy akár fred@domain. Ez hasznos lehet az e -mailek címkézéséhez rendezéshez (lásd alább), és a spam ellenőrzéséhez. Merevítők {és }ilyen módon is használják, bár ritkábban.

  • a szóköz és a speciális karakterek "(),:;<>@[\]korlátozásokkal megengedettek (csak az idézett karakterláncon belül megengedettek, az alábbi bekezdésben leírtak szerint, és ebben az idézett karakterláncban minden fordított perjelet vagy dupla idézőjelet egyszer egy fordított perjelnek kell megelőznie);
  • megjegyzések zárójelben megengedettek a helyi rész mindkét végén; pl john.smith(comment)@example.comés (comment)john.smith@example.commindkettő egyenértékű john.smith@example.com.

A fenti ASCII karaktereken kívül az U+007F feletti, UTF-8 kódolású nemzetközi karaktereket is engedélyezi az RFC 6531, bár még az SMTPUTF8 és 8BITMIME támogató levelezőrendszerek is korlátozhatják, hogy mely karaktereket kell használni a helyi alkatrészek hozzárendelésénél.

A helyi rész vagy Dot-string vagy Quoted-string; nem lehet kombináció. Az idézett karakterláncokat és karaktereket azonban nem gyakran használják. Az RFC 5321 arra is figyelmeztet, hogy "a levelek fogadását váró gazdagépnek el kell kerülnie a postafiókok meghatározását, ahol a Helyi rész megköveteli (vagy használja) az idézőjeles űrlapot".

A helyi részt postmasterkülön kezelik-a kis- és nagybetűk megkülönböztethetetlenek, és továbbítani kell a domain e-mail rendszergazdájához. Technikailag minden más helyi alkatrész kis- és nagybetűket, ezért jsmith@example.comés JSmith@example.comadja meg különböző postafiókok; azonban sok szervezet a nagy- és kisbetűket egyenértékűnek tekinti. Valójában az RFC 5321 figyelmeztet arra, hogy "a levelek fogadását váró gazdagépnek el kell kerülnie a postafiókok meghatározását, ahol ... a helyi rész kis- és nagybetűket érzékeny".

A műszakilag érvényes speciális karakterek széles skálája ellenére a szervezetek, levelező szolgáltatások, levelezőszerverek és levelezőprogramok a gyakorlatban gyakran nem fogadják el mindegyiket. Például a Windows Live Hotmail csak e -mail címek létrehozását teszi lehetővé alfanumerikus, pont ( .), aláhúzás ( _) és kötőjel ( -) használatával. Általános tanács, hogy ne használjon speciális karaktereket, hogy elkerülje az e -mailek elutasításának kockázatát.

Tartomány

Az e-mail cím tartománynév- részének meg kell felelnie a szigorú irányelveknek: meg kell felelnie a gazdagépnév követelményeinek , a ponttal elválasztott DNS- címkék listájának , mindegyik címke legfeljebb 63 karakter hosszúságú, és a következőkből áll:

  • nagy- és kisbetűs latin betűk Aa Zés afelé z;
  • számjegy 0az 9, feltéve, hogy a felső szintű domain nevek nem minden numerikus;
  • kötőjel -, feltéve, hogy nem az első vagy az utolsó karakter.

Ezt a szabályt LDH -szabálynak nevezik (betűk, számjegyek, kötőjelek). Ezenkívül a tartomány lehet IP -cím literál, szögletes zárójelekkel körülvéve [], például jsmith@[192.168.2.1]vagy jsmith@[IPv6:2001:db8::1], bár ez ritkán fordul elő, kivéve az e -mail levélszemétben . A nemzetközivé vált domainnevek (amelyek kódolva vannak, hogy megfeleljenek a gazdagépnévre vonatkozó követelményeknek ) lehetővé teszik nem ASCII tartományok megjelenítését. Az RFC 6531 és RFC 6532 szabványnak megfelelő levelezőrendszerekben az e-mail cím UTF-8 kódolású lehet , mind helyi, mind tartománynévként.

A megjegyzések megengedettek a tartományban és a helyi részben is; például, john.smith@(comment)example.comés john.smith@example.com(comment)egyenértékűek a john.smith@example.com.

Foglalt domainek

Az RFC  2606 meghatározza, hogy bizonyos tartományok, például a dokumentálásra és tesztelésre szánt tartományok, ne legyenek feloldhatóak, és ennek következtében a bennük lévő postaládákhoz és azok aldomainjeihez tartozó levelek ne legyenek kézbesíthetők. Az e-mailek közül említésre méltóak a példa , érvénytelen , example.com , example.net és example.org .

Példák

Érvényes e -mail címek
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( user.name@example.coma levelezőszervertől függően a Beérkező levelek mappába kerülhet )
x@example.com (egybetűs helyi rész)
example-indeed@strange-example.com
test/test@test.com (a perjelek nyomtatható karakterek, és megengedett)
admin@mailserver1(helyi domain név TLD nélkül , bár az ICANN erősen elriasztja a pont nélküli e -mail címeket)
example@s.example(lásd az Internet legfelső szintű tartományok listáját )
" "@example.org (szóköz az idézetek között)
"john..doe"@example.org (idézett kettős pont)
mailhost!username@example.org (uucp -küldőknél használt bangified host útvonal)
user%example.com@example.org (% menekült e -mail útvonal a user@example.com címre example.org -on keresztül)
user-@example.org (a helyi rész nem alfanumerikus karakterrel végződik az engedélyezett nyomtatható karakterek listájából)


Érvénytelen e -mail címek
Abc.example.com (nincs @ karakter)
A@b@c@example.com (csak egy @ megengedett az idézőjeleken kívül)
a"b(c)d,e:f;g<h>i[j\k]l@example.com (a helyi részben található speciális karakterek egyike sem megengedett az idézőjeleken kívül)
just"not"right@example.com (az idézett karakterláncokat ponttal kell elválasztani, vagy az egyetlen elem, amely a helyi részt alkotja)
this is"not\allowed@example.com (szóközök, idézőjelek és fordított perjelek csak akkor létezhetnek, ha idézőjelen belül vannak, és előtte egy fordított perjel)
this\ still\"not\\allowed@example.com (még akkor is, ha elhagyta (előtte egy fordított perjel), a szóközöket, idézőjeleket és fordított perjeleket továbbra is idézőjeleknek kell tartalmazniuk)
1234567890123456789012345678901234567890123456789012345678901234+x@example.com (a helyi rész 64 karakternél hosszabb)
i_like_underscore@but_its_not_allowed_in_this_part.example.com (Az aláhúzás nem engedélyezett a domain részben)
QA[icon]CHOCOLATE[icon]@test.com (ikon karakterek)

Gyakori helyi részi szemantika

Az RFC 5321 2.3.11 postafiókja és címe szerint "... a helyi részt csak a címtartományban megadott gazda értelmezheti és rendelheti hozzá szemantikát." Ez azt jelenti, hogy nem lehet feltételezni egy másik levelezőszerver helyi részének jelentését. Ez teljesen a levelezőszerver konfigurációjától függ.

Helyi rész normalizálása

Az e -mail cím helyi részének értelmezése a levelezőszerveren alkalmazott konvencióktól és házirendektől függ. Például a kis- és nagybetűk megkülönböztetése megkülönböztetheti a postafiókokat, amelyek csak a helyi rész karaktereinek nagybetűiben különböznek, bár ez nem túl gyakori. A Gmail figyelmen kívül hagy minden pontot a @gmail.com cím helyi részén a fiók azonosságának meghatározása céljából.

Alcímzés

Egyes levelezőszolgáltatások támogatják a helyi részben található címkét, így a cím a helyi rész előtagjának álneve. Például a joeuser+tag@example.com cím ugyanazt a szállítási címet jelöli, mint a joeuser@example.com . RFC 5233, utal, hogy ez Egyezmény Alácímzés , de az is ismert, mint plusz címzés , címkézett címzés vagy Mail Extensions .

Az űrlap címét az alapnév és a címke különböző elválasztóit használva számos e -mail szolgáltatás támogatja, beleértve az Andrew Project (plusz), a Runbox (plusz), a Gmail (plusz), a Rackspace (plusz), a Yahoo! Mail Plus (kötőjel), az Apple iCloud (plusz), Outlook.com (plusz), ProtonMail (plusz), FastMail (plusz és aldomain címzés), postale.io (plusz), Pf (plusz), MeMail (plusz), MMDF (egyenlő), Qmail és Courier Mail Server (kötőjel). A Postfix és az Exim lehetővé teszi tetszőleges elválasztó konfigurálását a jogi karakterkészletből.

A címke szövege felhasználható szűrés alkalmazására , vagy egyszer használatos vagy eldobható e-mail címek létrehozására .

A gyakorlatban egyes webhelyek űrlapellenőrzése elutasíthatja a karaktereket, például a "+" karaktereket az e -mail címekben - helytelenül érvénytelen karakterekként kezelve őket. Ez ahhoz vezethet, hogy helytelen felhasználó kap e-mailt, ha a "+" jelzést egy webhely csendben eltávolítja figyelmeztető vagy hibaüzenetek nélkül. Például a felhasználó által megadott foo+bar@example.com e-mail címre küldött e-mailt helytelenül lehet elküldeni a foobar@example.com címre. Más esetekben gyenge felhasználói élmény fordulhat elő, ha a webhely egyes részei, például a felhasználói regisztrációs oldal, engedélyezik a "+" karaktert, míg más részek, például a webhely levelezőlistájáról való leiratkozáshoz szükséges oldalak nem.

Érvényesítés és ellenőrzés

Az e -mail címeket gyakran kérik be a webhelyre való bemenetként a felhasználók létezésének igazolására. Más érvényesítési módszerek is rendelkezésre állnak, mint például a mobiltelefonszám érvényesítése, a postai érvényesítés és a fax érvényesítése.

Az e-mail címet általában úgy ismerik el, hogy két részből áll egy jel ( @ ), noha az RFC 822 és az azt követő RFC-k részletes műszaki leírást tartalmaznak.

A szintaktikailag helyes, ellenőrzött e -mail címek nem garantálják, hogy létezik e -mail fiók . Így sok levelezőszerver helytelenül használ más technikákat, és ellenőrzi a postafiók létezését a megfelelő rendszerekkel, például a tartományhoz tartozó tartománynévrendszerrel, vagy visszahívási ellenőrzéssel ellenőrzi, hogy létezik -e a postafiók. A visszahívási ellenőrzés tökéletlen megoldás, mivel letiltható a címtárgyűjtési támadás elkerülése érdekében .

A felhasználó e -mail címének érvényesítésére több érvényesítési technika is használható. Például,

  • Ellenőrző linkek: Az e-mail cím ellenőrzését gyakran végzik el a fiókok létrehozásakor a webhelyeken úgy, hogy e-mailt küldenek a felhasználó által megadott e-mail címre egy speciális ideiglenes hiperhivatkozással. Az átvétel után a felhasználó megnyitja a linket, és azonnal aktiválja a fiókot. Az e -mail címek arra is hasznosak, hogy üzeneteket juttassanak el egy webhelyről, például felhasználói üzeneteket, felhasználói műveleteket az e -mail postaládájába.
  • Formális és informális szabványok: Az RFC 3696 konkrét tanácsokat ad az internetes azonosítók, beleértve az e -mail címeket, érvényesítéséhez. Egyes weboldalak ehelyett önkényes szabványokon keresztül próbálják értékelni az e -mail címek érvényességét, például elutasítják az érvényes karaktereket tartalmazó címeket, például a + és / vagy az önkényes hosszkorlátozásokat. Az e-mail-címek nemzetközivé tétele sokkal nagyobb karaktertartományt biztosít, mint azt sok jelenlegi érvényesítési algoritmus lehetővé teszi, például minden U+0080 feletti Unicode-karaktert, UTF-8 kódolással .
  • Feladó hírneve: Az e -mail feladó hírnevével lehet ellenőrizni, hogy a feladó megbízható -e vagy potenciális levélszemétküldő. A feladó hírnevének értékelésébe beépíthetők a küldő IP -címének vagy e -mail -címének korábbi kapcsolattartásának minősége vagy az általa biztosított tartalom, valamint az elkötelezettségi szint.
  • Böngészőalapú ellenőrzés: A sok böngészőben megvalósított HTML5 űrlapok lehetővé teszik az e-mail cím ellenőrzését a böngészőben.

Egyes vállalatok szolgáltatásokat kínálnak az e -mail cím érvényesítésére, gyakran alkalmazásprogramozási felületet használva , de nincs garancia arra, hogy az pontos eredményeket fog nyújtani.

Nemzetköziesedés

Az IETF végez műszaki és szabványok munkacsoport szentelt nemzetközi kérdések e-mail címek című e-mail cím Nemzetközivé (EAI, más néven IMA, nemzetközivé mail cím). Ez a csoport RFC  6530 , 6531 , 6532 és 6533 gyártású , és továbbra is dolgozik további EAI-val kapcsolatos RFC-ken.

Az IETF EAI munkacsoportja közzétette az RFC 6530 "Overview and Framework for Internationalised Email" áttekintést és keretrendszert, amely lehetővé tette a nem ASCII karakterek használatát az e-mail cím helyi részeiben és tartományában. Az RFC 6530 az UTF-8 kódoláson alapuló e-mailezést biztosít , amely lehetővé teszi a Unicode teljes repertoárját . Az RFC 6531 mechanizmust biztosít az SMTP -kiszolgálók számára, hogy megbeszéljék az SMTPUTF8 -tartalom továbbítását .

Az EAI alapkoncepciói között szerepel az UTF-8-ban levélváltás. Bár az eredeti javaslat a korábbi rendszerek leminősítési mechanizmusát tartalmazta, ezt most elvetették. A helyi kiszolgálók felelősek a cím helyi részéért, míg a domaint az internacionalizált domain nevek szabályai korlátozzák , bár továbbra is UTF-8-ban továbbítják. A levelezőszerver felelős az IMA űrlap és az ASCII álnevek közötti leképezési mechanizmusokért is.

Az EAI lehetővé teszi a felhasználók számára, hogy lokalizált címet kapjanak anyanyelvi szkriptben vagy karakterkészletben, valamint ASCII-űrlapot a régebbi rendszerekkel való kommunikációhoz vagy szkriptfüggetlen használatra. A nemzetközivé vált domainneveket és e -mail címeket felismerő alkalmazásoknak rendelkezniük kell ezen ábrázolások konvertálására alkalmas eszközökkel.

Jelentős kereslet várható az ilyen címekre Kínában, Japánban, Oroszországban és más piacokon, amelyek nagy felhasználói bázissal rendelkeznek, nem latin alapú írási rendszerben.

Például a .in legfelső szintű domain mellett 2011-ben India kormánya jóváhagyta a ".bharat" ( Bhārat Gaṇarājya ), hét különböző szkriptben írva , Gujrati, Marathi, Bangali, Tamil, Telugu, pandzsábi és urdu hangszórók. Az indiai XgenPlus.com cég állítja, hogy a világ első EAI postafiók -szolgáltatója, és Rajasthan kormánya mostantól ingyenes e -mail fiókot biztosít a राजस्थान.भारत domainben az állam minden állampolgára számára. A Rajasthan Patrika egyik vezető médiaháza elérhető e -mail címmel indította el IDN domainjét पत्रिका.भारत.

Nemzetközi példák

Az alábbi példacímeket nem az RFC 5322 alapú kiszolgálók kezelik, de az RFC 6530 engedélyezi őket. Az ennek megfelelő kiszolgálók képesek lesznek kezelni ezeket:

Nemzetköziesítés támogatása

  • A Postfix levelező támogatja a nemzetközivé vált leveleket 2015-02-08 óta, stabil 3.0.0 kiadással.
  • A Google támogatja az e-mailek küldését a nemzetközivé vált domainekre és onnan, de nem engedélyezi a nem ASCII e-mail címek regisztrálását.
  • A Microsoft hasonló funkciókat adott hozzá az Outlook 2016 -hoz
  • A DataMail nemzetközivé vált e -mail támogatást indít 8 indiai nyelvre az XgenPlus e -mail platform segítségével Indiában.

Standard dokumentumok

  • RFC  821 - Egyszerű levélátviteli protokoll (az RFC 2821 elavult)
  • RFC  822 - szabvány az ARPA internetes szöveges üzenetek formátumához (az RFC 2822 elavult) (Errata)
  • RFC  1035 - Tartománynevek, megvalósítás és specifikáció (Errata)
  • RFC  1123 - Internetszolgáltatókra, alkalmazásokra és támogatásra vonatkozó követelmények (Frissítve: RFC 2821, RFC 5321) (Errata)
  • RFC  2142 - Postafióknevek a közös szolgáltatásokhoz, szerepekhez és funkciókhoz (Errata)
  • RFC  2821 - Egyszerű levélátviteli protokoll (RFC 821 elavult, RFC 1123 frissítések, RFC 5321 elavult) (hiba)
  • RFC  2822 - Internetes üzenetformátum (Az RFC 822 elavult, az RFC 5322 elavult) (Errata)
  • RFC  3696 - Alkalmazási technikák a nevek ellenőrzéséhez és átalakításához (hibák)
  • RFC  4291 - IP verzió 6 címzési architektúra (frissítette: RFC 5952) (Errata)
  • RFC  5321 - Egyszerű levélátviteli protokoll (Az RFC 2821 elavult, az RFC 1123 frissítése) (hiba)
  • RFC  5322 - Internetes üzenetformátum (Az RFC 2822 elavult, az RFC 6854 frissítette) (Errata)
  • RFC  5952 - Ajánlás az IPv6 cím szövegének megjelenítéséhez (RFC 4291 frissítések) (Errata)
  • RFC  6530 - Áttekintés és keretrendszer a nemzetközivé vált e -mailekhez (elavult RFC 4952, 5504, 5825)
  • RFC  6531 - SMTP kiterjesztés az internacionalizált e -mailekhez (elavult RFC 5336)
  • RFC  6854 - Frissítés az internetes üzenetformátumra, hogy engedélyezze a csoport szintaxisát a „Feladó:” és a „Feladó:” fejlécmezőkben (Frissítések RFC 5322)

Lásd még

Megjegyzések

Hivatkozások

Külső linkek