[ 
https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632946#action_12632946
 ] 

Robert Burrell Donkin commented on MIME4J-57:
---------------------------------------------

In favour but have some small nits (I can easily jump in and patch these 
afterwards if there's agreement)

@@ -78,6 +88,9 @@
         while ((ch = in.read()) != -1) {
             dst.append(ch);
             total++;
+            if (this.maxLineLen > 0 && dst.length() >= this.maxLineLen) {
+                throw new IOException("Maximum line length limit exceeded");
+            }
             if (ch == '\n') {
                 break;
             }

I wonder whether a specific MimeException subclass might be more better. This 
would allow a user to catch and retry with a longer line limit.

===================================================================
--- src/main/java/org/apache/james/mime4j/parser/MimeStreamParser.java  
(revision 697358)
+++ src/main/java/org/apache/james/mime4j/parser/MimeStreamParser.java  
(working copy)
@@ -45,13 +45,30 @@
 
     private ContentHandler handler = null;
     private boolean contentDecoding;
-    private final MimeTokenStream mimeTokenStream = new MimeTokenStream();
+    
+    private final MimeTokenStream mimeTokenStream;
 
-    public MimeStreamParser() {
+    public MimeStreamParser(final MimeEntityConfig config) {
         super();
+        MimeEntityConfig localConfig;
+        if (config != null) {
+            try {
+                localConfig = (MimeEntityConfig) config.clone();
+            } catch (CloneNotSupportedException ex) {
+                // should never happen
+                localConfig = new MimeEntityConfig();
+            }
+        } else {
+            localConfig = new MimeEntityConfig();
+        }
+        this.mimeTokenStream = new MimeTokenStream(localConfig);
         this.contentDecoding = false;
     }

Should probably add a few javadoc documentation lines into MimeEntityConfig 
explaining why it needs to be cloneable since subclassers need to beware. 

Alternatively, might be better just to make MimeEntityConfig immutable and so 
avoid all this cloning. This would be my preferred solution.

> Add a max limit to header length for parsing.
> ---------------------------------------------
>
>                 Key: MIME4J-57
>                 URL: https://issues.apache.org/jira/browse/MIME4J-57
>             Project: JAMES Mime4j
>          Issue Type: Bug
>    Affects Versions: 0.3
>            Reporter: Stefano Bagnara
>            Priority: Critical
>             Fix For: 0.5
>
>         Attachments: maxlinelen.patch
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. 
> This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes 
> per line, of course we may want to support longer headers, but not very long 
> ones.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to