[PHP] Plain text mail lezen uit mailbestand

[Joen]

Geachte medetweakers,

Ik ben als uitdaging voor me zelf al een tijdje bezig met een eigen webmailsysteem.
Ik heb het wel zo ver voor elkaar dat ik aan de hand van meegegeven Content-headers plain tekst en HTML tekst mail kan laten weergeven.
Echter het komt wel eens een enkele keer voor dat men echt pure plain tekst email verzend zonder de Content-headers.
Ik weet me geen raad hoe ik dat moet uitlezen en vraga dus om jullie hulp.

Hoe ik het to nu toe doe:
- Ik lees het mailbestand regel voor regel in en iedere regel wordt in de variabele $buffer gezet ($buffer wordt dus steeds overschreven met een nieuwe regel).
- Tevens sla ik het GEHELE bericht (dus ook headers met From en To e.d.) op in een variabele $total.
- Ik tel het aantal Content-haders dat gevonden wordt. Blijft deze op 0 staan dan moet een functie in actie komen dat de plain tekst (dus zonder Content-hader uit het mailbestand haalt.

De enige eigenschap die ik van een dergelijk mailtje bemerk is dat de tekst voorafgegaan wordt door een lege regel en wordt geëindigd met 1 punt op een lege regel.

Dit is een voorbeeld van een dergelijke mail:

code:

Return-path: <[e-mail]>
Envelope-to: [e-mail]
Delivery-date: Sun, 08 Feb 2004 19:38:44 +0100
Received: from [111.111.111.111] (helo=localhost)
    by host.domein.nl with smtp (Exim 4.24)
    id 1AptpC-0003FT-GZ
    for [e-mail]; Sun, 08 Feb 2004 19:38:38 +0100
Message-Id: <[e-mail]>
From: [e-mail]
Bcc:
Date: Sun, 08 Feb 2004 19:38:38 +0100
X-Webhostprovider-MailScanner-Information: Please contact the ISP for more information
X-Webhostprovider-MailScanner: Found to be clean

test

.

De regeleindes zijn trouwens \r\n
Ik heb dus na de check of er geen Content-headers aanwezig zijn dit geschreven:

PHP:

<?php
if($tekstcount==0){
    preg_match("/[:space:]\r\n(.*?)\r\n.\r\n/si",$total,$textarray);
    echo "<pre>";
    print_r($textarray);
    echo "</pre>";
}
?>

en dit:

PHP:

<?php
if($tekstcount==0){
    preg_match("/\r\n(.*?)\r\n.\r\n/si",$total,$textarray);
    echo "<pre>";
    print_r($textarray);
    echo "</pre>";
}
?>

Maar beiden geven geen resultaat (alleen de laatste geeft een paar witregels en punt in het midden van die regels. De eerste geeft waarschuwing:

Warning: Compilation failed: POSIX named classes are supported only within a class at offset 0 at line 207

Zou iemand me kunnen helpen hoe ik dit emailbestand op de juiste manier dan zou kunnen uitlezen (er vanuit gaande dat het hele emailbestand dus in $total staat)?

[ Voor 4% gewijzigd door Joen op 09-02-2004 20:55 ]

[Joen]

Ach, had wat te weinig geprobeerd
NA wat verder proberen kwam ik er achter dat dit afdoende werkt:

PHP:

<?php
if($tekstcount==0){
    preg_match("/\r\n\r\n(.*?)\r\n.\r\n/si",$total,$textarray);
    echo "<pre>";
    print_r($textarray);
    echo "</pre>";
}
?>

Controleren op nog een extra enter ana het begin dus.
Hopelijk dat er niet nog meer andere rare mailtjes bij komen te zitten.

[Reptile209]

JeroenM_tbs schreef op 09 februari 2004 @ 20:44:
De enige eigenschap die ik van een dergelijk mailtje bemerk is dat de tekst voorafgegaan wordt door een lege regel en wordt geëindigd met 1 punt op een lege regel.

Ik kan geen PHP, maar het is wel grappig om te merken dat je nu zelf de RFC voor email (SMTP) ontdekt hebt. De opbouw van een minimaal email-bericht is (check maar eens met telnet <je popserver> 25:

220 vmx40.multikabel.net ESMTP
HELO reptile209.mutikabel.net
250 vmx40.multikabel.net Hello qn-xxx-xxx-xxx-xxx.quicknet.nl [xxx.xxx.xxx.xxx], pleased to meet you
MAIL FROM:<[e-mail]>
250 2.1.0 <[e-mail]>... Sender ok
RCPT TO:<[e-mail]>
250 2.1.5 <[e-mail]>... Recipient ok
data
354 Enter mail, end with "." on a line by itself
yo!
.
250 2.0.0 i19NkHxj020861 Message accepted for delivery

levert het volgende emailtje:

Received: by ictlx034
[... snip received-headers van de mailservers ...]
Date: Tue, 10 Feb 2004 00:49:50 +0100
From: [e-mail]
Message-id: <[e-mail]>
Content-transfer-encoding: 7BIT
X-MultiKabel-MailScanner-Information: Please contact [e-mail] for more information
X-MultiKabel-MailScanner: Found to be clean
X-MultiKabel-MailScanner-SpamCheck:
To: undisclosed-recipients:;
X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact [e-mail] for more information.
X-UTwente-MailScanner: Found to be clean

yo!
.

Oftewel: een SMTP-bericht is als volgt opgebouwd (en zo krijg jij 'm weer voor je plaat):

code:

<headers>
         <<- lege regel tussen headers en data, oftewel twee keer \r\n
<data>
.        <<- punt op de laatste regel, met ervoor en er achter \r\n

Noot: weet dan ook dat als er ergens 2 punten alleen op een regel staan, dat de client er weer 1 punt van moet maken. Anders zou het immers het einde van het bericht zijn.

Zoek de RFC van SMTP-mail er eens bij, dat maakt je leven (wat) makkelijker.

edit:

Zal je matsen: deze moet je hebben. Onderaan staan voorbeelden die tamelijk leesbaar zijn. Je kan nog ff verder zoeken naar POP3-specs, maar dit geeft eigenlijk ook al alles wat je wil weten. 't Is alleen wel vanaf de afzender bekeken.

[ Voor 10% gewijzigd door Reptile209 op 10-02-2004 01:06 ]

[Joen]

Reptile209 schreef op 10 februari 2004 @ 01:00:
[...]


Ik kan geen PHP, maar het is wel grappig om te merken dat je nu zelf de RFC voor email (SMTP) ontdekt hebt. De opbouw van een minimaal email-bericht is (check maar eens met telnet <je popserver> 25:
*knip*
Oftewel: een SMTP-bericht is als volgt opgebouwd (en zo krijg jij 'm weer voor je plaat):

code:

<headers>
         <<- lege regel tussen headers en data, oftewel twee keer \r\n
<data>
.        <<- punt op de laatste regel, met ervoor en er achter \r\n

Eh, ik ben met het POP3-protocol bezig (en dat is trouwens op poort 110 )
Maar het mailbericht wordt in princpe inderdaad ook volgens die manier over SMTP verzonden.

Noot: weet dan ook dat als er ergens 2 punten alleen op een regel staan, dat de client er weer 1 punt van moet maken. Anders zou het immers het einde van het bericht zijn.

Dat lijkt mij zeldzaam.

Zoek de RFC van SMTP-mail er eens bij, dat maakt je leven (wat) makkelijker.

edit:

Zal je matsen: deze moet je hebben. Onderaan staan voorbeelden die tamelijk leesbaar zijn. Je kan nog ff verder zoeken naar POP3-specs, maar dit geeft eigenlijk ook al alles wat je wil weten. 't Is alleen wel vanaf de afzender bekeken.

Aargh wat een gigantische documentatie....
Nee, ik zoek het liever op eigen houtje uit
Ik zeg nu aleen nog met wat replace probleempjes voor urls en emailadressen...
Vanavond denk ik maar weer verer prutsen.

[ Voor 7% gewijzigd door Joen op 10-02-2004 08:22 ]

[Reptile209]

JeroenM_tbs schreef op 10 februari 2004 @ 08:21:
[...]
Eh, ik ben met het POP3-protocol bezig (en dat is trouwens op poort 110 )
Maar het mailbericht wordt in princpe inderdaad ook volgens die manier over SMTP verzonden.

Dat weet ik, maar ik heb zelf ook ooit met een webmail-ding zitten prutsen en toen vond ik het SMTP-deel wat makkelijker te volgen. Als je weet hoe een bericht (minimaal) verzonden wordt, kan je daar een mooie basis op bouwen.

Dat lijkt mij zeldzaam.

Mij ook, maar er is wel over nagedacht . En je gaat het geheid ooit tegenkomen (Murphy anyone? )

Aargh wat een gigantische documentatie....
Nee, ik zoek het liever op eigen houtje uit
Ik zeg nu aleen nog met wat replace probleempjes voor urls en emailadressen...
Vanavond denk ik maar weer verer prutsen.

idd, vandaar de verwijzing naar de voorbeelden onderaan. En als je de inhoud even overkijkt, kom je nog wat referenties tegen naar minimale layouts enzo. En dat scheelt zo 500 pagina's leeswerk

[Joen]

Reptile209 schreef op 10 februari 2004 @ 08:28:
[...]

Dat weet ik, maar ik heb zelf ook ooit met een webmail-ding zitten prutsen en toen vond ik het SMTP-deel wat makkelijker te volgen. Als je weet hoe een bericht (minimaal) verzonden wordt, kan je daar een mooie basis op bouwen.

Daar kun je gelijk in hebben. Alhoewel ik nu ook wel een beetje weet hoe het POP3-protocol werkt, is toch het SMTP protocol gemakkelijker.

[...]

Mij ook, maar er is wel over nagedacht . En je gaat het geheid ooit tegenkomen (Murphy anyone? )

Wie was ook al weer Murphy?

[...]

idd, vandaar de verwijzing naar de voorbeelden onderaan. En als je de inhoud even overkijkt, kom je nog wat referenties tegen naar minimale layouts enzo. En dat scheelt zo 500 pagina's leeswerk

500 pagina's lezen is gezond *ahum*
Bedankt voor de link en zal ze enigszins bekijken.

[Ploink]

Waarom gebruik je niet gewoon de pop/imap functies van php zelf? Zie http://www.php.net/manual/en/ref.imap.php
Ik heb hiermee zelf al eens een 'PhpColdmail' geschreven en die was goed bruikbaar.

[LuCarD]

JeroenM_tbs schreef op 10 februari 2004 @ 08:38:
Wie was ook al weer Murphy?

[offtopic]
http://www.murphys-laws.com/murphy/murphy-true.html

[Joen]

@Ploink:
Ik wilde het op de die-hard manier doen...
En trouwens, imap is toch een apart protocol waarmee je ook mappen e.d. kunt aanmaken op een server?
Ik wil juist met alleen POP3 kunnen werken.

@LuCarD:
Naturlijk weet ik wel wie Murphy was, t was maar een grapje.
Hij bedacht de wijze zin: "alles dat fout kan gaan, gaat fout" of zo iets...

[Verwijderd]

JeroenM_tbs schreef op 10 februari 2004 @ 10:49:
@Ploink:
Ik wilde het op de die-hard manier doen...
En trouwens, imap is toch een apart protocol waarmee je ook mappen e.d. kunt aanmaken op een server?
Ik wil juist met alleen POP3 kunnen werken.

Met de imap functies van php heb je een eenvoudige manier om mail uit een POP3 box te lezen. Het kan natuurlijk altijd die-hard, maar waarom zou je het wiel opnieuw uitvinden?

[stekkel]

Reptile209 schreef op 10 februari 2004 @ 01:00:


Noot: weet dan ook dat als er ergens 2 punten alleen op een regel staan, dat de client er weer 1 punt van moet maken. Anders zou het immers het einde van het bericht zijn.

Allemaal waar, maar ik vind het wel vreemd dat de mail opgeslagen wordt zoals het verzonden met SMTP zou zijn. Normaal gesproken zijn de \r\n.\r\n bedoeld om een smtp data overdracht af te sluiten. Die \r\n.\r\n zou dus niet in het opgeslagen mailtje moeten zitten.

Zelfde geld voor die .. die zou ook niet in het opgeslagen mailtje moeten voorkomen.

Wat voor SMTP server gebruik je eigenlijk?

[Joen]

Ik test niet met mn eigen mailserver (ArgoSoft Mailserver), maar met die van mn hostingprovider en weet zo ff niet wat voor server dat is (Linux iig).

Misschien vind je het raar klinken, maar een mailtje krijg je toch binnen via POP3 zoals het via SMTP ontvangen is op de mailserver.
Haal je mail maar eens op via ene telnet-sessie naar poort 110 van de mailserver van je ISP. En zie: een punt aan het einde van je bericht!

[Reptile209]

stekkel schreef op 10 februari 2004 @ 13:27:
[...]

Allemaal waar, maar ik vind het wel vreemd dat de mail opgeslagen wordt zoals het verzonden met SMTP zou zijn. Normaal gesproken zijn de \r\n.\r\n bedoeld om een smtp data overdracht af te sluiten. Die \r\n.\r\n zou dus niet in het opgeslagen mailtje moeten zitten.

Zelfde geld voor die .. die zou ook niet in het opgeslagen mailtje moeten voorkomen.

Wat voor SMTP server gebruik je eigenlijk?

Waarom zou een SMTP-server dat soort dingen moeten gaan bewerken? 't Is toch veel gemakkelijker (en transparanter) als de client dat soort dingen pas aan het einde doet? Die heeft immers precies dezelfde markeringen nodig als de SMTP-server, namelijk een scheiding tussen headers en data en een eindpunt. En dan moet je (dus) de "dubbele punt" ook laten staan.

Vergeet ook niet dat SMTP/POP3 een van de eerste protocollen (nouja, ik roep ook maar wat) op internet waren. Eenvoud troef, vooral niet rotzooien met de data onderweg (afgezien van het toevoegen van headers op de diverse servers). Alle parsing is verder voor de client.

[Joen]

Precies, alleen tegen Spam en spoofing e.d. mag nog wel wat worden gedaan in het protocol.

[ Voor 11% gewijzigd door Joen op 10-02-2004 15:05 ]

[stekkel]

Reptile209 schreef op 10 februari 2004 @ 14:01:
[...]

Waarom zou een SMTP-server dat soort dingen moeten gaan bewerken? 't Is toch veel gemakkelijker (en transparanter) als de client dat soort dingen pas aan het einde doet? Die heeft immers precies dezelfde markeringen nodig als de SMTP-server, namelijk een scheiding tussen headers en data en een eindpunt. En dan moet je (dus) de "dubbele punt" ook laten staan.

Wanneer ik een text verzend met SMTP dan doe ik mijn SMTP communicatie en bewerk de text zodat het geschikt is om de verzenden met SMTP (het vervangen van \r\n.\r\n door \r\n..\r\n).
Het is wenselijk dat ik de oorspronkelijke text zoals die bedoeld is in mijn mailbox ontvang, dus zonder de extra toegevoegde tekens om het bericht met SMTP te versturen.
Dat betekend dus dat de SMTP server die uiteindelijk het mailtje afleverd dus die extra tekens moet weghalen omdat ik als client niet weet of het betreffende mailtje met smtp in mijn mailbox terecht is gekomen.

[Reptile209]

stekkel schreef op 10 februari 2004 @ 16:21:
[...]

Wanneer ik een text verzend met SMTP dan doe ik mijn SMTP communicatie en bewerk de text zodat het geschikt is om de verzenden met SMTP (het vervangen van \r\n.\r\n door \r\n..\r\n).
Het is wenselijk dat ik de oorspronkelijke text zoals die bedoeld is in mijn mailbox ontvang, dus zonder de extra toegevoegde tekens om het bericht met SMTP te versturen.
Dat betekend dus dat de SMTP server die uiteindelijk het mailtje afleverd dus die extra tekens moet weghalen omdat ik als client niet weet of het betreffende mailtje met smtp in mijn mailbox terecht is gekomen.

In de specs van POP3 staat ongetwijfeld precies dezelfde conventie voor die aanpassingen als bij SMTP (zou wel logisch zijn he ). Dus de "aanpassingen" die je moet doen willen alleen zeggen dat je het protocol naleeft.
Het hoeft niet, maar anders krijg je "rotzooi". Een OS moet ook nagaan op wat voor manier een HD geformatteerd is, anders kan je er niks mee. En vertel je windows/*nix/whatever dan maar eens dat "het jou niet uitmaakt hoe het er op staat, maar dat je je pr0n wil hebben" _nofi
Kortom: ieder protocol vereist wat aanpassingen en als je er mee wil werken, moet je dat naleven.

BTW, het is niet eens zozeer de SMTP-server die het bericht aanpast, maar de verzendende client. De SMTP-server verzendt het mailtje onmiddelijk als hij (zij?) een \r\n.\r\n tegenkomt. Dus als de client dat wil voorkomen (jij typt alleen een losse punt), moet hij dat escapen met nog een punt. Want dat zegt het protocol. De server doet niks anders dan dat hij moet.

offtopic:
't Gaat wel lekker offtopic zo he...

*kuch* Zo, dus je werkt met PHP. Welke versie eigenlijk? */kuch*

[stekkel]

Reptile209 schreef op 10 februari 2004 @ 16:32:
[...]
In de specs van POP3 staat ongetwijfeld precies dezelfde conventie voor die aanpassingen als bij SMTP (zou wel logisch zijn he ). Dus de "aanpassingen" die je moet doen willen alleen zeggen dat je het protocol naleeft.
Het hoeft niet, maar anders krijg je "rotzooi". Een OS moet ook nagaan op wat voor manier een HD geformatteerd is, anders kan je er niks mee. En vertel je windows/*nix/whatever dan maar eens dat "het jou niet uitmaakt hoe het er op staat, maar dat je je pr0n wil hebben" _nofi
Kortom: ieder protocol vereist wat aanpassingen en als je er mee wil werken, moet je dat naleven.

pop3 !== SMTP
En volgens mij staat er in pop3 weinig over aanpassingen. Voor zover ik weet (doe nooit wat met pop3) kan je een queue overzicht krijgen en berichten er vanaf trekken (al dan niet laten staan). That's all.

BTW, het is niet eens zozeer de SMTP-server die het bericht aanpast, maar de verzendende client. De SMTP-server verzendt het mailtje onmiddelijk als hij (zij?) een \r\n.\r\n tegenkomt. Dus als de client dat wil voorkomen (jij typt alleen een losse punt), moet hij dat escapen met nog een punt. Want dat zegt het protocol. De server doet niks anders dan dat hij moet.

Ja, weet er alles van, ik heb het SMTP deliver gebeuren van SquirrelMail geschreven en kan me de dagen nog herinneren toen ik tientallen mailtjes met puntjes er in verstuurde
Vandaar ook mijn reactie, het bericht zoals het uiteindelijk in mijn mailbox terecht komt bevat niet de extra karakters (de escaped \r\n. en de \r\n.\r\n) toegevoegd ten behoeve van de transportlayer SMTP.
Dus het ging er ff om dat de SMTP gerelateerde translatie uiteindelijk niet blijvend (dus na delivery) in je bericht blijft zitten.

offtopic:
't Gaat wel lekker offtopic zo he...

*kuch* Zo, dus je werkt met PHP. Welke versie eigenlijk? */kuch*

Sinds gisteren met php 4.3.3 (fedore core 1) daarvoor 4.2.3.

Ik kijk uit naar php 5 en de tijd wanneer het niet meer nodig is om php4 backwards compatible te zijn. Pas dan kunnen we echt leuke dingen proggen.

[Joen]

Reptile209 schreef op 10 februari 2004 @ 16:32:
[...]

*knip*
En vertel je windows/*nix/whatever dan maar eens dat "het jou niet uitmaakt hoe het er op staat, maar dat je je pr0n wil hebben" _nofi
*knip*

offtopic:
Wat betekend nu eigenlijk "nofi"? Weet er al vele afkortingen, maar deze nog niet.

offtopic:
't Gaat wel lekker offtopic zo he...

*kuch* Zo, dus je werkt met PHP. Welke versie eigenlijk? */kuch*

offtopic:
Mjup, offtopic.
Ik gebruik btw 4.3.3 op mn testserver.

/ontopic:
Ik denk dat ik mijn project maar ga staken dan. Imz it nu namelijk ook al met vreemde tekens midden in de berichten af en toe (vooral veel net voor de regeleindes).
Ik heb inmiddels door mijn project wel beter doorgekregen hoe een eenvoudige basic templateparser werkt (daarmee is het min of meer begonnen nl.)

Ik denk dat ik me maar ga storten op een eenvoudig forumpje met templateset. Ik moet alleen nog even leren een betere templateparser te schrijven dan die ik nu heb.
Iemand nog tips voor bestaande goede templateparsers die niet moeilijk in gebruik zijn?

[Reptile209]

JeroenM_tbs schreef op 10 februari 2004 @ 20:00:
[...]

offtopic:
Wat betekend nu eigenlijk "nofi"? Weet er al vele afkortingen, maar deze nog niet.

offtopic:
nofi: No Flame Intended - ik bedoel dit met een knipoog / niet kwaad
fi! fi! : Flame Intended!! - ik bedoel dit met een hele dikke knipoog wel kwaad

Ik denk dat ik mijn project maar ga staken dan. Imz it nu namelijk ook al met vreemde tekens midden in de berichten af en toe (vooral veel net voor de regeleindes).

Zijn dat niet stiekum URLEncoded strings (a-la %20 voor spaties in URLs, of & quot-dingen voor aanhalingstekens e.d.)? Ook bedoeld om te voorkomen dat er inhoud verloren gaat bij het verzenden over diverse mailplatforms. Probeer je tekst dan eens door een URL-decoder te halen; PHP heeft er vast wel eentje.
En post ze anders eens, dan hebben we meer om over te kletsen .

* Reptile209 gaat doel in leven zoeken

[Joen]

Reptile209 schreef op 10 februari 2004 @ 20:49:
Zijn dat niet stiekum URLEncoded strings (a-la %20 voor spaties in URLs, of & quot-dingen voor aanhalingstekens e.d.)? Ook bedoeld om te voorkomen dat er inhoud verloren gaat bij het verzenden over diverse mailplatforms. Probeer je tekst dan eens door een URL-decoder te halen; PHP heeft er vast wel eentje.
En post ze anders eens, dan hebben we meer om over te kletsen .

* Reptile209 gaat doel in leven zoeken

Nope.
Urldecode en rawurldecode bedoel je.
Hielp niets. Ik heb er een soort van eigengemaaktre replacefunctie voor gemaakt, maar helaas pakt die ze ook niet helemaal goed.

Nouja en mn andere probleem is dus het automatisch vervangen van emailadres en URL's (en in HTML het hele stuk met <a href=" etc. etc.). De stukken tekst worden hierbij niet geod gepakt.

* Joen gaat nu slapen en denkt nog even na over dit gebeuren.
Allicht een laatste poging in aankomend weekend.

[Verwijderd]

JeroenM_tbs schreef op 10 februari 2004 @ 20:00:
/ontopic:
Ik denk dat ik mijn project maar ga staken dan. Imz it nu namelijk ook al met vreemde tekens midden in de berichten af en toe (vooral veel net voor de regeleindes).

Wat is dat nou? Geef je zomaar op?
Probeer quoted_printable_decode er eens op los te laten.

Zie RFC 2045, punt 6.7

[Joen]

Verwijderd schreef op 11 februari 2004 @ 09:20:
[...]


Wat is dat nou? Geef je zomaar op?
Probeer quoted_printable_decode er eens op los te laten.

Zie RFC 2045, punt 6.7

Bedankt voor dit schouderklopje , dat lijkt er op dat dat wel eens zou kunnen gaan helpen.
Maar zoals ik zei: ik denk dat ik komend weekend of daarna pas verder ga.
Dit om even rustig na te kunnen denken over oplossingen e.d. en drukte omdat ik op stage ben.

[Sjaaky]

Naar mijn mening zul je echt aan de RFC's moeten wil je dit tot een succesvol einde brengen. Anders kom je steeds voor nieuwe verrassingen te staan. Nieuwe gevallen die je niet voorzien had omdat de mailclients die jij gebruikt om te testen hun mail op 1 standaard manier genereren.
Mail wordt in een aantal rfc's beschreven. Degene die tot nu genoemd zijn, zoals die van SMTP hebben niet echt veel te maken met de opbouw van de mail zelf.
Even een aantal rfc's om je op weg te helpen:
RFC 822 - Standard for the format of ARPA Internet text messages Hier staat bijv ook het formaat van een email-adres in. Dat kun je niet afleiden uit zomaar een paar voorbeelden. Bovendien is het formaat van een email-adres niet 100% te valideren dmv een regexp.
RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
Deel 4 en 5 van MIME zul je (waarschijnlijk) niet nodig hebben, maar ik zet ze er toch maar even bij.

Ik moet toegeven de RFC's nogal heavy overkomen. Maar vaak zijn hele lappen tekst gewijd aan de status van de RFC zelf en valt het inhoudelijk wel mee. Verder is het handig als je syntax regels kunt lezen (bijv rfc 822 appendix D).

Ik vind het iig heel moedig dat je eraan begint. En als dit je niet afgeschrokken heeft, veel succes!

_{Als laatste tip: Ik zou een afweging tussen een parser en een zooi regexp's maken. Een parser is in principe beter, maar waarschijnlijk wel weer lastig te implementeren in php. Misschien dat er al wel pakketten voor bestaan}

[Joen]

@Sjaaky:
Ik ben meer iemand van het "vellen & opstaan" en "tryal and error" principe: ik probeer het liever zelf uit en ik vind ook dat je vooral op die manier het beste leert.
Als jed at principe toepast dan is de documentatie van de RFC's gewoon een handige naslag.

Verder is het niet zo dat ik mijn webbased mailclient 10% compatible wil maken met alles, het is voor mij meer en uitdaging om übarhaupt zo iets aan de gang te krijgen dat de meeste gangbare mail dat in Nederland wordt ontvangen en verstuurd kan lezen.

Dat alles neemt niet weg dat ik je wel ff wil bedanken voor de links naar de RFC's

@ DarthRaider:
Mjup, dat is het dus
De betreffende mailtjes waren quoted printable geëncodeerd. Na een juiste check hierop komen de mailtjes er goed uit.

edit:
Ik kon niet wachten om het te testen dus heb mn project ff gekopieerd naar een linuxbak hier op mn stage. Had toch ff een stil moment.
Zodoende weet ik dus dat dat de oplossing is.

[ Voor 14% gewijzigd door Joen op 11-02-2004 11:25 ]