E-mail attachements

[Verwijderd]

Er is door mij een e-mail viewer gemaakt in PHP welke de ruwe MIME mailtjes weergeeft. Nu werkt dit systeem al een lange tijd goed. Vandaag kreeg ik echter een melding dat bij een mailtje de bijlages niet worden getoond. In ruwe vorm ziet de mail er zo uit:

code:

Content-Type: multipart/alternative; boundary="Apple-Mail-7-419225385"

--Apple-Mail-7-419225385
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable

Plain deel

--Apple-Mail-7-419225385
Content-Type: multipart/mixed; boundary="Apple-Mail-8-419225385"

--Apple-Mail-8-419225385
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

HTML deel

--Apple-Mail-8-419225385
Content-Disposition: inline; filename="bijlage.pdf"
Content-Type: application/pdf; x-unix-mode=0644; name="bijlage.pdf"
Content-Transfer-Encoding: base64

Lange base64 string

--Apple-Mail-8-419225385
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Text

--Apple-Mail-8-419225385--

--Apple-Mail-7-419225385--

Zoals je ziet is de hoofd content-type: multipart/alternative. Dat bevat vervolgens een deel text/plain deel (deel 1) en een deel 2: multipart/mixed. Dit tweede deel bevat de attachments.

Ik interpreteer multipart/alternative als: "The multipart/alternative subtype indicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header." (Wikipedia: MIME)

