[php] email parsen

[Verwijderd]

Voor een klein projectje voor mezelf ben ik een soort webmail aan het maken. Ik kan tot nu toe verbinding maken met een server en berichten binnen halen. nu wil ik berichten gaan parsen maar hier tast ik eigenlijk een beetje in het duister. ik heb het volgende in de php-manual gevonden:

L. mailparse functions

Maar ik heb het gevoel dat dit toch niet helemaal is wat ik zoek. (en de documentatie hierover is bagger slecht).

is er ergens documentatie te vinden, of misschien een paar voorbeeld-functies die mij op weg kunnen helpen?

[Steije]

Daar kan je de PEAR Mail_mimeDecode-class heel goed voor gebruiken, krijg je alles wat in een mailtje zit in een object.

PHP:

$args["include_bodies"]= TRUE;
$args["decode_bodies"]= TRUE;
$args["decode_headers"]= TRUE;
$args["input"]= $mail;

$structure= Mail_mimeDecode::decode($args);

print_r($structure);

_{Dit is overigens geen werkend voorbeeld, je moet wel PEAR aan de praat hebben en de Mail_mimeDecode class geinstalleerd hebben.}

[ Voor 110% gewijzigd door Steije op 13-07-2003 21:32 ]

[Verwijderd]

ok bedankt, het installeren was geen probleem, nu nog eventjes uit zien te vinden hoe het precies werkt

heb een mooie uitleg met voorbeelden gevonden (voor mensen die interesse hebben )

[ Voor 30% gewijzigd door Verwijderd op 13-07-2003 21:48 ]

[Verwijderd]

het parsen werkt, maar ik snap niet echt hoe ik nu een variabele kan opvangen?

code:

<?php 

include 'mimeDecode.php';

$input = "Return-path: ... ";

$params['include_bodies'] = TRUE;
$params['decode_bodies']  = TRUE;
$params['decode_headers'] = TRUE;

$decoder = new Mail_mimeDecode($input);
$structure = $decoder->decode($params);

print_r($structure);
?>

als ik deze pagina open dan krijg ik als uitvoer:

code:

stdClass Object
(
    [headers] => Array
        (
            [return-path] => <[e-mail]>
            [received] => Array
                (
                    [0] => <blaat1>
                    [1] => <blaat2>
                    [2] => <blaat3>
                    [3] => <blaat4>
                )

            [date] => Sun, 13 Jul 2003 16:38:57 +0000
            [from] => xxx
            [subject] => test
            [x-originating-ip] => [xxx.xxx.xxx.xxx]
            [to] => xxxxxxxxxxx
            [bcc] => 
            [message-id] => xxxxxxxxx
            [mime-version] => 1.0
            [content-type] => text/plain; charset=iso-8859-1; format=flowed
            [x-originating-email] => xxxxxxxxxxx
            [original-recipient] => rfc822;xxxxxxxx
            [x-originalarrivaltime] => 13 Jul 2003 16:38:57.0180 (UTC) FILETIME=[413CDDC0:01C3495D]
        )

    [ctype_primary] => text
    [ctype_secondary] => plain
    [ctype_parameters] => Array
        (
            [charset] => iso-8859-1
            [format] => flowed
        )

    [body] => dit is een test om te kijken o de parser wil werken
)

(heb wat lange nummeloze dingen vervangen dor blaat en sommige dingen door xxxxx)

staan dingen als from nu in een class die "Object" heet en zit bijvoorbeeld from in een array die in de array [headers] zit ?


