[php] uitlezen van een email bevestiging

[marty]

Ik heb een email proggie geschreven en ben nu net met de bevestingen van een email bezig. Een bevestiging in de headers meesturen gaat prima, echter ik wil het zelf ook detecten als er een email wordt ontvangen.
Nou kun je met imap_header() de headers van een email in een object stoppen en uitlezen, maar noch op php.net, noch hier met de search kan ik vinden hoe je daar die bevestiging uit krijgt. (die wil ik bij binnenkomende meeltjes dus uit kunnen lezen om zelf ook een bevestiging te genereren)
Kan dit uberhaupt wel, of moet ik dan heel omslachtig van de headers een grote string maken en met regular expressions aan de gang?

[Bosmonster]

Waarom niet een url waar mensen op moeten klikken? Lijkt me veel eenvoudiger

[marty]

ja handig, ik ga alle gebruikers van dat email proggie wel ff vertellen dat ze iedereen in hun adressenlijst moeten zeggen dat ze een leesbevestiging voortaan als url in de email moeten sturen omdat mijn mailprogramma er anders geen raad mee weet

[dumpie]

Ow op die manier .
Je bedoeld net zo'n leesbevestiging als bij outlook?

Volgens mij is dat niet mogelijk dan omdat het "maar" een email is.

[ Voor 35% gewijzigd door dumpie op 20-07-2003 22:35 ]

[marty]

dumpie schreef op 20 juli 2003 @ 22:25:
Ow op die manier .
Je bedoeld net zo'n leesbevestiging als bij outlook?

Volgens mij is dat niet mogelijk dan omdat het "maar" een email is.

Nou het is natuurlijk wel mogelijk
als ik een met outlook ophaal en outlook ziet dat er om een lees bevestiging gevraagd wordt dan moet dat met een eigengeschreven programma ook kunnen. Het blijft dezelfde email. Outlook doet daar echt niet iets magisch mee.

En ik weet ook wel zeker dat het kan want het staat gewoon in de headers van zo'n mail. Maar ik vind het een beetje omslachtig om die headers eerst als 1 grote string in een variabele te stoppen en daarna te gaan regexen om daar op te controleren en het email adres er uit te vissen (om 1 of andere reden staat er bij die notificatie email ook altijd nog weer eens apart een adres vermeld, dus daar houdt ik me dan ook maar aan ipv gewoon het adres van de afzender uit het 'from' gedeelte te nemen)

Maargoed, dat is mijn vraag dus ook: kan het makkelijker (voor de overige header-dingetjes zijn namelijk ook eenvoudige oplossingen), of moet ik inderdaad met zo'n regex aan de gang?

[stekkel]

Conten-type moet zijn: multipart/report;report-type=disposition-notification

in het eerste text/plain mimepart komt het gelezen blah blah verhaaltje

het tweede mime part heeft content-type message/disposition-notification
en als encoding US-ASCII

De inhoud voor deel 2: rechtstreeks uit de SquirrelMail (GNU GPL) source:

PHP:

    // part2  (RFC2298)
    $original_recipient  = $to;
    $original_message_id = $header->message_id;

    $report = "Reporting-UA : $SERVER_NAME ; SquirrelMail (version $version) \r\n";
    if ($original_recipient != '') {
        $report .= "Original-Recipient : $original_recipient\r\n";
    }
    $final_recipient = $sender;
    $report .= "Final-Recipient: rfc822; $final_recipient\r\n" .
              "Original-Message-ID : $original_message_id\r\n" .
              "Disposition: manual-action/MDN-sent-manually; displayed\r\n";

Zie verder RFC2298 voor referentie info.

NB wanneer je dit soort dingen implementeerd is het belangrijk om rfc2298 compliant te zijn anders kan je net zo goed geen leesbevestiging sturen.

[ Voor 90% gewijzigd door stekkel op 20-07-2003 23:19 ]

[eborn]

marty schreef op 20 July 2003 @ 23:01:
Maar ik vind het een beetje omslachtig om die headers eerst als 1 grote string in een variabele te stoppen en daarna te gaan regexen om daar op te controleren en het email adres er uit te vissen

Dan wil ik wel eens weten wat jij onder 'niet omslachtig' verstaat... als je dit namelijk al omslachtig vindt... Het is gewoon één van de headers, dus die moet je eruit filteren. Of je dit nou met een while-loopje doet of met een regex, dat maakt dan niet uit. Een regex is misschien lastiger, maar het is wel gewoon mogelijk.

[marty]

eborn schreef op 20 July 2003 @ 23:15:
[...]
Dan wil ik wel eens weten wat jij onder 'niet omslachtig' verstaat... als je dit namelijk al omslachtig vindt... Het is gewoon één van de headers, dus die moet je eruit filteren. Of je dit nou met een while-loopje doet of met een regex, dat maakt dan niet uit. Een regex is misschien lastiger, maar het is wel gewoon mogelijk.

