Email cím RFC formátum

Vitába keveredtem egy feljesztő céggel a az email-ben lévő + (plusz) karaktert illetően.

A következőt írja:

Sajnálattal tájékoztatjuk, hogy a <név>+<szöveg>@<domain> e-mail címmel sajnos nincs lehetősége regisztrálni. Az ilyen típusú e-mail címek (melyben szerepel +) már nem elfogadottak. Ez nemzetközi ajánlás, amit a fejlesztése során figyelembe vettünk.

"már nem elfogadottak." - írja

Én napi szenten használom már minden új regisztrációmnál, nagyon kevés oldalon ütköztem emiatt problémába.

Az lenne a kérdésem, hogy melyik ma érvényes RFC írja le az email címben engedélyezett karaktereket?

Köszönöm szépen a segítséget!

Hozzászólások

Szerkesztve: 2020. 04. 03., p - 11:43

bár rfc-t nem olvastam, de szerintem a + az labelezésre van, ergo a kispista@email.tld-hez tartozó cím lenne a kispista+spam@email.tld és nem külön mailbox.

már csak abból kiindulva hogy a modernebb mail szerverek (pl wildduck) is igy használja, bár lehet ők inkább gmail-t koppintották és nem szabványt követtek ezzel.

" de szerintem a + az labelezésre van "

Nem. Az RFC expliciten leírja, hogy a local-part értelmezése a host feladata. Az, hogy nála a + az label, vagy nem, azt ő majd eldönti. Az, hogy a Google anno a +-t így értelmezte, az az ő dolga (mint ahogy azt is, hogy foo.bar, fo.obar és foobar ugyanaz a local-partban számára). De ez nem jelenti azt, hogy a szintakszis szerint invalid lenne a +-t tartalmazó local-part. Az egy más kérdés, hogy mivel a host értelmezi, emiatt megkötéseket adhat.

RFC 5321, 2,3.11:
the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
Szerkesztve: 2020. 04. 03., p - 12:04

Az e-mail címek formátumát az RFC 5322 írja le. Ebbből is a 3.4-es fejezet az, amit téged érint (Address Specification):

https://tools.ietf.org/html/rfc2822#section-3.4

 

Ebből a 3.4.1 specifikálja, hogy a local-part (azaz a @ előtti) milyen formátumú.

A szintakszisa szerint:

local-part      =       dot-atom / quoted-string / obs-local-part

A ezek közül dot-atom szintakszisa megengedi, hogy legyen benne + jel (meg még egy csomó más karakter).

Viszont a local-part értelmezése a host feladata. És ő adhat speciális jelentést a +-nak (például mint a Google-nél, az egy label), emiatt megtagadhatja azt, hogy +-t tartalmazó címed legyen, hiszen a host számára az speciális jelentéssel bír.

RFC 5321, 2.3.11-es fejezet:

the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.

Tehát például dönthet úgy a host, hogy ő csak a + előtti (vagy éppen csak a + utáni) részt veszi figyelembe a mailbox meghatározásához. Szóval nem elég csak a szintakszis (az RFC 5322 megengedi a + karaktert a local-partban), a szemantikát a host dönti el (az RFC 5321 szerint a host eldöntheti, hogyan értelmezi a +-t a local partban). Teljesen valid érv, hogy ők azt mondják, + nem lehet a mailbox nevében, mert ők azt szemantikusan másra használják (mint a Google is).

Mivel itt csak a regisztrációhoz kell az email cím - levet az oldal a regisztrált felhasználó címére nem fogad csak küld felé -, így a host kérdés nem fáj nekünk.

A lényeg, hogy az a magyarázat, hogy "már nem elfogadottak" az nem állja meg a helyét. Nem spammel vagy egyébbel okolják.

De nem értem, hogy mibe telne nekik, hogy engedik a regexp-ben. Ezt nem értem.

Köszönöm a részletes magyarázatot!

Pont annyiba telik nekik, mint neked + nélküli e-mail címet csinálni. És az RFC azt mondja, hogy a host adhat megkötéseket, ők a host és megkötik ezt, tehát RFC szerint sem lehet. Náluk. És nem csak küld, adott esetben fogadhat is, akkor meg azon fogsz elpityeredni, hogy nem ért oda, hogy lehet ez? Így. Válassz másik szolgáltatót/vagy szolgáltatást ha ez a megkötés neked túl erős. Mondjuk egy alias-t csinálni a +-&#<>.,=()@tedomained.tld e-mail fiókra nem akkora ügy és akkor a + jel kikerül belőle a problémás host felé és ennyi.

+1