edit: schrap deze vraag heb em al.
(nuttige link: http://www.evolt.org/arti...meDecode_module/18/60103/)

[ Voor 11% gewijzigd door Verwijderd op 13-07-2003 22:26 ]

[DRAFTER86]

PHP:

echo $structure->headers['from'];

[RSpliet]

helemaal leuk word het natuurlijk als je zelf het Pop3-protocol gaat leren en toepassen. Voorbeeldje:

PHP:

<?php
$fp = fsockopen(localhost,110,$a,$b,5);
if ($fp) {
   fputs($fp,"user ".$_POST['username']."\n");
   // vang info en kijk of je error terugkrijgt(ben ff te lui om alles te schrijven)
   fputs($fp,"pass ".$_POST['password']."\n");
   // zelfde hier
   // enzovoort
};
?>

Lijkt me juist veel uitdagender

[ Voor 11% gewijzigd door RSpliet op 13-07-2003 23:28 ]

[Verwijderd]

S3v3n_0f_n1n3 schreef op 13 July 2003 @ 23:28:
helemaal leuk word het natuurlijk als je zelf het Pop3-protocol gaat leren en toepassen. Voorbeeldje:
[code...]
Lijkt me juist veel uitdagender

ik snap niet wat je bedoeld? ik heb zelf al code gemaakt die de mails van de pop-server af haalt (als je dat bedoeld).

nog iets anders wat ik wou vragen: ik wou MySql als backend gebruiken (dus voor de users/userdata en de emails) maar nu vraag ik me af hoe ik dat ga doen met attachments. attachments uit een email halen zou nu moeten lullen maar zou ik die in de database op moeten slaan, of gewoon in temp-dir met een verwijzing er naar in de database?

[ Voor 49% gewijzigd door Verwijderd op 13-07-2003 23:48 ]

[marty]

misschien dat je hier wat aan heb:
http://www.melonfire.com/...s/trog/article.php?id=100

hij's een beetje verouderd, maar nog steeds wel nuttig

wat die attachments betreft:
ik heb daar ook mee zitten stoeien en sla nu gewoon in een ENUM veld een waarde op die aangeeft dat er een attachement is en vervolgens sla ik ook in een aparte tabel de naam van de attachment op (en het type - maar da's meer extra)
en die attachment sla ik vervolgens in een dir attachments/uniek_nummer/ op
als je dan die mail bekijkt weet je wat de naam is en kun je een download link maken

[ Voor 59% gewijzigd door marty op 14-07-2003 00:02 ]

[Soultaker]

Ik neem aan dat je je mailtjes ook in 'rauwe' vorm opslaat (of juist niet?) In dat geval kun je die attachments wel on-the-fly converteren naar binaire bestanden als de client ze opvraagt, en hoef je er dus in je database geen rekening mee te houden.

De motivatie om het zo te doen, zou kunnen zijn dat het mail storage/transfer systeem niets met de inhoud van de mailtjes te maken heeft. Of die mailtjes nu gecodeerd, in het Nederlands geformatteerd, plain-text, of met attachments uitgebreid zijn, is vanuit dat deel van het systeem niet relevant.

Maar goed, misschien dat je om redenen van efficientie iets anders wilt.

[marty]

Soultaker schreef op 14 July 2003 @ 01:27:
Ik neem aan dat je je mailtjes ook in 'rauwe' vorm opslaat (of juist niet?) In dat geval kun je die attachments wel on-the-fly converteren naar binaire bestanden als de client ze opvraagt, en hoef je er dus in je database geen rekening mee te houden.

ik sla op het moment nog een dump op van de email, omdat het pas net draait en ik in het geval van een bug de complete mail nog wil hebben

De motivatie om het zo te doen, zou kunnen zijn dat het mail storage/transfer systeem niets met de inhoud van de mailtjes te maken heeft. Of die mailtjes nu gecodeerd, in het Nederlands geformatteerd, plain-text, of met attachments uitgebreid zijn, is vanuit dat deel van het systeem niet relevant.

Maar goed, misschien dat je om redenen van efficientie iets anders wilt.

ik snap je motivatie nog niet helemaal. maar zal de mijne ff toelichten:
Ik sla de email helemaal in stukjes op. Dus subject, aan wie, van wie, datum, etc. etc. Komt allemaal apart in de db. Het voordeel daarvan is dat je de email maar 1 keer hoeft te verwerken (bij het ophalen) en daarna in hapklare brokken tot je beschikking heb, wat al aardig wat performance winst geeft.
Daarbij heb ik naast het email systeem ook een soort intern-email systeem gemaakt. 'lokale' emails worden dus gelijk in de database gezet, wat de server ook weer ontast. (het draait in een omgeving waarbij mensen moeten inloggen en hun email automatisch iedere 5 minuten opgehaald wordt als ze zijn ingelogd)
Door die attachments lokaal op te slaan win je vervolgens nog eens een keer performance als je emails wil forwarden, e.d. - je hoeft ze namelijk niet meer los te koppelen van de oorspronkelijke email. En ook bij het lezen van je email scheelt het natuurlijk aanzienlijk. het is veel efficienter om 1 keer die file op te slaan op schijf en daarna simpel een download linkje weer te geven, dan iedere keer weer die attachement loskoppelen van de email op het moment dat er iets mee moet gebeuren

[Reptile209]

Even een losse tip tussendoor: ik heb ooit in Delphi met een zelfde projectje zitten stoeien en ondekte dat net alle mail clients even netjes met de datum omspringen bij het verzenden. Standaards worden aan alle kanten genegeerd en zelf bedacht.
Dus als je wat wil parsen aan die datum (hangt er ook vanaf hoe strak die component er mee omgaat), hou dan wat marge voor alternatieve notaties.
(Mijn client ging even helemaal over zijn nek toen er een mailinglist-mailtje binnenkwam. Snel proggen != altijd even netjes werken )

[Verwijderd]

ok, bedankt voor de reacties. ik denk dat ik het inderdaad zo doe als marty beschrijft. als er een email binnen komt die parsen, opslaan in de db en dan een veld met namen/links (als elke email een unieke id heeft, wat ik wel van plan was te maken, kan ik de attachments opslaan in data/<gebruiker>/<id>/attachment. of ik moet aan de file zelf de id geven, dus bijvoorbeeld een mailtje met ID 2 met de attachment foto.jpg word dan 2foto.jpg. hmaar nu ik er aan denk gaat dat laatste natuurlijk ook niet werken (of ik moet het A2Afoto.jpg noemen, dat zou wel kunnen...)

en verder cronjob die om de 10 minuten mail binnen haalt voor iedereen, dan hoeft de gebruiker meestal niet zo lang te wachten omdat de server de mail nog binnen moet halen.

[ Voor 15% gewijzigd door Verwijderd op 14-07-2003 08:41 ]

[marty]

Ik heb het zo gedaan:
> checken op email
> als er een email is deze ophalen, verwerken en in de database stoppen -> op dit moment heeft de email een uniek nummer gekregen (van je auto_increment veld). stel even dat dit nummer 1234 is.
(> Er zit een attachement aan (bijvoorbeeld foto.jpg), dus ik geef in dat enum veld aan dat er een attachment aan zit)
> die attachment sla ik nu op als attachments/1234/foto.jpg en ik sla in een aparte tabel gegevens over die attachment op. (waarbij ie gelinkt is dmv het unieke nummer)
op het moment dat je de emails ophaalt moet je die attachment tabel er op joinen en kun je in het geval van een attachment gelijk een download linkje weergeven.

Het opslaan van de attachment gegevens in een aparte tabel is wellicht overbodig. Ik heb er voor gekozen omdat ik ook dingen zoals type en size op sla. Vond ik gewoon handig.
Kan bijvoorbeeld handig zijn als je wil berekenen hoeveel kbs aan attachments iemand heeft. Ik noem maar wat. Maar in princiepe zou je ook een veld attachment in je mail-tabel kunnen opnemen en daar de naam van de attachment in zetten. Als ie NULL is, dan weet je dat er geen attachment aan de mail hing en als ie een waarde bevat weet je dat er wel een attachment is, en gelijk wat de naam is.

[Verwijderd]

marty schreef op 14 juli 2003 @ 12:25:
Maar in princiepe zou je ook een veld attachment in je mail-tabel kunnen opnemen en daar de naam van de attachment in zetten. Als ie NULL is, dan weet je dat er geen attachment aan de mail hing en als ie een waarde bevat weet je dat er wel een attachment is, en gelijk wat de naam is.

En bij meerdere attachements? Die extra tabel lijkt me dus zelfs vereist

[ Voor 3% gewijzigd door Verwijderd op 14-07-2003 13:32 ]

[Verwijderd]

je kunt toch een soort structuur er in brengen bij meerdere attachments?
bijv:
attachment1.xtnsi|path/to/attachment1/attachment1.xtnsi;attachment2.xtnsi|to/attachment2/attachment2.xtnsi

(om maar ff snel een voorbeeld te geven)

maar als je gewoon een aparte tabel maakt met een entry voor elke attachment die je hebt is het natuurlijk makkelijker, je kunt dan dus inderdaad ook andere info opslaan.

[ Voor 28% gewijzigd door Verwijderd op 14-07-2003 13:43 ]

[marty]

Verwijderd schreef op 14 July 2003 @ 13:32:
[...]
En bij meerdere attachements? Die extra tabel lijkt me dus zelfs vereist

je heb gelijk

Verwijderd schreef op 14 July 2003 @ 13:42:
je kunt toch een soort structuur er in brengen bij meerdere attachments?
bijv:
attachment1.xtnsi|path/to/attachment1/attachment1.xtnsi;attachment2.xtnsi|to/attachment2/attachment2.xtnsi

(om maar ff snel een voorbeeld te geven)

Dat is geen goed idee. Nooit informatie in 1 veld opslaan die niet bij elkaar hoort. Netjes aparte entries van maken

[ Voor 54% gewijzigd door marty op 14-07-2003 16:33 ]