Nou, ik vind het omslachtig om eerst een object te creeëren waarmee ik info uit de headers haal en vervolgens zelf nog eens 'manueel' door de headers heen te lopen. Is gewoon niet erg efficiënt. Ik heb dit email proggie juist zelf geschreven om alles wat sneller te laten lopen
Ik vraag het dus alleen omdat de manual wel eens vaker onvolledig is

stekkel: ik ben ff met google gaan zoeken naar dat RFC2298, maar kan niet echt vinden waarom dat zo belangrijk is (rfc.net is ook down op het moment). Ik neem het van je aan hoor (ze zullen het ook niet voor niets doen ), maar waarom is dat zo belangrijk dat het daarmee compliant is? Gewoon nieuwsgierigheid waarom ik dat wil weten. Heeft dat met rechtsgeldigheid van één en ander te maken?

[ Voor 56% gewijzigd door marty op 20-07-2003 23:54 ]

[eborn]

marty schreef op 20 July 2003 @ 23:28:
stekkel: ik ben ff met google gaan zoeken naar dat RFC2298, maar kan niet echt vinden waarom dat zo belangrijk is (rfc.net is ook down op het moment). Ik neem het van je aan hoor (ze zullen het ook niet voor niets doen ), maar waarom is dat zo belangrijk dat het daarmee compliant is? Gewoon nieuwsgierigheid waarom ik dat wil weten. Heeft dat met rechtsgeldigheid van één en ander te maken?

Kijk even op http://www.rfc-editor.org/

En het is slim om RFC compliant te zijn omdat je op die manier ook (99%) zeker weet dat je code werkt conform de standaard. Het heeft verder niets met rechtsgeldigheid te maken, maar wel met gebruiksvriendelijkheid en toepasbaarheid Anders weet je namelijk nooit helemaal zeker dat je het op een correcte manier hebt geimplementeerd.

[marty]

eborn schreef op 21 July 2003 @ 00:10:
[...]
Kijk even op http://www.rfc-editor.org/

En het is slim om RFC compliant te zijn omdat je op die manier ook (99%) zeker weet dat je code werkt conform de standaard. Het heeft verder niets met rechtsgeldigheid te maken, maar wel met gebruiksvriendelijkheid en toepasbaarheid Anders weet je namelijk nooit helemaal zeker dat je het op een correcte manier hebt geimplementeerd.

Maar nou geef je nog steeds niet aan waarom dat beter is.....
Volgens die post van stekkel moet ik die email helemaal in twee gedeeltes met heel veel extra header-shit sturen. Maar waarom zou ik niet gewoon een simpel emailtje sturen in plain text met de melding dat de email gelezen is? Dat is voor de gebruiker even duidelijk....

[DizzyWeb]

Omdat geen enkele mail client dan begrijpt dat een mail bevestigd is.
Outlook geeft bij een mailtje ook aan of de bevestiging ontvangen is, bijvoorbeeld.

[stekkel]

linkje naar rfc2298 http://www.ietf.org/rfc/rfc2298.txt

waarom het belangrijk is om rfc compliant te zijn:
De RFC standaard is er niet voor niets en leent zich niet voor eigen interpretatie. (Wel net zo makkelijk trouwens, hoeft je gelijk niet zo diep na te denken omdat te RFC precies verteld hoe je het moet implementeren)

Afwijkingen van rfc's veroorzaakt in het algemeen ellende. Een goed voorbeeld is het afwijken van de mime-standaard. Op het moment dat je daar van afwijkt moet je niet verwachten dat de ontvanger van de mime mail het ook kan interpreteren.

Mijn opvatting is altijd, als je iets doet doe het dan ook gelijk goed en dat is dus volgens de betreffende rfc. Dit voorkomt de minste problemen in de toekomst.

Nog een tip bij het lezen van RFC's, let heel goed op de woorden MUST, SHOULD and MAY. Die moet je dus letterlijk interpreteren.

[stekkel]

Nog een opmerking over header parsing, zo moeilijk is dat ook weer niet. allereerst moet je de header unfolden. Dit betekend een alle \r\n\s vervangen door niks. (een str_replace($string,"\t",' ')) kan ook nodig zijn wanneer er gefold wordt met \r\n\t sequences.
Het resultaat is een header met op elke lijn een key value paar.
Het header veld is dan alles voor de ':" and de waarde is alles achter de ':'.
voorbeeld:
Content-Type: multipart/alternative;
boundary=blah
wordt dan:
Content-Type: multipart/alternative; boundary=blah

Header veld is Content-Type, Waarde is multipart/alternative;boundary=blah

Zo zijn alle headers opgebouwd.

Wanneer je wilt zien hoe ik dat doe kijk dan maar op:
http://cvs.sourceforge.ne...e=text/vnd.viewcvs-markup

Dat is de Rfc822Header class die ik voor SquirrelMail geschreven heb.

Let op het is wel GNU GPL dus copy paste mag niet zomaar.

[eborn]

marty schreef op 21 juli 2003 @ 00:38:
Maar nou geef je nog steeds niet aan waarom dat beter is.....
Volgens die post van stekkel moet ik die email helemaal in twee gedeeltes met heel veel extra header-shit sturen. Maar waarom zou ik niet gewoon een simpel emailtje sturen in plain text met de melding dat de email gelezen is? Dat is voor de gebruiker even duidelijk....

