Check ob MIME korrekt aufgebaut ist. (Sonstige Beiträge (auch Spaß und Sinnloses))

[thread]14111[/thread]

Check ob MIME korrekt aufgebaut ist.

Leser: 18

Articles: hide open all | hide show old branches

+21 replies
leo11

2009-10-07 14:44
User since
2008-08-14
250 Artikel
BenutzerIn
Hallo,

ich habe ein MIME File vorliegen. Hier ein Auszug:
Code: (dl )

1 2 3 4 5 6 7

content-type: application/octet-stream;filename="123.txt" Content-Transfer-Encoding: 7bit content-transfer-encoding: base64 Content-Disposition: attachment; filename="123.txt" JVBEel0xLjQKJeTjz9IKMSAwIG9iagpbL1BERi9JbWFnZUIvSW1hZ2VDL0ltYWdlSS9UZXh0XQpl
Ich dachte das der Header durch die erste Leerzeile vom Body getrennt wird. Das ist hier nicht der Fall. Wie kann ich püfen, ob das so korrekt ist?
- bianca
  
  2009-10-07 14:52
  
  User since
  2009-09-13
  7016 Artikel
  BenutzerIn
  
  Dokus
  
  Edit: Komisch sieht es allemal aus. Zweimal content-transfer-encoding? Ich glaube nicht, dass das sinnvoll ist. Zumindest baue ich Mails nicht so auf.
  Last edited: 2009-10-07 14:54:21 +0200 (CEST)
  10 print "Hallo"
  20 goto 10
- topeg
  
  2009-10-07 14:53
  User since
  2006-07-10
  2611 Artikel
  BenutzerIn
  Das sieht nach einem geschachtelten Content aus.
  
  Der Inhalt ist eigentlich:
  
  Code: (dl )
  
  1 2 3 4
  
  content-transfer-encoding: base64 Content-Disposition: attachment; filename="123.txt" JVBEel0xLjQKJeTjz9IKMSAwIG9iagpbL1BERi9JbWFnZUIvSW1hZ2VDL0ltYWdlSS9UZXh0XQpl
  
  und ist als ASCII (7bit) kodiert mit dem Namen "123.txt"
