Announcement

Collapse
No announcement yet.

Error when extracting e-mails and attachments

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error when extracting e-mails and attachments

    Hi,

    Using OSForensics 3.0 build 1000 (32 bit), I encounter errors when extracting .eml e-mails and their attachments.

    Some of them do work, but some don't. It may be related to problem with accents. For instance, it shows : "Boéte" instead of "Boîte", but strangely not on ALL items.

    Another problem is, if the subject of the e-mail begins by "=?iso-8859-1", there is also an error "Error adding file. AddEmailToCase: Could not extract email".

    Any advice ? Is there an option somewhere to adjust character encoding ?

    Thanks !

  • #2
    Can you upgrade to V3.1. See,
    http://www.osforensics.com/whatsnew.html

    We did a complete re-write of the E-mail handling.

    If there is still an issue in V3.1, then please get back to us. Also let us know what type of attachment is effected (Word, Excel, etc..)

    Comment


    • #3
      Upgraded to 3.1 as advised. Things are a little bit better but there still are major issues.

      First of all, when searching in the index, attachments now appear as files and not as attachments anymore. It was better to make a distinction between these 2 types of files.

      Also, please see the following error messages.

      1) When adding a file (attachment) to a case :



      "Le chemin d'accès spécifié est introuvable" means "System can't find the path specified".

      2) Sometimes, when adding an e-mail to a case :



      Strangely enough, as you can see, character encoding seems to be right here but not in the first point...

      Good news is, problem with e-mail subject beginning with "=?iso-8859-1" is fixed

      Edit : attachment files are mainly PDF documents.
      Last edited by Silas; Dec-08-2014, 01:33 PM.

      Comment


      • #4
        Thanks for the details.

        It looks to be an issue with handling filepaths containing accented characters. We're investigating at the moment and will get back with a fix shortly.

        For the issue you described regarding "attachments now appearing as files and not as attachments anymore", can you post a screenshot that shows the incorrect grouping of attachments as files? Even better if you are able to provide a test file that we can reproduce on our own systems.

        Comment


        • #5
          OK, here's a screenshot when searching in an index with 3.0 :



          And now the same search with 3.1 :



          Also, I have blocking issues when generating a report when using the "copy files to report location" option, when files contains special characters in the path (the process stops at the 1st error) :



          Unfortunately I can't provide test files as they are confidential, but they're all are EML files (Windows Live Mail) with ISO-8859-1 encoding.

          Ah, and there still are "AddEmailToCase : E-mail does not have a header" problems sometimes... For instance, this is the header of such an e-mail :

          X-grid-version: 0000
          Return-Path: <xxx@yyy.com>
          Received: from xxx.yyy.fr (xxx.yyy.fr) by XXX (SMTP Server) with LMTP; Wed, 19 Aug 2009 07:43:57 +0200
          X-Sieve: Server Sieve 2.2
          X-MSMail-Priority: High
          Received: from filter.xxx.fr (localhost [127.0.0.1]) by xxx.yyy.fr (SMTP Server) with ESMTP id 0D2BF1C0008A for <clb000000000000000023697460@back04-mail02-01.xxx.fr>; Wed, 19 Aug 2009 07:43:57 +0200 (CEST)
          Received: from srv-stmp-01.xxx.com (unknown [a.b.c.d]) by xxx.fr (SMTP Server) with ESMTP id EB0C41C00084 for <xxx@yyy.fr>; Wed, 19 Aug 2009 07:43:54 +0200 (CEST)
          Return-Receipt-To: "XXX" <xxx@yyy.f>
          Subject: =?iso-8859-1?Q?TR=A0:_RE:_Antwort:_RE:_Antwort:_RE:_Antwort:_ xxx?=
          =?iso-8859-1?Q?eel?=
          Date: Wed, 19 Aug 2009 07:41:51 +0200
          Message-ID: <2D138B3205203C4292B7B2F2C28B64500138B3@SRV-AD-xxx.com>
          MIME-Version: 1.0
          Content-Type: multipart/related;
          type="multipart/alternative";
          boundary="----=_NextPart_000_60A8_01CF46A4.F5D43620"
          X-MS-Has-Attach: yes
          X-MS-TNEF-Correlator:
          Thread-Topic: RE: Antwort: RE: Antwort: RE: Antwort: xxx
          Disposition-Notification-To: "XXX" <xxx@yyy.com>
          Content-class: urn:content-classes:message
          Thread-Index: AcofXxHByv2Ak/ySSTm/SOSJt/++dQAAxzEgAEtkhz0=
          X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
          X-Priority: 1
          Priority: Urgent
          Importance: High
          References: <1664CEA7F3BA8046805B44D9CF6C8820800870@xxx.com>
          From: "XXX" <xxx@yyy.com>
          To: <zzz@aaa.fr>
          X-OriginalArrivalTime: 19 Aug 2009 05:43:50.0953 (UTC) FILETIME=[07AB5990:01CA2090]
          X-Brightmail-Tracker: AAAAAA==
          X-BitDefenderWKS-SpamStamp: v1, build 2.8.21.79864, dwl listed, bayes score: 500(0), pbayes score: 0(0), neunet score: 0(0), flags: [NN_ORDER; NN_NET_SHARE; NN_USELESS_CONTENT_TYPE; NN_TP_TAG_HTTP; NN_SUMM_N15_ADN; NN_SWISS; NN_THICKEN; NN_COPIES; NN_LARGISH_BIGGISH1; NN_LEGIT_SUMM_400_WORDS], total: 0(725)
          X-BitDefenderWKS-Spam: No - 0
          Hope this helps
          Last edited by Silas; Dec-09-2014, 02:00 PM.

          Comment


          • #6
            Thanks for the screenshots. We were able to address some of the character encoding issues (it turns out that non-ASCII text in MIME headers is quite complicated and is a pain to decode). Can you give this pre-release build a try:

            http://www.passmark.com/ftp/osf_v3.1.1002a.exe

            Comment

            Working...
            X