lengte van email adres
Ton Masseur
kan zijn.
Of waar dit gedefinieerd is.
Dit omdat er een bestand van email adressen electronisch moet worden
opgebouwd, en dan is het toch zonde van de ruimte om te groot te
dimensioneren, maar nog veel meer zonde als een email adres van een relatie
wordt afgebroken.
Ik heb bij geruchte vernomen dat de maximale lengte 129 zou zijn, namelijk
64 voor de naam, 1 voor het @ teken en 64 voor het domain, maar of dat waar
is.....
TIA,
Ton
jan.van...@h2o.xs4all.nl
> Ik heb bij geruchte vernomen dat de maximale lengte 129 zou zijn, namelijk
> 64 voor de naam, 1 voor het @ teken en 64 voor het domain, maar of dat waar
> is.....
Helaas voor jou bestaan er ook nog subdomeinen, en is er nul restrictie op
het aantal daarvan.
pie...@klaas.wim.piet.ik.wil.een.sub.domein.op.het.net kan dus voorkomen.
Maar wat voor beest van een database ben je aan het bouwen dat die paar
bytes per record wat uitmaken ?
HDD kost zo ongeveer niks meer, en tegen de tijd dat mySQL te traag voor
je begint te worden heb je andere problemen, denk ik....
--
Dag, Jan
___________________________________________________________________
| Use finger | PGP-Fingerprint: 8D 5E 4C 23 73 3C CA A2 |
| jvha...@xs4all.nl | 90 12 EF 23 A9 60 0B EA |
| for PGP-key | He who throws mud loses ground. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reinoud van Leeuwen
wrote:
>Hier is vast wel iemand die weet hoe lang een email adres (in characters)
>kan zijn.
>Of waar dit gedefinieerd is.
>Dit omdat er een bestand van email adressen electronisch moet worden
>opgebouwd, en dan is het toch zonde van de ruimte om te groot te
>dimensioneren, maar nog veel meer zonde als een email adres van een relatie
>wordt afgebroken.
tip: kijk eens naar het datatype VARCHAR in plaats van CHAR in je
database...
__________________________________________________
"Nothing is as subjective as reality"
Reinoud van Leeuwen rei...@xs4all.nl
http://www.xs4all.nl/~reinoud
__________________________________________________
rou...@glasvezel.net
jan.van...@h2o.xs4all.nl wrote:
>"Ton Masseur" <tmas...@xs4all.nl> writes:
>> Ik heb bij geruchte vernomen dat de maximale lengte 129 zou zijn, namelijk
>> 64 voor de naam, 1 voor het @ teken en 64 voor het domain, maar of dat waar
>> is.....
>Helaas voor jou bestaan er ook nog subdomeinen, en is er nul restrictie op
>het aantal daarvan.
Uit m'n hoofd: een DNS tree kan maximaal 127 niveaus diep zijn. Elk label
mag maximaal 63 karakters lang zijn. Het geheel mag niet langer zijn dan
255 karakters.
J.
Met vriendelijke groet / Kind regards,
--
rou...@glasvezel.net - www.glasvezel.net - Rotterdam, Netherlands
PGP KeyID = 0887F1E9 - PGP fp = 24DB2D858641EDBFECADD947C4735B10
Intl. Mirrors: www.glassfibre.net (UK) - www.glassfiber.net (USA)
lo...@jthz.com
> Hier is vast wel iemand die weet hoe lang een email adres
> (in characters) kan zijn. Of waar dit gedefinieerd is.
Ik weet dat heel veel mailservers/databases moeite hebben
met het accepteren van j.@i.am , terwijl dat een
volledig valid en werkend mailadres (en domein) is.
Ton Masseur
<jan.van...@h2o.xs4all.nl> wrote in message
news:20001010.22170...@h2o.xs4all.nl...
> "Ton Masseur" <tmas...@xs4all.nl> writes:
>
> > Ik heb bij geruchte vernomen dat de maximale lengte 129 zou zijn,
namelijk
> > 64 voor de naam, 1 voor het @ teken en 64 voor het domain, maar of dat
waar
> > is.....
>
> Helaas voor jou bestaan er ook nog subdomeinen, en is er nul restrictie op
> het aantal daarvan.
> Maar wat voor beest van een database ben je aan het bouwen dat die paar
> bytes per record wat uitmaken ?
het gaat om een zakelijke database op een mainframe, je weet wel, zo'n IBM
bak met moeilijke database systemen.
Er moeten wel een paar honderdduizend adressen inkunnen (en ja, dat zijn
allemaal echte klanten die weten dat we ze opslaan:-)). En dat raadplegen
moet in tienden van seconden kunnen met honderden gebruikers tegelijk, dus
grootte en performance doen wel terzake.
En nou niet allemaal consultancy gaan aanbieden <grin> </grin>
Groet,
Ton
jan.van...@h2o.xs4all.nl
> Uit m'n hoofd: een DNS tree kan maximaal 127 niveaus diep zijn. Elk label
> mag maximaal 63 karakters lang zijn. Het geheel mag niet langer zijn dan
> 255 karakters.
Welke RFC staat dat ?
Niet dat ik denk dat er iemand een mailadres heeft dat zo lang is, je zult
het maar in moeten typen :-)
jan.van...@h2o.xs4all.nl
> het gaat om een zakelijke database op een mainframe, je weet wel, zo'n IBM
> bak met moeilijke database systemen.
Nee, sorry, dat soort zaken doe ik helaas niet.
> Er moeten wel een paar honderdduizend adressen inkunnen (en ja, dat zijn
> allemaal echte klanten die weten dat we ze opslaan:-)). En dat raadplegen
> moet in tienden van seconden kunnen met honderden gebruikers tegelijk, dus
> grootte en performance doen wel terzake.
Een paar honderdduizend valt toch ook nog wel mee ?
Maar zoals net al werd gezegd is het waarschijnlijk tot 255 tekens beperkt.
Ik zal eens kijken of ik de RFC kan vinden.
> En nou niet allemaal consultancy gaan aanbieden <grin> </grin>
Ik kijk wel uit. Voordat ik het weet is het m'n werk :-)
Reinoud van Leeuwen
wrote:
>rou...@glasvezel.net writes:
>
>> Uit m'n hoofd: een DNS tree kan maximaal 127 niveaus diep zijn. Elk label
>> mag maximaal 63 karakters lang zijn. Het geheel mag niet langer zijn dan
>> 255 karakters.
>
>Welke RFC staat dat ?
RFC 822: http://RF.Cx/rfc0822.html STANDARD FOR THE FORMAT OF ARPA
INTERNET TEXT MESSAGES
RFC 1035: http://RF.Cx/rfc1035.html : DOMAIN NAMES - IMPLEMENTATION
AND SPECIFICATION
>Niet dat ik denk dat er iemand een mailadres heeft dat zo lang is, je zult
>het maar in moeten typen :-)
Murphy werkt ook in databases hoor! je wilt niet na een half jaar je
database model moeten aanpassen voor dat *ene* adres dat er niet in
past...
jan.van...@h2o.xs4all.nl
> RFC 822: http://RF.Cx/rfc0822.html STANDARD FOR THE FORMAT OF ARPA
> INTERNET TEXT MESSAGES
Die had ik al snel gevonden, maar niks over lengte, geloof ik.
> RFC 1035: http://RF.Cx/rfc1035.html : DOMAIN NAMES - IMPLEMENTATION
> AND SPECIFICATION
Ik zal zo eens even kijken.
>>Niet dat ik denk dat er iemand een mailadres heeft dat zo lang is, je zult
>>het maar in moeten typen :-)
>
> Murphy werkt ook in databases hoor! je wilt niet na een half jaar je
> database model moeten aanpassen voor dat *ene* adres dat er niet in
> past...
Och, uurtje clickety-click en klaar.
Altijd beter dan weer bij Ria/Harry Word een schop moeten geven :-)
Rejo Zenger
>Ik weet dat heel veel mailservers/databases moeite hebben
>met het accepteren van j.@i.am , terwijl dat een
>volledig valid en werkend mailadres (en domein) is.
Weet je dat laatste zeker? Ik ben geneigd je gelijk te geven, maar als
ik RFC822 bekijk, waarin die dingen gedefineerd zijn lees ik het
volgende:
authentic = "From" ":" mailbox ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
"From" ":" 1#mailbox) ; Multiple authors
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
addr-spec = local-part "@" domain ; global address
local-part = word *("." word) ; uninterpreted
; case-preserved
Dat laatste deel staat dus voor de apestaart. Dat gedeelte kan nooit een
punt voor de at zetten, tenzij 'word' ook uit (ondermeer) een punt kan
bestaan. Mee eens?
word = atom / quoted-string
Dat deel 'word' kan dus bestaan uit een ofwel een 'atom' ofwel een
'quoted-string', geen combinatie ervan.
atom = 1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
Die laatste, de 'quoted-string', is niet interesant voor ons verhaal
omdat die dus per definitie eindigt met een '"'. Rest 'atom'. Voor
'atom' is het interesant te weten waar 'CHAR', 'specials', 'SPACE' en
'CTLs' voor staan:
; ( Octal, Decimal.)
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
De punt, waar het tenslotte om ging is decimaal 46 en behoort daarmee in
de groep CHAR en specials. Gezien er staat dat dat deel 'word' (even de
rest weglatend) kan bestaan uit ASCII character behalve een special, zou
ik dus zeggen dat een het locale deel van een adres niet op een punt mag
eindigen.
Maar uiteraard kan ik verkeerd zitten. Iemand?
-Rejo.
--
= Rejo Zenger s.r...@sisterray.xs4all.nl
= http://www.sisterray.nl PGP: see headers
--------------------------------------------------------------------------------
lo...@jthz.com
> De punt, waar het tenslotte om ging is decimaal 46 en behoort daarmee in
> de groep CHAR en specials. Gezien er staat dat dat deel 'word' (even de
> rest weglatend) kan bestaan uit ASCII character behalve een special, zou
> ik dus zeggen dat een het locale deel van een adres niet op een punt mag
> eindigen.
Tja, daar heb je een punt. Dan is de vraag denk ik meer
waarom easy.to (oh nee, nu V3) dat toestond als geldig adres
tijdens de invoer ervan, terwijl ik me nog herinner dat ze
verder heel erg streng waren en ik wel 20 nieuwe adressen
heb moeten uitproberen tot ik er 1 had die ze goedkeurden.
> Maar uiteraard kan ik verkeerd zitten. Iemand?
Servers bij het NOB en bij Vuurwerk.nl hadden een tijd lang
problemen met het domein "i.am", en "j." was daar weer wel OK,
dus ja, je hebt ze in alle soorten en maten, blijkt ;)
hoe, door wie, en of die RFC's worden interpreted,
that is the question...
--
Julius - http://jthz.com/
"A wiseguy is always right, even when he's wrong he's right. Remember that."
(Al Pacino in Carlito's Way)
Rejo Zenger
>> Maar uiteraard kan ik verkeerd zitten. Iemand?
>
>Servers bij het NOB en bij Vuurwerk.nl hadden een tijd lang
>problemen met het domein "i.am", en "j." was daar weer wel OK,
Je bedoeld dat ze 'j.' als local-part accepteerden?
Ik kan me onder andere nog een klant van mijn vorige provider herinneren
die een adres had met het local-part eindigend in een punt. Die persoon
ondervond afentoe problemen van systemen die haar adres (terecht?) niet
accepteerden.
loca...@null.net
49713897...@sisterray.xs4all.nl says...
> Je bedoeld dat ze 'j.' als local-part accepteerden?
>
> Ik kan me onder andere nog een klant van mijn vorige provider herinneren
> die een adres had met het local-part eindigend in een punt. Die persoon
> ondervond afentoe problemen van systemen die haar adres (terecht?) niet
> accepteerden.
Lotus Notes/Domino gaat ook helemaal mis. Ik heb dat ooit bij Lotus
gemeld en deze kwamen (na 2 dagen zoeken) met een oud en stoffig
document aanzetten. Geen idee meer welke RFC dat was.
Groeten, Menno.
--
It looks like Blue but it's also available in Red, or any color you
want.
http://www.xs4all.nl/~mstevens/usenet/also-available-in-red.gif
http://www.xs4all.nl/~mstevens/usenet/red.html