Ook volgens rfc2046 (http://www.ietf.org/rfc/rfc2046.txt): "In particular,
each of the body parts is an "alternative" version of the same
information."

Oftewel, technisch gezien heeft deze e-mail geen bijlages. Het tweede deel van de multipart/alternative bevat de bijlages.

Outlook toont de bijlages echter wel. Echter mijn viewer niet.

Feitelijk gezien heeft de mail toch geen bijlages? Die zijn toch alleen aanwezig bij een multipart/mixed of een content-disposition: attachment?

Ik kan geen manier verzinnen om dit netjes op te lossen, aangezien ik standaard de text/plain toon (i.v.m. XSS). Er kan natuurlijk wel gekeken worden of er een deel multipart/mixed in aanwezig is binnen de container multipart/alternative, maar is er geen nettere manier?


Graag jullie ideeën.

[ Voor 5% gewijzigd door Verwijderd op 16-06-2009 13:35 ]

[Remus]

De structuur lijkt mij op zich niet helemaal correct. Maar het lijkt erop dat de multipart/alternative een plain-text versie bevat en een multipart/mixed met daarin de HTML-versie van het bericht en de diverse bijlagen.

Er zijn dus weldegelijk bijlagen en - als ik mij goed herinner - de MIME-standaard staat toe dat je bijlagen arbitrair diep nest . Ik zou als ik jou was dus recursief de multipart delen doorgaan en op zoek gaan naar (potentiele) bijlagen.

Het lijkt er mij op dat het multipart/mixed deel er 'eerder' was en dat Apple mail die heeft opgenomen in een multipart/alternative om er ook een tekst versie bij te voegen.

[Verwijderd]

Remus schreef op maandag 15 juni 2009 @ 17:04:
Er zijn dus weldegelijk bijlagen en - als ik mij goed herinner - de MIME-standaard staat toe dat je bijlagen arbitrair diep nest . Ik zou als ik jou was dus recursief de multipart delen doorgaan en op zoek gaan naar (potentiele) bijlagen.

Heb je toevallig een RFC? Ik weet het graag zeker voordat ik wijzingen aanbreng in de bestaande parser.

[Woy]

Verwijderd schreef op dinsdag 16 juni 2009 @ 11:47:
[...]
Heb je toevallig een RFC? Ik weet het graag zeker voordat ik wijzingen aanbreng in de bestaande parser.

Iets meer moeite kan je zelf ook wel doen
[google=RFC mime multipart]

[Verwijderd]

Woy schreef op dinsdag 16 juni 2009 @ 11:56:
[...]

Iets meer moeite kan je zelf ook wel doen
[google=RFC mime multipart]

De RFC's m.b.t.multipart kan ik zelf vinden. Ik verwijs er zelfs naar! Echter kan ik nergens de juiste RFC vinden waarin staat in welke partjes (en eventueel de diepte) ik moet zoeken naar attachments. Dat is waar ik naar vraag.

[Remus]

Verwijderd schreef op dinsdag 16 juni 2009 @ 13:36:
[...]


De RFC's m.b.t.multipart kan ik zelf vinden. Ik verwijs er zelfs naar! Echter kan ik nergens de juiste RFC vinden waarin staat in welke partjes (en eventueel de diepte) ik moet zoeken naar attachments. Dat is waar ik naar vraag.

Het kan arbitrair diep zijn, zeker als je berichten stuurt met message/rfc822 attachments (waarin dus ook weer multiparts en attachments kunnen zitten etc etc). Zie bijvoorbeeld RFC 2049 hoofdstuk 2 MIME conformance. Uit de stappen beschreven in RFC 2049 hoofdstuk 4 Canonical Encoding Model blijkt dat ook. Verder is de beschrijving in RFC 2049 paragraaf 5.1 ook duidelijk:

The use of a media type of "multipart" in a body part within another "multipart" entity is explicitly allowed. In such cases, for obvious reasons, care must be taken to ensure that each nested "multipart" entity uses a different boundary delimiter. See RFC 2049 for an example of nested "multipart" entities.

Het bericht uit je TS had volgens mij overigens als volgt opgebouwd horen zijn:

code:

multipart/mixed(
    multipart/alternative(
        text/plain, 
        text/html
    ),
    ... de attachments
)

[ Voor 1% gewijzigd door Remus op 16-06-2009 15:26 . Reden: Extra level multipart/mixed niet nodig ]

[Verwijderd]

Remus schreef op dinsdag 16 juni 2009 @ 15:25:
[...]
Het kan arbitrair diep zijn.

Daarvan ben ik op de hoogte. Berichten met daarin een nieuw bericht (message/rfc822) worden netjes afgehandeld. Binnen de weergave van die mail worden netjes de attachments getoond.

Remus schreef op dinsdag 16 juni 2009 @ 15:25:

Het bericht uit je TS had volgens mij overigens als volgt opgebouwd horen zijn:

code:

multipart/mixed(
    multipart/alternative(
        text/plain, 
        text/html
    ),
    ... de attachments
)

Dit slaat de spijker op zijn kop. Het had zo opgebouwd moeten zijn (jij bent het wat dat betreft dus met mij eens). Echter is dat niet het geval. Outlook toont wel de attachments van het text/html deel. Oftewel dat is hetgeen er wordt verwacht.

In mijn ogen zou ik nu het volgende moeten doen:
Ga alle delen parts af en controleer op bijlages (content-type mixed, deel 2 en hoger, en/of content-type-disposition attachment). De delen met een content-type message/rfc822 moeten worden overgeslagen.

[Peter]

Ik heb ongeveer twee maanden terug zelf tijd geinvesteerd om een (goede) MIME-decoder te schrijven, en ik kan je nu alvast vertellen dat Apple Mail niet de enige client is die moeilijk gaat doen. Er zijn talloze web-mail clients met hun eigen implementatie, gewone e-mail clients en laten we ook de duizenden customs-scriptjes in PHP, Perl, C of wat voor taal dan ook niet vergeten.

Ik heb het opgelost door, indien er boundaries zijn, iedere boundary, ongeacht of het multipart/mixed of -alternative is, als een eigen entiteit te behandelen. Alle boundaries worden geladen en geparsed naar een array toe met de benodigde informatie en op basis van het mime-type wordt er besloten wat de HTML, textuele content of juist de bijlagen zijn. Flink wat fine-tuning is absoluut nodig, maar echt heel veel andere opties heb je vaak niet.

Natuurlijk kun je ook voor de pre-build oplossingen gaan. Google kent een boel MIME-decoders, waarbij PHPClasses.org nog wel een aantal classes heeft liggen. MIME heeft ook nog een classe, maar die wordt niet meer bijgehouden.

[Verwijderd]

Peter schreef op dinsdag 16 juni 2009 @ 16:35:
Verhaal.

Zelf maak ik gebruik van Zend Framework welke het decoderen van de MIME berichten doet. Attachments bepalen is eigelijk altijd een probleem geweest: van scanneer die vreemde headers opgooien tot inderdaad webmail / customer mailers. Ik ben dan eigelijk ook meer op zoek naar een generieke stelregel om te kunnen bepalen wat een attachment is.

Voor nu zal ik inderdaad elke part als eigen identiteit gaan beschouwen (indien de content-type geen message/rfc822 of message/report) is. Ik denk dat ik dan de problemen heb opgelost. Kun je je daarin vinden?

[sam.vimes]

TS heeft geen e-mail met bijlagen ontvangen, maar een html-mail met embedded "plaatjes" en voor de html-tekst is een text/plain vertaling toegevoegd voor lezers die geen text/html aankunnen. Zoals Remus al aangeeft, ziet een e-mail met bijlagen er zo uit:

code:

multipart/mixed {
    body van de e-mail
    attachment-1
    attachment-2
    ....
}

waarbij de body van de e-mail eventueel weer uit een aantal alternatieven kan bestaan:

code:

multipart/alternative {
    text/plain
    text/html
}

Attachments in een multipart/mixed zijn herkenbaar aan de aanwezigheid van een Content-Disposition header.

In het geval van TS zijn er twee alternatieven:

code:

multipart/alternative {
    alternatief-1: text/plain
    alternatief-2: multipart/mixed {
        text/html (begin van de tekst)
        application/pdf (met Content-Disposition, dus een attachment)
        text/html (verdere tekst)
    }
}

Strikt genomen zijn alternatief-1 en alternatief-2 gelijkwaardig (similar), conform de RFC, zoals TS al aangeeft. Iemand die dus kiest voor alternatief-1 zal de attachment dus nooit zien.
Mijn conclusie is dat de e-mail op een foute manier is opgebouwd. Probleem is alleen dat het erg moeilijk is om grote jongens zoals Apple te overtuigen van hun ongelijk in deze.

Advies: als je hebt gekozen voor een bepaald alternatief uit de multipart/alternative, scan dan toch de andere alternatieven op multipart/mixed-delen met een gedefinieerde Content-Disposition. Dat zijn namelijk (bijna) altijd attachments.

[Remus]

Verwijderd schreef op dinsdag 16 juni 2009 @ 16:27:
[...]

Daarvan ben ik op de hoogte. Berichten met daarin een nieuw bericht (message/rfc822) worden netjes afgehandeld. Binnen de weergave van die mail worden netjes de attachments getoond.

[...]

Dit slaat de spijker op zijn kop. Het had zo opgebouwd moeten zijn (jij bent het wat dat betreft dus met mij eens). Echter is dat niet het geval. Outlook toont wel de attachments van het text/html deel. Oftewel dat is hetgeen er wordt verwacht.

In mijn ogen zou ik nu het volgende moeten doen:
Ga alle delen parts af en controleer op bijlages (content-type mixed, deel 2 en hoger, en/of content-type-disposition attachment). De delen met een content-type message/rfc822 moeten worden overgeslagen.

Het 'grote' probleem is dat de relevante RFCs het allemaal toelaten, en daarbij komt het dus wel eens voor dat de logica van de samensteller van de mail (de mailclient of soms een eigenwijze IMAP-emulating server (bijvoorbeeld Exchange, Lotus Notes of Zarafa) niet overeenkomt met de logica die de ontvanger verwacht (sam.vimes beschrijving wijkt af van mijn beschrijving (en jouw verwachting), maar kan ook als logisch gezien worden).

Ik heb in ieder geval genoeg situaties gezien waar uit bleek dat het beste is om recursief alle mulitparts door te gaan (en - afhankelijk van je exacte requirements - de message/rfc822 delen over te slaan) en gewoon alles als attachments te behandelen (ook bijvoorbeeld content-disposition: inline).

[sam.vimes]

Remus schreef op donderdag 18 juni 2009 @ 10:05:
[...]
Ik heb in ieder geval genoeg situaties gezien waar uit bleek dat het beste is om recursief alle mulitparts door te gaan (en - afhankelijk van je exacte requirements - de message/rfc822 delen over te slaan) en gewoon alles als attachments te behandelen (ook bijvoorbeeld content-disposition: inline).

Helemaal mee eens. Het komt te vaak voor dat de verzender van de e-mail zich niet realiseert dat zijn software de e-mail verkeerd samenstelt (althans: op zodanige wijze dat de ontvanger er geen chocola van kan maken; zie topic-start).
Overigens laat rfc2183 (http://www.ietf.org/rfc/rfc2183.txt) er geen misverstand over bestaan: Content-disposition: inline is niet bedoeld voor attachments, maar voor directe, sequentiële display binnen een multipart/mixed.

quote: rfc2183

The display of an attachment is generally construed to require positive action on the part of the recipient, while inline message components are displayed automatically when the message is viewed.
[...]
A bodypart should be marked `inline' if it is intended to be displayed automatically upon display of the message. Inline bodyparts should be presented in the order in which they occur, subject to the normal semantics of multipart messages.

[Remus]

sam.vimes schreef op donderdag 18 juni 2009 @ 12:02:
[...]

Helemaal mee eens. Het komt te vaak voor dat de verzender van de e-mail zich niet realiseert dat zijn software de e-mail verkeerd samenstelt (althans: op zodanige wijze dat de ontvanger er geen chocola van kan maken; zie topic-start).
Overigens laat rfc2183 (http://www.ietf.org/rfc/rfc2183.txt) er geen misverstand over bestaan: Content-disposition: inline is niet bedoeld voor attachments, maar voor directe, sequentiële display binnen een multipart/mixed.

[...]

Dat klopt, maar het komt regelmatig voor dat een verzender iets inline doet (bijvoorbeeld een screenshot plakken ipv attachen), waarbij de mailclient dat als content-disposition: inline verstuurt. Afhankelijk van het doel is het dan beter om ook een content-disposition: inline ook gewoon als attachment te beschouwen.
Mijn specifieke ervaring heeft overigens te maken met de mailimport functionaliteit van TOPdesk, waarbij de tekst van een e-mail als nieuw incident of als aanvulling van een incident wordt opgenomen, terwijl attachments als bestanden aan het incident worden toegevoegd. Het is dan hoogst onhandig als screenshots uit de mail niet beschikbaar zijn

[Confusion]

Verwijderd schreef op dinsdag 16 juni 2009 @ 16:27:
Dit slaat de spijker op zijn kop. Het had zo opgebouwd moeten zijn (jij bent het wat dat betreft dus met mij eens).

Ik kwam tot dezelfde conclusie toen ik mailtjes met die constructie moest maken een paar maanden geleden. De ontvanger ziet ofwel tekst, ofwel HTML met embedded images en andere attachments zijn voor beide zichtbaar. En inderdaad, niet alle mailclients gaan daar correct mee om, maar voorzover ik heb kunnen vinden kan je Outlook ook gewoon niet zover krijgen om de attachments niet te tonen. Als Outlook die attachments niet zou tonen, zouden andere mailclients waarschijnlijk wel goed verzenden...

[ Voor 3% gewijzigd door Confusion op 18-06-2009 14:24 ]