Uploaded image for project: 'Tika'
  1. Tika
  2. TIKA-879

Detection problem: message/rfc822 file is detected as text/plain.

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0, 1.1, 1.2
    • Fix Version/s: None
    • Component/s: metadata, mime
    • Labels:
    • Environment:

      linux 3.2.9
      oracle jdk7, openjdk7, sun jdk6

      Description

      When using DefaultDetector mime type for .eml files is different (you can test it on testRFC822 and testRFC822_base64 in tika-parsers/src/test/resources/test-documents/).

      Main reason for such behavior is that only magic detector is really works for such files. Even if you set CONTENT_TYPE in metadata or some .eml file name in RESOURCE_NAME_KEY.

      As I found MediaTypeRegistry.isSpecializationOf("message/rfc822", "text/plain") returns false, so detection by MimeTypes.detect(...) works only by magic.

      1. TIKA-879-thunderbird.eml
        0.7 kB
        Sebastian Nagel
      2. mime_diffs_A_to_B.html
        1 kB
        Tim Allison
      3. mbox_email_section.txt
        2 kB
        Matthew Caruana Galizia

        Issue Links

          Activity

          Hide
          vladimir_l Vladimir L. added a comment - - edited

          I've got the same problem: trying to parse Outlook Express file: *.eml and get default "text/plain" Content-Type instead of expected "message/rfc822"

          I'm using org.apache.tika.parser.AutoDetectParser with default settings and during debugging came to the same conclusion as a reporter of this issue: "MediaTypeRegistry.isSpecializationOf("message/rfc822", "text/plain") returns false".

          If there is a way to vote for this bug to be fixed, or easy work around, please share it with us!

          Show
          vladimir_l Vladimir L. added a comment - - edited I've got the same problem: trying to parse Outlook Express file: *.eml and get default "text/plain" Content-Type instead of expected "message/rfc822" I'm using org.apache.tika.parser.AutoDetectParser with default settings and during debugging came to the same conclusion as a reporter of this issue: "MediaTypeRegistry.isSpecializationOf("message/rfc822", "text/plain") returns false". If there is a way to vote for this bug to be fixed, or easy work around, please share it with us!
          Hide
          vladimir_l Vladimir L. added a comment - - edited

          I figured out where the root of problem lays on.
          The original Tika configuration for "message/rfc822" is following:

            <mime-type type="message/rfc822">
              <magic priority="50">
                <match value="Relay-Version:" type="string" offset="0"/>
                <match value="#!\ rnews" type="string" offset="0"/>
                <match value="N#!\ rnews" type="string" offset="0"/>
                <match value="Forward\ to" type="string" offset="0"/>
                <match value="Pipe\ to" type="string" offset="0"/>
                <match value="Return-Path:" type="string" offset="0"/>
                <match value="From:" type="string" offset="0"/>
                <match value="Received:" type="string" offset="0"/>
                <match type="string" value="Message-ID:" offset="0"/>
                <match type="string" value="Date:" offset="0"/>
              </magic>
              <glob pattern="*.eml"/>
              <glob pattern="*.mime"/>
              <glob pattern="*.mht"/>
              <glob pattern="*.mhtml"/>
            </mime-type>
          

          Unfortunately the e-mail message I'm testing with has following header:

          x-store-info:J++/JTCzmObr++wNraA4 .....
          Authentication-Results: something.com; sender-id= ......
          X-SID-PRA: vladimir_l@example.com
          X-SID-Result: Pass
          X-DKIM-Result: None
          X-AUTH-Result: PASS
          X-Message-Status: n:n
          X-Message-Delivery: Vj0xLjE7dXM .....
          X-Message-Info: aKlYzGSc+Ll01bU5 ....
          Received: from mailout- ....
          Received: (qmail invoked by alias); 21 Nov 2012 20:11:35 -0000
          Received: from mp017. ....
          X-Authenticated: #2407 ....
          X-Provags-ID: V01U2FsdGVkX ....
          Received: (qmail 22194 invoked by uid 0); 21 Nov 2012 20:11:34 -0000
          Received: from ....
          Content-Type: text/plain; charset="utf-8"
          Date: Wed, 21 Nov 2012 21:11:32 +0100
          From: "Vladimir L." <vladimir_l@example.com>
          Message-ID: <20121121201132.74140@example.com>
          MIME-Version: 1.0
          Subject: JUnit test message
          To: vladimir_l@something.com
          X-Flags: 0001
          X-Mailer: WWW-Mail 6100 (Global Message Exchange)
          X-Priority: 3
          Content-Transfer-Encoding: 8bit
          Return-Path: vladimir_l@example.com
          X-OriginalArrivalTime: 21 Nov 2012 20:11:36.0285 ....
          
          Dear Vladimir .....
          

          As you can see none of the mentioned patterns is matching since they are all configured with offset="0"
          However the e-mail header defines the Content-Type: text/plain, which i assume influence the initial content type detection.
          The <sub-class-of type="text/plain"/> is not defined in mime-type definition, therefore auto-detection via extension *.eml fails for aforementioned reason of this issue.

          The current workaround for me is following:
          1. Create custom-mimetypes.xml as described here: http://tika.apache.org/1.0/parser_guide.html#Add_your_MIME-Type
          2. Add redefinition for "message/rfc822" mime-type as following:

            <mime-type type="message/rfc822">
              <magic priority="50">
                <match value="Relay-Version:" type="string" offset="0"/>
                <match value="#!\ rnews" type="string" offset="0"/>
                <match value="N#!\ rnews" type="string" offset="0"/>
                <match value="Forward\ to" type="string" offset="0"/>
                <match value="Pipe\ to" type="string" offset="0"/>
                <match value="Return-Path:" type="string" offset="0:2000"/>
                <match value="From:" type="string" offset="0"/>
                <match value="Received:" type="string" offset="0:2000"/>
                <match value="Message-ID:" type="string" offset="0:2000"/>
                <match value="Date:" type="string" offset="0"/>
              </magic>
              <glob pattern="*.eml"/>
              <glob pattern="*.mime"/>
              <glob pattern="*.mht"/>
              <glob pattern="*.mhtml"/>
              <sub-class-of type="text/plain"/>
            </mime-type>
          

          Note the offset settings for Message-ID:, Return-Path:, and Received:
          I decided to leave fall-back to extension detection through definition of super-class text/plain

          Hope this will help you to go around this issue too.

          Good luck,
          vladimir

          Show
          vladimir_l Vladimir L. added a comment - - edited I figured out where the root of problem lays on. The original Tika configuration for "message/rfc822" is following: <mime-type type= "message/rfc822" > <magic priority= "50" > <match value= "Relay-Version:" type= "string" offset= "0" /> <match value= "#!\ rnews" type= "string" offset= "0" /> <match value= "N#!\ rnews" type= "string" offset= "0" /> <match value= "Forward\ to" type= "string" offset= "0" /> <match value= "Pipe\ to" type= "string" offset= "0" /> <match value= "Return-Path:" type= "string" offset= "0" /> <match value= "From:" type= "string" offset= "0" /> <match value= "Received:" type= "string" offset= "0" /> <match type= "string" value= "Message-ID:" offset= "0" /> <match type= "string" value= "Date:" offset= "0" /> </magic> <glob pattern= "*.eml" /> <glob pattern= "*.mime" /> <glob pattern= "*.mht" /> <glob pattern= "*.mhtml" /> </mime-type> Unfortunately the e-mail message I'm testing with has following header: x-store-info:J++/JTCzmObr++wNraA4 ..... Authentication-Results: something.com; sender-id= ...... X-SID-PRA: vladimir_l@example.com X-SID-Result: Pass X-DKIM-Result: None X-AUTH-Result: PASS X-Message-Status: n:n X-Message-Delivery: Vj0xLjE7dXM ..... X-Message-Info: aKlYzGSc+Ll01bU5 .... Received: from mailout- .... Received: (qmail invoked by alias); 21 Nov 2012 20:11:35 -0000 Received: from mp017. .... X-Authenticated: #2407 .... X-Provags-ID: V01U2FsdGVkX .... Received: (qmail 22194 invoked by uid 0); 21 Nov 2012 20:11:34 -0000 Received: from .... Content-Type: text/plain; charset= "utf-8" Date: Wed, 21 Nov 2012 21:11:32 +0100 From: "Vladimir L." <vladimir_l@example.com> Message-ID: <20121121201132.74140@example.com> MIME-Version: 1.0 Subject: JUnit test message To: vladimir_l@something.com X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 Content-Transfer-Encoding: 8bit Return-Path: vladimir_l@example.com X-OriginalArrivalTime: 21 Nov 2012 20:11:36.0285 .... Dear Vladimir ..... As you can see none of the mentioned patterns is matching since they are all configured with offset="0" However the e-mail header defines the Content-Type: text/plain, which i assume influence the initial content type detection. The <sub-class-of type="text/plain"/> is not defined in mime-type definition, therefore auto-detection via extension *.eml fails for aforementioned reason of this issue. The current workaround for me is following: 1. Create custom-mimetypes.xml as described here: http://tika.apache.org/1.0/parser_guide.html#Add_your_MIME-Type 2. Add redefinition for "message/rfc822" mime-type as following: <mime-type type= "message/rfc822" > <magic priority= "50" > <match value= "Relay-Version:" type= "string" offset= "0" /> <match value= "#!\ rnews" type= "string" offset= "0" /> <match value= "N#!\ rnews" type= "string" offset= "0" /> <match value= "Forward\ to" type= "string" offset= "0" /> <match value= "Pipe\ to" type= "string" offset= "0" /> <match value= "Return-Path:" type= "string" offset= "0:2000" /> <match value= "From:" type= "string" offset= "0" /> <match value= "Received:" type= "string" offset= "0:2000" /> <match value= "Message-ID:" type= "string" offset= "0:2000" /> <match value= "Date:" type= "string" offset= "0" /> </magic> <glob pattern= "*.eml" /> <glob pattern= "*.mime" /> <glob pattern= "*.mht" /> <glob pattern= "*.mhtml" /> <sub-class-of type= "text/plain" /> </mime-type> Note the offset settings for Message-ID: , Return-Path: , and Received: I decided to leave fall-back to extension detection through definition of super-class text/plain Hope this will help you to go around this issue too. Good luck, vladimir
          Hide
          wastl-nagel Sebastian Nagel added a comment -

          I've run into the same problem with an .eml file written by Thunderbird (see attachment).

          RFC822 states (http://tools.ietf.org/html/rfc822#section-4.1) that header fields can appear in any order:

          Note: Due to an artifact of the notational conventions, the syntax indicates that, when present, some fields, must be in a particular order. Header fields are NOT required to occur in any particular order, except that the message body must occur AFTER the headers.

          If one of the "optional" fields (according to RFC822), esp. "extension-field" ("X-...") or any "user-defined-field", is the first field in the header the mime magic does not work.

          Adding <sub-class-of type="text/plain"/> would solve the problem only partially: if any text file is named *.eml, it is always recognized as message/rfc822 independent from its content. Is the file name/extension a strong indicator?

          Or would it be possible to relax the MIME magic and allow additional header fields at the beginning?

          • check for the field: value structure first
          • then check for (some) required fields ("Date:", "From:") but also if not immediately at beginning
          Show
          wastl-nagel Sebastian Nagel added a comment - I've run into the same problem with an .eml file written by Thunderbird (see attachment). RFC822 states ( http://tools.ietf.org/html/rfc822#section-4.1 ) that header fields can appear in any order: Note: Due to an artifact of the notational conventions, the syntax indicates that, when present, some fields, must be in a particular order. Header fields are NOT required to occur in any particular order, except that the message body must occur AFTER the headers. If one of the "optional" fields (according to RFC822), esp. "extension-field" ("X-...") or any "user-defined-field", is the first field in the header the mime magic does not work. Adding <sub-class-of type="text/plain"/> would solve the problem only partially: if any text file is named *.eml, it is always recognized as message/rfc822 independent from its content. Is the file name/extension a strong indicator? Or would it be possible to relax the MIME magic and allow additional header fields at the beginning? check for the field: value structure first then check for (some) required fields ("Date:", "From:") but also if not immediately at beginning
          Hide
          lfcnassif Luis Filipe Nassif added a comment -

          I have had this issue too with a lot of files and currently I am using the same workaround as Vladimir L..

          Show
          lfcnassif Luis Filipe Nassif added a comment - I have had this issue too with a lot of files and currently I am using the same workaround as Vladimir L. .
          Hide
          gagravarr Nick Burch added a comment -

          I've done something a little different in r1647721 as a partial workaround - I've added a new mimetype of text/x-tika-text-based-message which is a parent of the 3 text-based message/ mimetypes (most of the message/ mimetypes are not text based). With that in place, Vladimir's test email is now correctly detected when it has a .eml extension. (I think that this parent probably is more semantically meaningful than text/plain, which is why I went for it)

          However, this doesn't solve the "detection without filename" issue, and some other related mail detection problems (eg multipart/signed). We might therefore want to think about adding a new mail detector, along the lines of the one suggested in this Stack Overflow question from a few weeks back - http://stackoverflow.com/questions/27397807/tika-detect-multipart-signed

          Show
          gagravarr Nick Burch added a comment - I've done something a little different in r1647721 as a partial workaround - I've added a new mimetype of text/x-tika-text-based-message which is a parent of the 3 text-based message/ mimetypes (most of the message/ mimetypes are not text based). With that in place, Vladimir's test email is now correctly detected when it has a .eml extension. (I think that this parent probably is more semantically meaningful than text/plain, which is why I went for it) However, this doesn't solve the "detection without filename" issue, and some other related mail detection problems (eg multipart/signed). We might therefore want to think about adding a new mail detector, along the lines of the one suggested in this Stack Overflow question from a few weeks back - http://stackoverflow.com/questions/27397807/tika-detect-multipart-signed
          Hide
          hudson Hudson added a comment -

          UNSTABLE: Integrated in tika-trunk-jdk1.7 #387 (See https://builds.apache.org/job/tika-trunk-jdk1.7/387/)
          TIKA-879 Add a new parent mime type, for the text based message formats, of text/x-tika-text-based-message, which allows Thunderbird messages to be correctly detected as they now show up as being text based not binary based in the hierarchy (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1647721)

          • /tika/trunk/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml
          • /tika/trunk/tika-parsers/src/test/java/org/apache/tika/mime/TestMimeTypes.java
          Show
          hudson Hudson added a comment - UNSTABLE: Integrated in tika-trunk-jdk1.7 #387 (See https://builds.apache.org/job/tika-trunk-jdk1.7/387/ ) TIKA-879 Add a new parent mime type, for the text based message formats, of text/x-tika-text-based-message, which allows Thunderbird messages to be correctly detected as they now show up as being text based not binary based in the hierarchy (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1647721 ) /tika/trunk/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml /tika/trunk/tika-parsers/src/test/java/org/apache/tika/mime/TestMimeTypes.java
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in tika-trunk-jdk1.6 #372 (See https://builds.apache.org/job/tika-trunk-jdk1.6/372/)
          Missing test file from TIKA-879 (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1647725)

          • /tika/trunk/tika-parsers/src/test/resources/test-documents/testThunderbirdEml.eml
            TIKA-879 Add a new parent mime type, for the text based message formats, of text/x-tika-text-based-message, which allows Thunderbird messages to be correctly detected as they now show up as being text based not binary based in the hierarchy (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1647721)
          • /tika/trunk/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml
          • /tika/trunk/tika-parsers/src/test/java/org/apache/tika/mime/TestMimeTypes.java
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in tika-trunk-jdk1.6 #372 (See https://builds.apache.org/job/tika-trunk-jdk1.6/372/ ) Missing test file from TIKA-879 (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1647725 ) /tika/trunk/tika-parsers/src/test/resources/test-documents/testThunderbirdEml.eml TIKA-879 Add a new parent mime type, for the text based message formats, of text/x-tika-text-based-message, which allows Thunderbird messages to be correctly detected as they now show up as being text based not binary based in the hierarchy (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1647721 ) /tika/trunk/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml /tika/trunk/tika-parsers/src/test/java/org/apache/tika/mime/TestMimeTypes.java
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in tika-trunk-jdk1.7 #388 (See https://builds.apache.org/job/tika-trunk-jdk1.7/388/)
          Missing test file from TIKA-879 (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1647725)

          • /tika/trunk/tika-parsers/src/test/resources/test-documents/testThunderbirdEml.eml
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in tika-trunk-jdk1.7 #388 (See https://builds.apache.org/job/tika-trunk-jdk1.7/388/ ) Missing test file from TIKA-879 (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1647725 ) /tika/trunk/tika-parsers/src/test/resources/test-documents/testThunderbirdEml.eml
          Hide
          lfcnassif Luis Filipe Nassif added a comment -

          Nick,
          Could we add the extended offsets proposed by Wladimir? I am using 0:1000 range with the same patterns as him. It helped a lot to detect mails without extension and I am getting no false positives.

          Show
          lfcnassif Luis Filipe Nassif added a comment - Nick, Could we add the extended offsets proposed by Wladimir? I am using 0:1000 range with the same patterns as him. It helped a lot to detect mails without extension and I am getting no false positives.
          Hide
          tpalsulich Tyler Palsulich added a comment -

          Luis Filipe Nassif, that seems like a reasonable solution. Nick Burch, any objections to widening the range of the offset for magic detection?

          Show
          tpalsulich Tyler Palsulich added a comment - Luis Filipe Nassif , that seems like a reasonable solution. Nick Burch , any objections to widening the range of the offset for magic detection?
          Hide
          gagravarr Nick Burch added a comment -

          It might be good to try the widened versions with Tika Batch, to see if on a wide range of files it causes any noticable slowdown or false positives?

          I still think this isn't a file format that can be fully reliably detected with mime magic alone, and ideally we do need a dedicated detector for it as mentioned above, to fully solve this and related (eg multipart/signed) detection

          Show
          gagravarr Nick Burch added a comment - It might be good to try the widened versions with Tika Batch, to see if on a wide range of files it causes any noticable slowdown or false positives? I still think this isn't a file format that can be fully reliably detected with mime magic alone, and ideally we do need a dedicated detector for it as mentioned above, to fully solve this and related (eg multipart/signed) detection
          Hide
          chrismattmann Chris A. Mattmann added a comment -

          So Jeremy B. Merrill proposed https://github.com/apache/tika/pull/40 as a solution to this. Nick, Konstantin - can you guys take a look and see if we can figure out how to get that included since we have code now that is fixing this.

          Show
          chrismattmann Chris A. Mattmann added a comment - So Jeremy B. Merrill proposed https://github.com/apache/tika/pull/40 as a solution to this. Nick, Konstantin - can you guys take a look and see if we can figure out how to get that included since we have code now that is fixing this.
          Hide
          lfcnassif Luis Filipe Nassif added a comment -

          Maybe we could keep the original magics and ADD the widened versions with a "\n" prefix to decrease the number of false positives (I have got a small number of them)? Could you try the widened magics with govdocs1 Tim Allison?

          Show
          lfcnassif Luis Filipe Nassif added a comment - Maybe we could keep the original magics and ADD the widened versions with a "\n" prefix to decrease the number of false positives (I have got a small number of them)? Could you try the widened magics with govdocs1 Tim Allison ?
          Hide
          tallison@mitre.org Tim Allison added a comment - - edited

          Y, will do. Results probably tomorrow.

          This?
          <mime-type type="message/rfc822">
          <magic priority="50">
          <match value="Relay-Version:" type="string" offset="0"/>
          <match value="#!\ rnews" type="string" offset="0"/>
          <match value="N#!\ rnews" type="string" offset="0"/>
          <match value="Forward\ to" type="string" offset="0"/>
          <match value="Pipe\ to" type="string" offset="0"/>
          <match value="Return-Path:" type="string" offset="0"/>
          <match value="\nReturn-Path:" type="string" offset="0:1000"/>
          <match value="From:" type="string" offset="0"/>
          <match value="Received:" type="string" offset="0"/>
          <match value="\nReceived:" type="string" offset="0:1000"/>
          <match value="Message-ID:" type="string" offset="0"/>
          <match value="\nMessage-ID:" type="string" offset="0:1000"/>
          <match value="Date:" type="string" offset="0"/>
          </magic>
          <glob pattern="*.eml"/>
          <glob pattern="*.mime"/>
          <glob pattern="*.mht"/>
          <glob pattern="*.mhtml"/>
          <sub-class-of type="text/plain"/>
          </mime-type>

          Show
          tallison@mitre.org Tim Allison added a comment - - edited Y, will do. Results probably tomorrow. This? <mime-type type="message/rfc822"> <magic priority="50"> <match value="Relay-Version:" type="string" offset="0"/> <match value="#!\ rnews" type="string" offset="0"/> <match value="N#!\ rnews" type="string" offset="0"/> <match value="Forward\ to" type="string" offset="0"/> <match value="Pipe\ to" type="string" offset="0"/> <match value="Return-Path:" type="string" offset="0"/> <match value="\nReturn-Path:" type="string" offset="0:1000"/> <match value="From:" type="string" offset="0"/> <match value="Received:" type="string" offset="0"/> <match value="\nReceived:" type="string" offset="0:1000"/> <match value="Message-ID:" type="string" offset="0"/> <match value="\nMessage-ID:" type="string" offset="0:1000"/> <match value="Date:" type="string" offset="0"/> </magic> <glob pattern="*.eml"/> <glob pattern="*.mime"/> <glob pattern="*.mht"/> <glob pattern="*.mhtml"/> <sub-class-of type="text/plain"/> </mime-type>
          Hide
          lfcnassif Luis Filipe Nassif added a comment -

          Yes, thank you very much for testing with govdocs1 (Nick Burch's suggestion)!

          Show
          lfcnassif Luis Filipe Nassif added a comment - Yes, thank you very much for testing with govdocs1 ( Nick Burch 's suggestion)!
          Hide
          lfcnassif Luis Filipe Nassif added a comment -

          Yes, thank you very much for testing with govdocs1 (Nick Burch's suggestion)!

          Show
          lfcnassif Luis Filipe Nassif added a comment - Yes, thank you very much for testing with govdocs1 ( Nick Burch 's suggestion)!
          Hide
          tallison@mitre.org Tim Allison added a comment -

          Only about ~300 more rfc822 files. I'll manually review some to see if the increase is good or bad.

          Show
          tallison@mitre.org Tim Allison added a comment - Only about ~300 more rfc822 files. I'll manually review some to see if the increase is good or bad.
          Hide
          chrismattmann Chris A. Mattmann added a comment -

          This is still open and we have a patch ready and available for TIKA-1602 - I am going to commit that patch (once updated with my comments from Github). Waiting for a more general solution is great, but if we have a patch that works at least in limited cases, my preference is to include that contribution and then improve later.

          Show
          chrismattmann Chris A. Mattmann added a comment - This is still open and we have a patch ready and available for TIKA-1602 - I am going to commit that patch (once updated with my comments from Github). Waiting for a more general solution is great, but if we have a patch that works at least in limited cases, my preference is to include that contribution and then improve later.
          Hide
          mcaruanagalizia Matthew Caruana Galizia added a comment -

          As described in TIKA-2042, the attached file mbox_email_section.txt contains a section of an MBOX file, itself containing a message stream which is detected as text/html instead of message/rfc822, even though the correct mimetype is set on the Metadata object by the MBOXParser.

          Show
          mcaruanagalizia Matthew Caruana Galizia added a comment - As described in TIKA-2042 , the attached file mbox_email_section.txt contains a section of an MBOX file, itself containing a message stream which is detected as text/html instead of message/rfc822, even though the correct mimetype is set on the Metadata object by the MBOXParser.

            People

            • Assignee:
              Unassigned
              Reporter:
              grossws Konstantin Gribov
            • Votes:
              1 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:

                Development