[jira] [Created] (MIME4J-256) DefaultMessageBuilder.parseMessage should honor MaxHeaderLen over MaxLineLen

["Remmelt Pit (JIRA)" <mi...@james.apache.org>]

Remmelt Pit created MIME4J-256:
----------------------------------

             Summary: DefaultMessageBuilder.parseMessage should honor MaxHeaderLen over MaxLineLen
                 Key: MIME4J-256
                 URL: https://issues.apache.org/jira/browse/MIME4J-256
             Project: James Mime4j
          Issue Type: Bug
    Affects Versions: 0.8.0
            Reporter: Remmelt Pit


Upon parsing a message using DefaultMessageBuilder.parseMessage(InputStream), the max header length is measured _after_ max line length, even for header lines. This should not be the case.

Our use case is to support body line lengths up to 1,000 characters, and header lines up to 10,000 characters. This is the default as found in MimeConfig.Builder().
From these defaults, it would seem that header lines are measured differently than body lines, and can be longer.

This is not actually the case, since header lines will also be measured like body lines, even _before_ they are measured as header lines.

Example code:
{code}
         String messageText = "From: from@example.com\n" +
                "To: to@example.com\n" +
                "\n" +
                "Message\n";

        MimeConfig mimeConfig = new MimeConfig.Builder()
                .setMaxHeaderLen(1000)
                .setMaxLineLen(10)
                .build();

        DefaultMessageBuilder messageBuilder = new DefaultMessageBuilder();
        messageBuilder.setMimeEntityConfig(mimeConfig);
        messageBuilder.parseMessage(new ByteArrayInputStream(messageText.getBytes(StandardCharsets.UTF_8)));
{code}

What I would expect to happen: Message is created without exception. 

What actually happens: MaxLineLimitException is thrown because of the "From:" header line.

For now a workaround could be to set the maxLineLength to -1, to disable that check. We don't want to run without the body line length check, though.



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