[
https://issues.apache.org/jira/browse/TIKA-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Allison updated TIKA-3962:
------------------------------
Attachment: TIKA-2680-1.eml.-2.6.0.json
TIKA-2680-1.eml-2.7.0-prerc1.json
> Set RFC822 parser to noRecurse
> ------------------------------
>
> Key: TIKA-3962
> URL: https://issues.apache.org/jira/browse/TIKA-3962
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Minor
> Fix For: 2.7.0
>
> Attachments: TIKA-2680-1.eml-2.7.0-prerc1.json,
> TIKA-2680-1.eml.-2.6.0.json
>
>
> On our test file {{testGroupWiseEml.eml}}, there's an embedded rfc822
> attachment that is currently not treated as an attachment but is inlined.
> The relevant section of the test file is:
> {noformat}
> Content-Type: message/rfc822
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="test.eml"
> {noformat}
> When I open the email in several email clients, it shows this {{test.eml}}
> correctly as an attachment.
> It turns out there's a setting on mime4j's parser "setNoRecurse" that yields
> the correct behavior on this test file. Given that Tika handles files
> recursively already by default, I _think_ we should be safe to set no recurse
> in the mime4j parser and rely on Tika's own recursive parsing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
