You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "Luis Filipe Nassif (JIRA)" <ji...@apache.org> on 2015/04/11 17:46:12 UTC

[jira] [Commented] (TIKA-1602) Detecting standards-non-compliant emails as message/rfc822

    [ https://issues.apache.org/jira/browse/TIKA-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491078#comment-14491078 ] 

Luis Filipe Nassif commented on TIKA-1602:
------------------------------------------

I think this is a duplicate of TIKA-879, where a more generic solution is discussed.

> Detecting standards-non-compliant emails as message/rfc822
> ----------------------------------------------------------
>
>                 Key: TIKA-1602
>                 URL: https://issues.apache.org/jira/browse/TIKA-1602
>             Project: Tika
>          Issue Type: New Feature
>            Reporter: Jeremy B. Merrill
>            Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Tika does not properly detect certain emails as `message/rfc822` if they're slightly standards-non-compliant and begin with `Status: ` as the first header. I've added `Status: ` as a magic detection line in tika-mimetypes.xml. 
> This solves my problem and does not appear to cause unit test failures. I have not yet run the tika-batch tests.
> As further information, the emails that are processed incorrectly come from dumps directly from various US public officials' mailservers. The dumps, I believe since they're not intended to be transmitted over the wire, sometimes are slightly non-compliant. 
> It's important to note that Tika (and the underlying library, James Mime4J) do properly *parse* these emails, despite the non-compliant header. The problem is getting Tika to *detect* the file as an email so that Mime4J gets chosen to parse it.
> Pull request on Github at https://github.com/apache/tika/pull/40



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)