Technische kenmerken
Deze bladzijde van informatie is het minst zeker toegankelijk van
deze website. Het is noodzakelijk om een kennis van het formaat van de
berichten te hebben die per elektronische post (met name de codering
MIME)
worden overgebracht om alle details ervan te volgen.
Algemeen
Aan de oorsprong, werden de protocollen Internet voor de Verenigde
Staten van Amerika, ontwikkeld alvorens bij andere landen gebruikt te
worden.
Deze internationalisatie heeft vereist om alfabetten in aanmerking te
nemen rijker dan het Amerikaanse alfabet.
Bovendien na de fundamentele teksten, hebben de protocollen van
elektronische post de mogelijkheid geïntegreerd om teksten met opmaak
en bestanden van elke natuur te verzenden.
Helaas voor elk ondervonden probleem, werden verschillende
verschillende technische oplossingen aanvaard zonder dat, meestal,
zo'n verscheidenheid een praktisch belang heeft.
Voorts heeft de complexiteit van de normen tot gevolg dat zij niet
aan de brief door mailers worden geëerbiedigd, dat het voor
moeilijkheden van toepassing, of wegens zeer aproximative uitvoeren
is.
In de praktijk, gebruikt het merendeel van mailers een beperkte
deelverzameling van de mogelijke formaten van berichten.
Twee keuze zijn dus mogelijk:
- ofwel alle berichten proberen du mieux possible te behandelen aan
het risico om een zeer ingewikkelde toepassing te verwezenlijken
- ofwel zich tot de meest lopende gevallen beperken (die niettemin
99% van de berichten kunnen omvatten).
Het is de tweede benadering die voor Libremail is goedgekeurd.
Evenwel versie na versie, behandelt Libremail steeds meer bijzondere
gevallen, zonder echter veel ingewikkelder geworden zijn dan aan de
oorsprong.
Behandeling van mails die in functie van hun structuur worden
ontvangen
- Als ontvangen mail zich tot een zone van tekst van soort text/plain
beperkt, zal Libremail deze tekst aangeven.
- In het geval van berichten multipart/alternative (eerst van de tekst
vervolgens het equivalent in HTML), zal Libremail de afdeling tekst
van mail te kennen geven.
- Als mail in zuivere HTML (text/html) is, doet Libremail geen
omzetting om dit soort bericht leesbaar te kennen te geven.
Door tegen, is het werktuig suphtm in staat om voor download
de berichten in zuivere HTML te ontdekken en af te schaffen.
- Als een mail van soort multipart/report is, zal Libremail de
verschillende zones van tekst te kennen geven dat hij enen aan het
vervolg van de anderen bevat.
Er is geen onderzoek van bestanden die in mails van soort worden
samengevoegd, multipart/report.
- In het geval van een mail van multipart/mixed soort, zal libremail
de tekst vervat in de eerste afdeling aangeven. Naargelang het geval,
zal het zijn:
- de tekst vervat in een afdeling van soort text/plain
- onder afdeling text/plain van een afdeling multipart/alternative
- veranderde tekst van de afdeling text/html als er geen afdeling
text/plain is
Na deze display, zal Libremail de lijst van de samengevoegde
bestanden weer toevoegen die teruggekregen zullen kunnen worden. De
afdelingen text/html, die een naam van bestand bezitten, zullen
echter niet (sinds de versie 1.2.1) in aanmerking genomen worden.
Als mail afdelingen message/rfc822 bevat, zullen deze laatsten als
een mails behandeld worden, en hun tekst zal aan die van hoofdmail
weer toegevoegd worden.
Door tegen, als een mail van multipart/mixed soort verschillende
opeenvolgende zones van tekst, enig de eerste zal aangegeven worden
bevat.
In een mail multi afdeling, kan men (sinds de versie 1.1.0) verkiezen
om de afdeling text/html (zonder omzetting van de bakens) in plaats
van de afdeling te kennen te geven text/plain .
De afdelingen multipart/related worden de figurant aan het binnenste
van andere afdelingen multipart (sinds de versie 1.2.1) voor de
behandeling van de randen van afdelingen, zonder echter in aanmerking
genomen dat hun aanwezigheid geen veranderingen in de analyse van
mail tot gevolg heeft.
Structuur van de verzonden berichten
Voor de zending van mails, beperkt Libremail zich tot twee structuren
van bericht alleen maar :
- mail alleen maar gevormd van een afdeling tekst van soort text/plain
- mail van soort multipart/mixed samenstellingen van een afdeling
text/plain gevolgd door één of meer samengevoegde bestanden.
Codering van de karakters
Zoals aangegeven hierboven hoog, zijn de protocollen Internet eerst
Amerikaans geweest alvorens zich internationaal te maken. Maar de
Amerikanen bezitten 2 kenmerken die ze van het merendeel van de
volkeren van de planeet onderscheiden :
- zij bezitten een kolossale voorraad van wapens van massieve
vernieling
- hun taal bevatten geen nadruk.
Voor de elektronische post, is het het 2ste punt dat het
belangrijkst, met name parce is dat aan de oorsprong, de protocollen
Internet voor een overdracht van de karakters op 7 boorbeitels zijn
voorzien.
Onder deze omstandigheden moesten de karakters die de 8e belangrijke
boorbeitel hebben (dat wil zeggen aan 1) gecodeerd worden.
Van de rest, zelfs vandaag waar de overdracht van de karakters
op 8 boorbeitels zich heeft veralgemeend, bepaalt de norm van
overdracht dat de karakters van het opschrift van de berichten die
de 8e automatisch ingestelde belangrijke boorbeitel hebben, altijd
zullen gecodeerd worden.
Twee coderingsformaten bestaan: het formaat "quoted printable" en
het formaat base64.
- Voor de display van de velden van het opschrift van de berichten,
draagt Libremail sinds het begin de codering quoted printable
(bijna universeel) en de versie 1.0.4 de codering base64 (veel zeldzamer
zonder praktisch belang oefent met een Europees alfabet uit, anders kan
zijn die een leesbare display te verhinderen door een oude mailers, en
de filtrering van mails door de server van besteldienst direct te
compliceren vanaf het veld Subject:).
- Voor de display van de inhoud ontvangen berichten, aanvaardt
Libremail sinds het begin de direct overgebrachte teksten over 7 of 8
boorbeitels (zonder zichtbare codering aan de ontvangst), en de
berichten die aan het formaat worden gecodeerd, quoted printable.
De gecodeerde berichten worden base64 nu (sinds de versie 1.1.0),
maar met een behandeling van de sprongen van lijn oppervlakkiger
veranderd dan voor de andere formaten. Op elke wijze, is het gebruik
van deze codering voor de teksten van mails zeer zeldzaam, en
volkomen ongegrond met een Europees alfabet.
- Voor de terugwinning van de samengevoegde bestanden, de coderingen
quoted worden printable en base64 beiden sinds het begin veranderd,
(wat minder van de dingen is).
- Voor de zending van mails, verwezenlijkt Libremail automatisch een
codering quoted printable van de velden van het opschrift die
speciale karakters bevatten, terwijl het lichaam van de berichten
overbracht onder 8-boorbeitels en dus, zonder codering is.
- Om samengevoegde bestanden te verzenden, in functie van de inhoud
van deze bestanden, kiest Libremail tussen de codering quoted printable
en de codering base64, die die het minst lastig is.
Deze technische keuze passen uitstekend in de ontwikkelde landen
(bijvoorbeeld Frankrijk), maar zijn niet kan niet aan andere gebieden
van de wereld zoals Afrika (om te controleren) aangepast worden.
Als het bleek dat in deze landen, de geaccentueerde karakters juist
in de velden van opschrift (met name in het onderwerp van mail), en
de samengevoegde stukken worden overgebracht, maar niet in de tekst
van het bericht, zou men een gewijzigde versie van "envmail" moeten
creëren en gebruiken opdat deze berichten met de codering quoted
printable worden overgebracht.
Spelen van erkende karakters
- Aan de oorsprong, werd Libremail ontworpen om met het spel van
karakters per gebrek ISO-8859-15 of ISO-8859-1 te werken wanneer het
symbool € (euro) niet noodzakelijk is.
Hij kan dus zonder omzetting die mails eveneens goed aangeven
afkomstig van een PC onder Windows (tot aan de versie 98) werkt, dan
onder bepaalde verdelingen van GNU/Linux en andere UNIX.
- Een deelverzameling van de karakters (niet affichables zonder enige
wijziging) omvat in de tussenpoos 80h om 9Fh (met name gebruikt op
Mac) wordt in zijn equivalent in het spel ISO-8859-15 veranderd.
- Libremail ontdekt eveneens de codering UTF-8 en verandert de
overeenkomstige karakters wanneer zij gelijkwaardig met een aanwezig
karakter in de tussenpoos A0h om FFh van het spel ISO-8859-15
zijn.
Degenen die met een karakter van de tussenpoos 80h om 9Fh in dit spel
ISO overeenstemmen worden niet veranderd. Enerzijds zou men komen tot
karakters niet affichables, het ander vertrekt hun codering UTF-8 is
veel meer anarchistisch dan die van de karakters vanaf A0h.
Niettemin andere karakters UTF-8, waarschijnlijk van de drukletters
Mac, eveneens worden veranderd wanneer het mogelijk is.
- Sinds de versie 2.0 (en het bêta versies 1.9.2 en 1.9.3),
analyseert Libremail de variabele van milieu $LANG om het spel van
karakters te ontdekken (ISO-8859-n of UTF-8) dat door het systeem van
gebruik wordt gebruikt.
Mails die met hetzelfde spel van karakters zijn opgesteld, worden dan
die van het systeem van gebruik zonder omzetting aangegeven, de
anderen worden van ISO-8859-1 aan UTF-8 of UTF-8 aan ISO-8859-15
veranderd om een goede display van de geaccentueerde karakters toe te
laten.
Van zelfde, is het beslag van mails mogelijk eveneens goed met het
spel van karakters ISO-8859-15 dan het spel van karakters UTF-8 .
- De codering UTF-7 wordt niet per Libremail behandeld.
Uur en uurspil
Voor de display van de data en uren van expeditie van de berichten, houdt
Libremail rekening hield geen met de tijdzones tot versie 2.1.4 .
Sinds de versie 2.2 , corrigeert de bestelling vmailsj de
verschillen (in gehele uren) tussen de tijdzone van de afzender en die
van de ontvanger en er erop staat de rekening mee om een chronologisch
sorteren van te doen mails die verschillende tijdzones gebruikt.
De werktuigen die dienen om de inhoud van mails zichtbaar te maken
blijven aangeven zoals zij in mails data en uren van expeditie en zijn
tijdzone van de afzender.