Vittem egy levelet a postára(EMS), a címzés rajta volt koreaiul és latin betűkkel is. Az egészet berakta egy új borítékba amin már csak a latin betűk voltak, mert azt tudta rögzíteni a gépbe. Mikor szóvá tettem azt kérdezte, hogy "Miért nem tudnak európaiul ?".  Nem volt egyszerű elérnem, hogy ott legyen a cím a címzett számára olvashatóan is.

Keveredés van.

Nem email címet hozol létre mail szolgáltatónál, hanem meglévő címmel regisztrálsz egy weboldalon. A weboldal pedig azt mondja, hogy ő nem fogad el '+'-os email címet.

Ha ez a weboldal egy közszolgáltató, egészségügyi intézmény stb nem tucat webshop, akkor nincs alternatív lehetőséged.

De nem értem, hogy mibe telne nekik, hogy engedik a regexp-ben. Ezt nem értem.

Én dolgoztam egy projekten, ahol az architect meghatározta, hogy milyen email címeket lehet elfogadni regisztrációnál.

+-t nem lehetett, .-ot igen. Amikor kérdeztem, hogy mégis miért, akkor azt magyarázta, hogy mivel a gee+alfa@ és a gee+beta@ cím ugyanaz, de a rendszer különbözőnek látná ezeket, így majd keveredés lesz, mert jön a szegény felhasználó, aki gee+alfa@ címmel regisztrált, belépne gee+beta@ címmel, és majd jól nem találja meg a saját dolgait. Lesz itt káosz meg minden.

Mondtam neki, hogy simán lehet két külön felhasználó a gee+alfa@ és gee+beta@ címek mögött. Azt is mondtam, hogy ha a felhasználó hülye, és nem tudja, hogy milyen címmel regisztrált, az ellen nem tudunk semmit tenni, mert ha regisztrál gee@gmail címről és gee@freemail címmel akar belépni, ugyanott tart majd. Ráadásul ha már gmail, jöhet ge.e@ címmel és g.ee@ címmel, és ugyanúgy külön címnek látja a mi rendszerünk, pedig egy mailbox. Sajnos nem értette meg a magyarázatot, csak ismételte mint egy törött lemez a magáét.

Sajnos néha nem az a gond, hogy technikailag nem lehet megvalósítani, hanem egyszerűen sötétség lakozik a fejekben.

Viszont ha tényleg azt akarod, hogy egy mailbox csak egyszer szerepeljen, azt nem tudod megvalósítani.

Ugyanis a local-part értelmezése a host feladata. Lehet, hogy számára Foo.Bar és fo+obar ugyanaz a mailbox. Lehet, hogy különböző. Lehet, hogy Foo/Bar ugyanaz, mint f+oobar. Nem tudhatod. Emiatt nem annyira jó az e-mail, mint egyedi azonosító, de néha nincs jobb.

És pont ezért nem szeretik a "különleges" karaktereket a címekben a szolgáltatók, mert ők nem tudják implementálni minden egyes hostra a mailboxok egyezőségét vizsgáló algoritmust, hiszen nem is ismerik azt, hostfüggő az egész.

Az esetek 99%-ban vissza kell igazolni az email címet. Ha sikeres, akkor mindegy, hogy az adott oldalon minek látszik.

Ha azt mondják esetemben, hogy nem akarják engedni az megint egy más tárgyalási alap, minthogy az hogy "már nem elfogadottak"

Kicsit OFF:

Van olyan futó projekt, ahol a megrendelő azt akarta, hogy a regisztrációkor ne email cím legyen az azonosító, hanem a felhasználó név és arra se legyenek megkötések.

Engedve a kis/nagy/ékezetes/szóköz karaktereket is. Mint az ügyfélkapun. :)

Pl ilyen vicces kódolásban érkeznek a szövegek "gipsz istvĂĄn 11", "kov?sz m?rta11" stb.

Hát szuper. :)

megírnád, kik ők? bővíteném a szégyenfalamat.

Vissza kell kérdezni hogy melyik az említett nemzetközi ajánlás. Simán lehet hogy mutatnak egyet. Ajánlás bármire lehet, a kérdés hogy kié.

gondolom azt akarjak igy kivedeni, hogy tobbszor tudj gyakorlatilag ugyanazzal az email cimmel/fiokkal (csak a + utanit varialva) regisztralni. csak nem jol csinaltak, bar vszinu bonyi lenne nekik lekezelni rendesen (pl. sql-ben keresni cimre de ugy hogy a + es a @ kozottit ignoralja)

en a sajat mailszerveremen ezert allitottam be a pontot a + helyett separatornak :)

A'rpi