Als je alleen maar een bevestiging wilt sturen dan hoef je helemaal niets met die headers te doen. Ik ging er alleen vanuit dat je de 'standaard' bevestigingsmethode wilde toepassen, en daarvoor dien je gebruik te maken van de 'standaarden' die in bovengenoemde RFC worden vermeld.

[marty]

stekkel schreef op 21 July 2003 @ 00:49:
Mijn opvatting is altijd, als je iets doet doe het dan ook gelijk goed en dat is dus volgens de betreffende rfc. Dit voorkomt de minste problemen in de toekomst.

Dat is ook zeker mijn opvatting en tegelijk de reden waarom ik er zo over doorvraag Ik wil gewoon een solide product maken, maar van domweg een standaard overnemen ben ik niet zo. Ik doe het graag volgens de regeltjes, maar wil wel de gedachte erachter graag weten.
maar ok. ik zocht er teveel achter denk ik. op een gegeven moment is er gewoon een standaard procedure bedacht en die is er nu eenmaal. niet meer en niet minder.

stekkel schreef op 21 July 2003 @ 01:01:
Nog een opmerking over header parsing, zo moeilijk is dat ook weer niet.

Nee, ik bedoelde met omslachtig ook niet moeilijk in de zin van moeilijk te programmeren, maar ik vind het gewoon een beetje zonde om eerst met imap_header() een object te creëren waar de afzender e.d. uit kan halen en dan vervolgens zelf nog eens een keer door de headers te gaan lopen om te controleren op een lees bevestiging. Dat vind ik omslachtig.

Wanneer je wilt zien hoe ik dat doe kijk dan maar op:
http://cvs.sourceforge.ne...e=text/vnd.viewcvs-markup

Dat is de Rfc822Header class die ik voor SquirrelMail geschreven heb.

stoer ziet er goed uit.
Viel me me toevallig nog een minuscuul typefoutje op:

/*
* rdc822_header class
* input: header_string or array
*/

Let op het is wel GNU GPL dus copy paste mag niet zomaar.

don't worry. die van mij is al up and running, dus dat stadium ben ik al ver voorbij Ze begonnen alleen afgelopen week om die leesbevestigingen te jammeren. Dus vandaar.

De reden dat ik er zelf één gemaakt heb en geen bestaande genomen is dat ik 'm heb verweven in een database frontend (dat ik ook zelf geschreven heb), waarbij alle emails in een database worden gepompt. Deze manier stelt me ook in staat het eenvoudig met de interne 'mailtjes' te mixen, die ik rechtstreeks de database in pomp (en dus niet via de mailserver)
Ik weet dus ook inmiddels wel hoe die headers er uit zien. Ik maak zowiezo voorlopig nog van iedere email een 'rauwe' backup die ik ook in de database zet, tot het moment dat ik (vrijwel) zeker weet dat er niets meer mis gaat.


Heb ik alleen nog een vraagje (ben wel lastig)

The following disposition-types are defined:
"displayed" [...]
"dispatched" [...]
"processed" [...]
"deleted" [...]
"denied" [...]
"failed" [...]

Ik snap die uitleg erbij wel, maar ik snap niet precies hoe die nou tot stand komen. Als ik om een leesbevestiging vraag en het meeltje naar mezelf (ander account) stuur en met outlook ophaal, maar alvorens het te openen die mail verwijder (ook uit de prullenbak), dan krijg ik geen 'bevestiging' waarbij gemeld wordt dat de mail werd gedelete. Is dat gewoon een tekortkoming van outlook? of mis ik iets...

[ Voor 5% gewijzigd door marty op 21-07-2003 02:54 ]

[stekkel]

Dat is de keuze van de client. Via MDN is het dus mogelijk om verschillende disposition types mee te geven maar de client kan het dus ook gewoon negeren. Net zoals gebruikers vaak geen MDN notification zenden.

In de praktijk is "displayed" het meest gebruikte disposition-type.

[marty]

ja, ik denk ook niet dat ik dat in ga bouwen. kan me niet voorstellen dat iemand het prettig vindt als er een notification terug gestuurd wordt dat de email linea recta in de prullenbak is geklikkerd.

nog even wat aanvullende informatie voor het archief : dat die imap_header() functie dit niet kan verwerken blijkt overigens aan de onderliggende c client te liggen. kunnen ze bij php nix aan doen. Als je iets meer met die headers wil (ook bijv. priority, om maar wat te noemen), zul je zelf de headers moeten uitpluizen

[Dutchmega]

Als je het nou via HTML doet... Als je de email bekijkt en dan een js activeert ofzo?

[marty]

Dutchmega schreef op 21 July 2003 @ 16:06:
Als je het nou via HTML doet... Als je de email bekijkt en dan een js activeert ofzo?

que ?

[Megamind]

JS wordt gedisabled door de meeste email clients, kijk maar naar die spammailtjes die je ip reggen om te checken of je account nog active is..