- +18 replies
- leo11
  
  2009-10-07 15:10
  User since
  2008-08-14
  250 Artikel
  BenutzerIn
  Ok, aber wie kann ich pruefen ob es korrekt ist? In dem RFC Dschungel find ich mich nur schwerlich zurecht.. .
  
  Hier mal ein größerer Auszug:
  
  Code: (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13
  
  Message-ID: <1412248204.1254850563832.JavaMail.wfdd@exl.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_149_79303392.1254850563879" ------=_Part_149_79303392.1254850563879 content-type: application/octet-stream;filename="123.txt" Content-Transfer-Encoding: 7bit content-transfer-encoding: base64 Content-Disposition: attachment; filename="123.txt" JVBERi0xLjQKJeTjz9IKMSAwIG9iagpbL1BERi9JbWFnZUIvSW1hZ2VDL0ltYWdlSS9UZXh0XQpl
  
  Dann kommen die letzten base64 Zeilen direkt (d.h. ohne Leerzeile) gefolgt von:
  
  Code: (dl )
  
  1 2 3 4 5 6
  
  ------=_Part_149_79303392.1254850563879 content-type: application/octet-stream;filename="456.txt" content-transfer-encoding: base64 Content-Disposition: attachment; filename="456.txt" MDAxMjAwOS0xMC0wNi0xMC40Mi4yMy43MzEyMTIwMDAwMDAyMzd5DdfowMTBCWSAgICBCQRDSCAg
  - +6 replies
  - bianca
    
    2009-10-07 15:31
    
    User since
    2009-09-13
    7016 Artikel
    BenutzerIn
    
    Hier steht der generelle Aufbau beschrieben: Doku
    
    Und hier wird Multipart Mime beschrieben, was in Deinem Fall vorliegt: Doku
    
    Wenn Du das nicht studieren willst, stell halt Deine Frage konkreter. Wofür musst Du wissen, ob es korrekt ist? Bist Du Versender oder Parser oder Empfänger oder wie oder was?
    10 print "Hallo"
    20 goto 10
    - +5 replies
    - leo11
      
      2009-10-07 15:41
      
      User since
      2008-08-14
      250 Artikel
      BenutzerIn
      
      Ich bin der Empfänger und möchte die attachements parsen. Bitte jetzt keinen Link auf MIME::Tools.
      - +4 replies
      - bianca
        
        2009-10-07 17:05
        
        User since
        2009-09-13
        7016 Artikel
        BenutzerIn
        
        2009-10-07T13:41:55 leo11
        Ich bin der Empfänger und möchte die attachements parsen. Bitte jetzt keinen Link auf MIME::Tools.
        
        Ich muss sagen, mit dem MIME::Parser bin ich diesbezüglich seit vielen Jahren äußerst zufrieden. Hab das Gefühl, der liest irgendwie alles :)
        
        Was hast Du denn dagegen? Kommste nicht mit klar? Willste Beispielcode haben?
        10 print "Hallo"
        20 goto 10
        
        +3 replies
        
        leo11
        
        2009-10-07 17:29
        
        User since
        2008-08-14
        250 Artikel
        BenutzerIn
        
        [quote="bianca@2009-10-07T15:05:15"]
        2009-10-07T13:41:55 leo11
        Was hast Du denn dagegen? Kommste nicht mit klar? Willste Beispielcode haben?
        
        Ist halt wegen der Installation so eine Sache... .
        Fänd aber auf alle Fälle intressant zu sehen, wie man dann an die attachements kommt, und den String zwischen den Hochkommas in filename="123.txt" pro attachement.
        
        +2 replies
        
        bianca
        
        2009-10-07 17:56
        
        User since
        2009-09-13
        7016 Artikel
        BenutzerIn
        
        Ich hab das bei mir so, dass jede Mail einen temporären Ordner bekommt und dem Mimeparser sage ich, er soll alles, was er findet da rein schmeißen.
        
        und mit
        
        Code: (dl )
        
        $parser -> output_dir($tmppfad);
        
        sag ich dem Teil, wo der Schrott hin soll.
        
        Soweit der Dateiname im MIME der Mail richtig integriert ist, erkennt ihn der Mimeparser und verwendet ihn auch als Dateinamen. Das jeweilige Verzeichnis auszulesen hinterher dürfte ja nicht das Problem sein.
        
        Ich checke bei mir allerdings nicht, ob die Angabe in der Mail zum Attachment nun auch mit dem Filenamen im temporären Ordner überein stimmt, weil mir das Schnurz ist.
        10 print "Hallo"
        20 goto 10
        
        leo11
        
        2009-10-07 18:46
        
        User since
        2008-08-14
        250 Artikel
        BenutzerIn
        
        Danke für das prima Bsp.
  - +11 replies
  - topeg
    
    2009-10-07 18:36
    User since
    2006-07-10
    2611 Artikel
    BenutzerIn
    
    "boundary" ist ja der Blocktrenner, alles was dazwischen steht ist ein Eigener Datenblock mit Header und Body. Leere Zeilen sind dort nur sofern nötig als dass es sich um Formatierungen im Inhalt oder zu Abtrennen des Headers dient.
    
    Der erste Datenblock sieht mir nicht korrekt aus, denn im Header
    
    Code: (dl )
    
    1 2
    
    content-type: application/octet-stream;filename="123.txt" Content-Transfer-Encoding: 7bit
    
    findet sich kein Hinweis, dass der Inhalt geparst werden soll.
    "application/octet-stream" ja weißt darauf hin dass es sich um eine Binärdatei handelt.
    Wenn du das nicht an der Quelle Korrigieren kannst bleibt dir nur die die Möglichkeit eine Ausnahmeregel zu machen.
    So könntest du den Body jedes Attachments nach "filename=" durchsuchen und mit den gefunden Dateiname aus dem Header vergleichen, wenn es identisch ist, dann nimm den Body und Parse ihn nochmal.
    - +10 replies
    - leo11
      
      2009-10-07 18:45
      
      User since
      2008-08-14
      250 Artikel
      BenutzerIn
      
      2009-10-07T16:36:17 topeg
      "boundary" ist ja der Blocktrenner,
      
      klar
      
      Quote
      alles was dazwischen steht ist ein Eigener Datenblock mit Header und Body. Leere Zeilen sind dort nur sofern nötig als dass es sich um Formatierungen im Inhalt oder zu Abtrennen des Headers dient.
      
      Du meints Leerzeilen sind nur erlaubt bei Formatierungen im Body und zum abtrennen des Headers vom Body, oder? Ich kenne das bisher auch nur so, dass im Header selbst keine Leerzeile ist.
      
      Quote
      So könntest du den Body jedes Attachments nach "filename=" durchsuchen
      
      Dachte eigentlich das gehört zum Header.
      - bianca
        
        2009-10-07 19:01
        
        User since
        2009-09-13
        7016 Artikel
        BenutzerIn
        
        2009-10-07T16:45:53 leo11
        Dachte eigentlich das gehört zum Header.
        
        Vorsicht mit den Begrifflichkeiten. Bei MIME-Mails (insbesondere Multipart) ist nicht alles so, wie man das vielleicht aus anderen Bereichen kennt.
        Wenn Du wirklich so tief gehen willst, kommst Du um das Studium der RFC's nicht herum, das besagt meine Erfahrung.
        10 print "Hallo"
        20 goto 10
      - +8 replies
      - topeg
        
        2009-10-07 19:29
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Für multipart/mixed
        
        Code: (dl )
        
        1 2 3
        
        HEADER (mit boundary="--trenner") BODY
        
        Der BODY ist:
        
        Code: (dl )
        
        1 2 3 4 5 6 7 8 9
        
        --trenner HEDER BODY --trenner HEADER BODY --trenner--
        
        Bei dir scheint aber zu stehen:
        Header wie geabt
        aber BODY
        
        Code: (dl )
        
        1 2 3 4 5 6 7 8 9 10 11
        
        --trenner HEADER HEADER BODY --trenner HEADER BODY --trenner--
        
        damit gehört der "zweite" header zum BODY des Ersten Datenblocks
        und der BODY des ersten Datenblocks ist
        
        Code: (dl )
        
        1 2 3
        
        HEADER BODY
        
        Soweit klar?
        
        Wenn nun im HEADER des ersten Datenblocks nichts steht, dass der BODY auch geparst werden soll dann ist der BODY wirklich nur Daten. In deinem Fall scheint es so zu sein, dass der Sender den Inhalt fehlerhaft verpackt hat und im BODY einen HEADER gepackt hat den du, wenn du dich an die RFC hältst, missachten müsstest, aber nicht willst, da du am "wahren" Inhalt interessiert bist. Darum schlug ich den Hack vor.
        
        +7 replies
        
        leo11
        
        2009-10-07 19:49
        
        User since
        2008-08-14
        250 Artikel
        BenutzerIn
        
        Ich hab die Files nun mal mit Mime::Tools geparst, und zusammen mit eurer Hilfe nun die Sicherheit, das folgendes geändert werden muss:
        
        falsch:
        
        Code: (dl )
        
        1 2 3 4 5 6
        
        ------=_Part_149_79303392.1254850563879 content-type: application/octet-stream;filename="123.txt" Content-Transfer-Encoding: 7bit content-transfer-encoding: base64 Content-Disposition: attachment; filename="123.txt"
        
        richtig:
        
        Code: (dl )
        
        1 2 3 4
        
        ------=_Part_149_79303392.1254850563879 content-type: application/octet-stream;filename="123.txt" content-transfer-encoding: base64 Content-Disposition: attachment; filename="123.txt"
        
        Mit diesen kleinen Änderungen parst MIME::Tools und mein eigener kleiner Hack die Files 1a. (-:
        
        Danke an euch beide.
        
        +6 replies
        
        topeg
        
        2009-10-07 20:09
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Nach welcher Regel fügst du die beiden zusammen?
        Wenn du dabei nicht ganz vorsichtig bist kann es zu Fehlern kommen. Es gibt einige Content-Typen, die besagen, dass der Body selber wieder eine Mime Message ist.
        
        +5 replies
        
        leo11
        
        2009-10-07 21:12
        
        User since
        2008-08-14
        250 Artikel
        BenutzerIn
        
        2009-10-07T18:09:48 topeg
        Nach welcher Regel fügst du die beiden zusammen?
        
        Das muss der Absender ändern. Ist sonst zu heikel.
        
        Ich hab noch ein paar Fragen zu MIME::Tools:
        Wie kann ich auf den String zwischen den Hochkommas in filename zugreifen?
        
        Edit: Hat sich erledigt.
        
        Hier mein Code aufs wesentliche beschränkt:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6
        
        eval { my $parser = new MIME::Parser; $parser->output_under("/tmp/"); my $entity = $parser->parse(\*STDIN) or die "parse failed\n"; }; ..
        
        Wie komm ich an den Ordnernamen, in dem das Extrahierte abliegt?
        Last edited: 2009-10-07 23:01:34 +0200 (CEST)
        
        +4 replies
        
        leo11
        
        2009-10-08 15:50
        
        User since
        2008-08-14
        250 Artikel
        BenutzerIn
        
        Wie komm ich mit MIME::Tools an den Ordnernamen in dem das extrahierte File abliegt? Den der mit msg beginnt.
        Hier mal ein Auszug aus print Dumper \$entity;
        
        Code: (dl )
        
        1 2 3 4 5 6 7 8 9 10
        
        $VAR1 = \bless( { 'ME_Parts' => [ bless( { 'ME_Bodyhandle' => bless( { 'MB_Path' => '/tmp/msg-1254937311-19946-0/123.txt', 'MB_Binmode' => 1 }, 'MIME::Body::File' ), 'ME_Parts' => [], 'mail_inet_head' => bless( { ...
        
        +3 replies
        
        bianca
        
        2009-10-08 16:21
        
        User since
        2009-09-13
        7016 Artikel
        BenutzerIn
        
        Das umgehe ich, indem ich die Dateien jeder Mail in ein eigenes Unterverzeichnis schreiben lasse.
        Dann kann ich bequem mit readdir nachschauen, was da alles schönes erzeugt wurde. Vielleicht hilft Dir das auch.
        10 print "Hallo"
        20 goto 10
        
        +2 replies
        
        leo11
        
        2009-10-08 16:32
        
        User since
        2008-08-14
        250 Artikel
        BenutzerIn
        
        Ich wills aber gern wissen. Hab rausgefunden, wie man auf filename zugreift, aber das nicht. Das muss doch gehen.
        
        leo11
        
        2009-10-10 19:12
        
        User since
        2008-08-14
        250 Artikel
        BenutzerIn
        
        Hier nun die Lösung:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12
        
        if ( $entity->is_multipart ) { for my $part ( $entity->parts ) { my $head = $part->head; if ( my $filename = $head->recommended_filename ) { print "Attachment name: $filename\n"; } my $body = $part->bodyhandle; if (my $path = $body->path) { print $path, "\n"; } } }

View all threads created 2009-10-07 14:44.