I believe this bug has already been resolved in the current SVN trunk.
Probably in the course of
http://issues.apache.org/jira/browse/MIME4J-138..
Please create a new JIRA issue if I am wrong.
Best regards,
Markus
On Thu, Dec 3, 2009 at 11:31 PM, Wim Jongman <wim.jongman@gmail.com> wrote:
> Hi,
>
> Decoderutil crashes on this subject line:
>
> =?utf-8?Q?variable=20${target.nl}?=
>
> Illegal group reference
> at java.util.regex.Matcher.appendReplacement(Unknown Source)
> at
> org.apache.james.mime4j.codec.DecoderUtil.decodeEncodedWords(DecoderUtil.java:160)
>
>
> Best regards,
>
> Wim
Hi Wim,
would you mind open a jira bug report ?
https://issues.apache.org/jira/browse/MIME4J
We will take the needed steps then to fix the bug.
Thx for using MIME4J
Bye,
Norman
2009/12/3 Wim Jongman <wim.jongman@gmail.com>:
> Hi,
>
> Decoderutil crashes on this subject line:
>
> =?utf-8?Q?variable=20${target.nl}?=
>
> Illegal group reference
> at java.util.regex.Matcher.appendReplacement(Unknown Source)
> at
> org.apache.james.mime4j.codec.DecoderUtil.decodeEncodedWords(DecoderUtil.java:160)
>
>
> Best regards,
>
> Wim
>
Hi,
Decoderutil crashes on this subject line:
=?utf-8?Q?variable=20${target.nl}?=
Illegal group reference
at java.util.regex.Matcher.appendReplacement(Unknown Source)
at
org.apache.james.mime4j.codec.DecoderUtil.decodeEncodedWords(DecoderUtil.java:160)
Best regards,
Wim
[ https://issues.apache.org/jira/browse/MIME4J-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norman Maurer resolved MIME4J-133.
----------------------------------
Resolution: Fixed
http://www.apache.org/licenses/exports/ <- updated and email sent
> File ECCN 5D002 notice for Mime4j
> ---------------------------------
>
> Key: MIME4J-133
> URL: https://issues.apache.org/jira/browse/MIME4J-133
> Project: JAMES Mime4j
> Issue Type: Sub-task
> Affects Versions: 0.7
> Reporter: Robert Burrell Donkin
> Assignee: Norman Maurer
> Priority: Blocker
> Fix For: 0.7
>
>
> Hey Danny!
> Looks like we need to notify the US government about Mime4j.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MIME4J-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784965#action_12784965
]
Oleg Kalnichevski commented on MIME4J-141:
------------------------------------------
Makes sense. Removed. Please review.
Oleg
> DefaultFieldParser / DelegatingFieldParser incorrectly reject folded headers as invalid
> ---------------------------------------------------------------------------------------
>
> Key: MIME4J-141
> URL: https://issues.apache.org/jira/browse/MIME4J-141
> Project: JAMES Mime4j
> Issue Type: Bug
> Reporter: Oleg Kalnichevski
> Fix For: 0.7
>
>
> DefaultFieldParser / DelegatingFieldParser incorrectly reject folded headers as invalid.
Value of the header field must be unfolded prior to parsing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Author: olegk
Date: Wed Dec 2 19:12:45 2009
New Revision: 886266
URL: http://svn.apache.org/viewvc?rev=886266&view=rev
Log:
MIME4J-141: removed unnecessary MimeUtil.unfold() call in AbstractField
Modified:
james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/AbstractField.java
Modified: james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/AbstractField.java
URL: http://svn.apache.org/viewvc/james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/AbstractField.java?rev=886266&r1=886265&r2=886266&view=diff
==============================================================================
--- james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/AbstractField.java
(original)
+++ james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/AbstractField.java
Wed Dec 2 19:12:45 2009
@@ -149,21 +149,13 @@
private static ParsedField parse(final ByteSequence raw, final String rawStr)
throws MimeException {
- /*
- * Unfold the field.
- */
- final String unfolded = MimeUtil.unfold(rawStr);
-
- /*
- * Split into name and value.
- */
- final Matcher fieldMatcher = FIELD_NAME_PATTERN.matcher(unfolded);
+ final Matcher fieldMatcher = FIELD_NAME_PATTERN.matcher(rawStr);
if (!fieldMatcher.find()) {
throw new MimeException("Invalid field in string");
}
final String name = fieldMatcher.group(1);
- String body = unfolded.substring(fieldMatcher.end());
+ String body = rawStr.substring(fieldMatcher.end());
if (body.length() > 0 && body.charAt(0) == ' ') {
body = body.substring(1);
}
[ https://issues.apache.org/jira/browse/MIME4J-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784953#action_12784953
]
Norman Maurer commented on MIME4J-133:
--------------------------------------
Hi Markus,
I just committed the changes to the export site. Let us wait till it will show up, then I
will send the email. So no need to remove the code..
> File ECCN 5D002 notice for Mime4j
> ---------------------------------
>
> Key: MIME4J-133
> URL: https://issues.apache.org/jira/browse/MIME4J-133
> Project: JAMES Mime4j
> Issue Type: Sub-task
> Affects Versions: 0.7
> Reporter: Robert Burrell Donkin
> Assignee: Norman Maurer
> Priority: Blocker
> Fix For: 0.7
>
>
> Hey Danny!
> Looks like we need to notify the US government about Mime4j.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MIME4J-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784827#action_12784827
]
Markus Wiederkehr commented on MIME4J-133:
------------------------------------------
Mime4j has a storage module where messages or parts of messages can be stored and later retrieved.
See interface org.apache.james.mime4j.storage.StorageProvider.
One of the implementations of StorageProvider transparently scrambles and unscrambles the
data as it is written and read back. See class CipherStorageProvider in the same package.
I added that class more for demonstration purposes and wasn't aware that it would cause such
a fuss since it does not do any crypto by itself but merely calls existing JRE code.
Anyway, I wouldn't have a problem if we removed this class instead, as I have stated earlier.
> File ECCN 5D002 notice for Mime4j
> ---------------------------------
>
> Key: MIME4J-133
> URL: https://issues.apache.org/jira/browse/MIME4J-133
> Project: JAMES Mime4j
> Issue Type: Sub-task
> Affects Versions: 0.7
> Reporter: Robert Burrell Donkin
> Assignee: Norman Maurer
> Priority: Blocker
> Fix For: 0.7
>
>
> Hey Danny!
> Looks like we need to notify the US government about Mime4j.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MIME4J-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784826#action_12784826
]
Norman Maurer commented on MIME4J-133:
--------------------------------------
@Robert:
Could you explain why it need crypto stuff and for what ?
Thx,
Norman
> File ECCN 5D002 notice for Mime4j
> ---------------------------------
>
> Key: MIME4J-133
> URL: https://issues.apache.org/jira/browse/MIME4J-133
> Project: JAMES Mime4j
> Issue Type: Sub-task
> Affects Versions: 0.7
> Reporter: Robert Burrell Donkin
> Assignee: Norman Maurer
> Priority: Blocker
> Fix For: 0.7
>
>
> Hey Danny!
> Looks like we need to notify the US government about Mime4j.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MIME4J-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Wiederkehr updated MIME4J-130:
-------------------------------------
Fix Version/s: (was: 0.7)
0.8
Assignee: (was: Markus Wiederkehr)
> Add parse method for e-mail addresses that contain special characters in the display
name
> -----------------------------------------------------------------------------------------
>
> Key: MIME4J-130
> URL: https://issues.apache.org/jira/browse/MIME4J-130
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.6
> Reporter: Markus Wiederkehr
> Fix For: 0.8
>
>
> Address.parse(), Group.parse() and Mailbox.parse() can only parse addresses in their
raw (encoded) form. They are capable of decoding encoded words (RFC 2047) but they do not
accept already decoded special characters.
> In other words, they can parse the result of Address.getEncodedString() but not Address.getDisplayString().
> Mime4j should have a means to parse an address such as "Hans Müller <hans.mueller@acme.com>"
for generating new messages or manipulating existing ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MIME4J-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784453#action_12784453
]
Markus Wiederkehr commented on MIME4J-141:
------------------------------------------
Look okay to me.
I guess the MimeUtil.unfold() call in AbstractField line 155 does not make much sense after
your change.
At least all tests seem to pass if the call gets removed.
Opinions?
> DefaultFieldParser / DelegatingFieldParser incorrectly reject folded headers as invalid
> ---------------------------------------------------------------------------------------
>
> Key: MIME4J-141
> URL: https://issues.apache.org/jira/browse/MIME4J-141
> Project: JAMES Mime4j
> Issue Type: Bug
> Reporter: Oleg Kalnichevski
> Fix For: 0.7
>
>
> DefaultFieldParser / DelegatingFieldParser incorrectly reject folded headers as invalid.
Value of the header field must be unfolded prior to parsing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MIME4J-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Wiederkehr updated MIME4J-109:
-------------------------------------
Fix Version/s: (was: 0.7)
0.8
> Support for MIME Parameter Value and Encoded Word Extensions
> ------------------------------------------------------------
>
> Key: MIME4J-109
> URL: https://issues.apache.org/jira/browse/MIME4J-109
> Project: JAMES Mime4j
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Assignee: Markus Wiederkehr
> Fix For: 0.8
>
>
> See RFC 2231.
> Mime4j should be capable of correctly decoding and encoding these extensions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
On Tue, Dec 1, 2009 at 10:16 PM, Stefano Bagnara <apache@bago.org> wrote: > 2009/12/1 Oleg Kalnichevski <olegk@apache.org>: >> Folks, >> >> Could you please invest a few minutes into a quick review of open issues and >> reassign some of them to a later target (0.8 / 0.9 / 1.0)? It would be great >> to have a more concrete / realistic road map for the 0.7 release. > > I moved any unussigned&unresolved issue from 0.7 to 0.8 and I made the > crypto notice issue "blocker" for a release. > > Markus have this 2 issues assigned: > MIME4J-109 - Support for MIME Parameter Value and Encoded Word Extensions > http://issues.apache.org/jira/browse/MIME4J-109 > MIME4J-130 - Add parse method for e-mail addresses that contain > special characters in the display name > http://issues.apache.org/jira/browse/MIME4J-130 I don't have time for #109 ATM and I'm still not sure how to address #130 so I'm going to move both to 0.8.. Markus > > Robert have 2 issues assigned: > MIME4J-98 - Review Use Of java.util.Date > http://issues.apache.org/jira/browse/MIME4J-98 > MIME4J-131 - Factor out storage module > http://issues.apache.org/jira/browse/MIME4J-131 > > Robert, Markus, can you updated the status or move them to the 0.8 if > you don't plan to resolve them soon? > > Stefano
2009/12/1 Oleg Kalnichevski <olegk@apache.org>: > Folks, > > Could you please invest a few minutes into a quick review of open issues and > reassign some of them to a later target (0.8 / 0.9 / 1.0)? It would be great > to have a more concrete / realistic road map for the 0.7 release. I moved any unussigned&unresolved issue from 0.7 to 0.8 and I made the crypto notice issue "blocker" for a release. Markus have this 2 issues assigned: MIME4J-109 - Support for MIME Parameter Value and Encoded Word Extensions http://issues.apache.org/jira/browse/MIME4J-109 MIME4J-130 - Add parse method for e-mail addresses that contain special characters in the display name http://issues.apache.org/jira/browse/MIME4J-130 Robert have 2 issues assigned: MIME4J-98 - Review Use Of java.util.Date http://issues.apache.org/jira/browse/MIME4J-98 MIME4J-131 - Factor out storage module http://issues.apache.org/jira/browse/MIME4J-131 Robert, Markus, can you updated the status or move them to the 0.8 if you don't plan to resolve them soon? Stefano
[ https://issues.apache.org/jira/browse/MIME4J-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara reassigned MIME4J-133:
--------------------------------------
Assignee: Norman Maurer (was: Danny Angus)
I think this is now a duty for Norman ;-)
This can be done together with jDKIM and mailet-crypto stuff.
Is there anything other project we can notify in the mean time?
> File ECCN 5D002 notice for Mime4j
> ---------------------------------
>
> Key: MIME4J-133
> URL: https://issues.apache.org/jira/browse/MIME4J-133
> Project: JAMES Mime4j
> Issue Type: Sub-task
> Affects Versions: 0.7
> Reporter: Robert Burrell Donkin
> Assignee: Norman Maurer
> Fix For: 0.7
>
>
> Hey Danny!
> Looks like we need to notify the US government about Mime4j.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MIME4J-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara updated MIME4J-133:
-----------------------------------
Priority: Blocker (was: Major)
> File ECCN 5D002 notice for Mime4j
> ---------------------------------
>
> Key: MIME4J-133
> URL: https://issues.apache.org/jira/browse/MIME4J-133
> Project: JAMES Mime4j
> Issue Type: Sub-task
> Affects Versions: 0.7
> Reporter: Robert Burrell Donkin
> Assignee: Norman Maurer
> Priority: Blocker
> Fix For: 0.7
>
>
> Hey Danny!
> Looks like we need to notify the US government about Mime4j.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Norman Maurer wrote: > I can take care if noone else want to tackle it.. > > Bye, > Norman > > 2009/11/17 Oleg Kalnichevski <olegk@apache.org>: >> Markus Wiederkehr wrote: >>> Mime4j development seems to progress very slow at the moment. To me it >>> does not look like that's going to change anytime soon. >>> >>> But since 0.6 we have fixed three important bugs in trunk (MIME4J-138, >>> 139 and 140). >>> >>> If 0.7 cannot be expected soon, should we cut a 0.6.1 instead? >>> >>> Markus >> >> And who would be willing to act as a release manager? >> >> Oleg >> Folks, Could you please invest a few minutes into a quick review of open issues and reassign some of them to a later target (0.8 / 0.9 / 1.0)? It would be great to have a more concrete / realistic road map for the 0.7 release. Oleg
[ https://issues.apache.org/jira/browse/MIME4J-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved MIME4J-141.
--------------------------------------
Resolution: Fixed
Fix Version/s: 0.7
Fixed in SVN trunk. Please review.
Oleg
> DefaultFieldParser / DelegatingFieldParser incorrectly reject folded headers as invalid
> ---------------------------------------------------------------------------------------
>
> Key: MIME4J-141
> URL: https://issues.apache.org/jira/browse/MIME4J-141
> Project: JAMES Mime4j
> Issue Type: Bug
> Reporter: Oleg Kalnichevski
> Fix For: 0.7
>
>
> DefaultFieldParser / DelegatingFieldParser incorrectly reject folded headers as invalid.
Value of the header field must be unfolded prior to parsing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Author: olegk
Date: Tue Dec 1 20:54:22 2009
New Revision: 885926
URL: http://svn.apache.org/viewvc?rev=885926&view=rev
Log:
MIME4J-141: DefaultFieldParser / DelegatingFieldParser incorrectly reject folded headers as
invalid
Modified:
james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/DelegatingFieldParser.java
Modified: james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/DelegatingFieldParser.java
URL: http://svn.apache.org/viewvc/james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/DelegatingFieldParser.java?rev=885926&r1=885925&r2=885926&view=diff
==============================================================================
--- james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/DelegatingFieldParser.java
(original)
+++ james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/field/DelegatingFieldParser.java
Tue Dec 1 20:54:22 2009
@@ -23,6 +23,7 @@
import java.util.Map;
import org.apache.james.mime4j.util.ByteSequence;
+import org.apache.james.mime4j.util.MimeUtil;
public class DelegatingFieldParser implements FieldParser {
private static final FieldParser DEFAULT_PARSER = UnstructuredField.PARSER;
@@ -48,6 +49,6 @@
public ParsedField parse(final String name, final String body, final ByteSequence raw)
{
final FieldParser parser = getParser(name);
- return parser.parse(name, body, raw);
+ return parser.parse(name, MimeUtil.unfold(body), raw);
}
}
DefaultFieldParser / DelegatingFieldParser incorrectly reject folded headers as invalid
---------------------------------------------------------------------------------------
Key: MIME4J-141
URL: https://issues.apache.org/jira/browse/MIME4J-141
Project: JAMES Mime4j
Issue Type: Bug
Reporter: Oleg Kalnichevski
DefaultFieldParser / DelegatingFieldParser incorrectly reject folded headers as invalid. Value
of the header field must be unfolded prior to parsing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MIME4J-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved MIME4J-140.
--------------------------------------
Resolution: Fixed
Fix Version/s: 0.7
Marking as resolved
Oleg
> MIME4J-57 is not practical in its limits and incorrect in its RFC interpretation
> --------------------------------------------------------------------------------
>
> Key: MIME4J-140
> URL: https://issues.apache.org/jira/browse/MIME4J-140
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.6
> Reporter: mike bell
> Assignee: Markus Wiederkehr
> Fix For: 0.7
>
>
> I have begun playing with Mime4j for potential use in a software project. Very quickly
I found a simple email (Which i can attach) which has about 30 TO addresses. The default was
to throw an exception
> Looking at MIME4J-57 the author has misunderstood the SMTP RFC 2821. Yes you are limited
to 998 octets PER LINE, but you may FOLD as many 998 octet lines as you wish. Technically
it's 100% legal to have a 50 megabyte header value, as long as it is folded. (per 76 or 998
rules).
> I think the limit chosen by default of 1000 is absurdly low - this should be 100000 minimum
or perhaps even unlimited by default. There is something to be said for a sanity check option,
for sure - but not one that is triggered so easily.
> I can also open somewhat related JIRAS if people find them of merit:
> 1. Documentation - defaults should be clearly stated in MimeEntityConfig javadoc. They
are not
> 2. Bug - The javadocs for MimeEntityConfig claim mc.setMaxHeaderCount(-1); would defeat;
this check. It does not (I worked around with Integer.MaxValue)
> 3. Design Question: Should the MimeTokenStream not have a public constructor that allows
MimeEntityConfig to be fed. As it was I had to create my own subclass to access the protected
constructor - is there a reason for this?
> Thanks
> Example header that blew stuff up (and I think we've all seen far far worse!) - The To
line triggers this
> Return-Path: <tomxypdq@hotmail.com>
> Received: from c.mx.sonic.net (c.mx.sonic.net [64.142.100.46])
> by eth0.a.lds.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id mBT21U5h027864;
> Sun, 28 Dec 2008 18:01:30 -0800
> Received: from bay0-omc2-s13.bay0.hotmail.com (bay0-omc2-s13.bay0.hotmail.com [65.54.246.149])
> by c.mx.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id mBT21QuA026548;
> Sun, 28 Dec 2008 18:01:30 -0800
> Received: from BAY117-W11 ([207.46.8.46]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft
SMTPSVC(6.0.3790.3959);
> Sun, 28 Dec 2008 18:01:26 -0800
> Message-ID: <BAY117-W1177D87B46BEFE5606716BDDE60@phx.gbl>
> Content-Type: multipart/mixed;
> boundary="_03df338b-5029-48d8-84e8-34f5e171dcbd_"
> X-Originating-IP: [96.228.108.66]
> From: Tommy Clark <tomxypdq@hotmail.com>
> To: <alayne.newton@thomson.com>,
> Alexandra Droman
> <alexandra_dorman_100@yahoo.com>,
> Alexis Steinkamp <lexilooo@hotmail.com>, <asteinkamp@ameritech.net>,
> <attame@msn.com>, Ben Greenberg
> <bprofane68@hotmail.com>,
> blythe gross <muppetgirl1969@yahoo.com>, <brenden@mediamystic.com>,
> <cliverping@hotmail.com>, Dae-Jin Kim
> <polykor@chollian.net>,
> Doug Arthur <dougside@yahoo.com>,
> Dox Doxiadis
> <evdoxios.doxiadis@gmail.com>, <doxiadis@princeton.edu>,
> Haidde Sprague
> <haidee.sprague@gmail.com>,
> James Lee <jcl0072@hotmail.com>, Jeff Dorman
> <bub365@aol.com>,
> <jeffejeff@gmail.com>, "Jeff Lim (E-mail)"
> <jeffreyelim@hotmail.com>,
> Jeff Moshman <jmosesian@sonic.net>, Karen Wolfe
> <kaka_2702@yahoo.com>,
> <keirabby@charter.net>, keirabby
> <keirabby@cableone.net>,
> <keirmo@yahoo.com>, Kerry Levenberg
> <kerry@levenbergs.com>,
> Kim-Chi Steger <kcsteger@aol.com>, <lornap78@hotmail.com>,
> <mbell90@sonic.net>, mike bell <mjb@gwava.com>, <myra13@aol.com>,
> Natalie Stange <nstange@nyc.rr.com>,
> karen wolfe
> <ngocbao99@yahoo.com>, <polykor@chol.com>,
> Rob Cliver
> <cliver@fulbrightweb.org>, Sharon Lee <weronron@yahoo.com>,
> the Clarks
> <bosudary@comcast.net>, Ward Breeze <wbreeze@gunder.com>,
> <whosbarley@yahoo.com>
> Subject: N More THANKS
> Date: Sun, 28 Dec 2008 18:01:25 -0800
> Importance: Normal
> In-Reply-To: <BAY117-W268E2179DDEE877110AF11DDE60@phx.gbl>
> References: <c46c51bb0812281737i256ae8depebb851f79b54c326@mail.gmail.com>
> <BAY117-W268E2179DDEE877110AF11DDE60@phx.gbl>
> MIME-Version: 1.0
> X-OriginalArrivalTime: 29 Dec 2008 02:01:26.0088 (UTC) FILETIME=[5B42CC80:01C96959]
> X-Sonic-SB-IP-RBLs: IP RBLs sorbs-spam.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
On Sat, Nov 28, 2009 at 12:19 AM, Oleg Kalnichevski <olegk@apache.org> wrote:
> Markus Wiederkehr wrote:
>>
>> On Fri, Nov 27, 2009 at 10:21 PM, Oleg Kalnichevski <olegk@apache.org>
>> wrote:
>>>
>>> Markus Wiederkehr wrote:
>>>>
>>>> On Fri, Nov 27, 2009 at 2:37 PM, Oleg Kalnichevski <olegk@apache.org>
>>>> wrote:
>>>>>
>>>>> Oleg Kalnichevski wrote:
>>>>>>
>>>>>> Markus et al
>>>>>>
>>>>>> The address list parser currently chokes on folded field values that
>>>>>> are
>>>>>> otherwise perfectly valid. That seems somewhat illogical to me. It
>>>>>> really
>>>>>> took me a while to figure out what was wrong with the address list
>>>>>> until
>>>>>> I
>>>>>> stumbled upon a commend about the parser expecting unfolded fields.
>>>>>> The
>>>>>> very
>>>>>> cryptic exception message did not really help either.
>>>>>>
>>>>>> What is the reason for this restriction? It is because folded values
>>>>>> are
>>>>>> difficult to parse with jjtree? Should not we unfold field values
>>>>>> automatically prior to feeding them to the parser?
>>>>
>>>> As for the reason, I don't know, that was before my time..
>>>>
>>> And also before mine
>>>
>>>
>>>>>> Oleg
>>>>>>
>>>>> DelegatingFieldParser#parse method does not automatically unfold the
>>>>> field
>>>>> body, which actually seems like a bug to me. What is the expected
>>>>> behavior
>>>>> of this method?
>>>>> From what I see the unfolding happens in
>>>>
>>>> AbstractField.parse(ByteSequence, String) at line 155. The call
>>>> hierarchy leads to AbstractField.parse(ByteSequence) and
>>>> MessageBuilder.field(Field)..
>>>>
>>>> I guess you should use AbstractField.parse(ByteSequence).
>>>>
>>> That still leaves us with DefaultFieldParser and DelegatingFieldParser
>>> that
>>> produce incorrect results, at least in my opinion.
>>
>> Are you referring to DelegatingFieldParser.parse(String, String,
>> ByteSequence)? That method implements FieldParser#parse which can only
>> be considered to be internal API in my opinion.
>
> That would not be a problem if DefaultFieldParser did not subclass
> DelegatingFieldParser
>
>
> Well maybe not quite,
>>
>> a user might want to implement a custom FieldParser but I don't think
>> this method is intended to be invoked directly.
>>
>> Generally you don't have the name, body and raw byte sequence at hand.
>
> When working with MimeTokenStream generally you do.
Okay, that makes sense.
Feel free to change the behaviour if you like (unless someone else
objects). Maybe it would also be sufficient to provide good
documentation for the current behaviour instead. I mean all you'd have
to do to fix your code is add one MimeUtil.unfold() call.
Markus
>
>> Usually name and body are computed from the raw byte sequence or vice
>> versa. So what's wrong with using AbstractField.parse(ByteSequence)
>> instead?
>>
>
> There is nothing wrong with it but inconveniently there is a public class
> called DefaultFieldParser, which seems to suggest that this is what users
> are supposed to use per default. Why would a user pick AbstractField over
> DefaultFieldParser to parse fields?
>
>
>>> Are there any objections to changing the behavior of these classes?
>>
>> I don't see the point. What's your use case?
>>
>
> MimeTokenStream mimestream = new MimeTokenStream();
> mimestream.parse(instream);
>
> FieldParser parser = new DefaultFieldParser();
> boolean completed = false;
> while (!completed) {
> int state = mimestream.getState();
> switch (state) {
> case MimeTokenStream.T_FIELD:
> Field field = mimestream.getField();
> String name = field.getName();
> String body = field.getBody();
> ByteSequence raw = field.getRaw();
> ParsedField parsedField = parser.parse(name, body, raw);
> break;
> case MimeTokenStream.T_END_OF_STREAM:
> completed = true;
> break;
> }
> if (!completed) {
> mimestream.next();
> }
> }
>
> Oleg
>
>> Markus
>>
>>> Oleg
>>>
>>>> Markus
Markus Wiederkehr wrote:
> On Fri, Nov 27, 2009 at 10:21 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
>> Markus Wiederkehr wrote:
>>> On Fri, Nov 27, 2009 at 2:37 PM, Oleg Kalnichevski <olegk@apache.org>
>>> wrote:
>>>> Oleg Kalnichevski wrote:
>>>>> Markus et al
>>>>>
>>>>> The address list parser currently chokes on folded field values that
are
>>>>> otherwise perfectly valid. That seems somewhat illogical to me. It
>>>>> really
>>>>> took me a while to figure out what was wrong with the address list until
>>>>> I
>>>>> stumbled upon a commend about the parser expecting unfolded fields. The
>>>>> very
>>>>> cryptic exception message did not really help either.
>>>>>
>>>>> What is the reason for this restriction? It is because folded values
are
>>>>> difficult to parse with jjtree? Should not we unfold field values
>>>>> automatically prior to feeding them to the parser?
>>> As for the reason, I don't know, that was before my time..
>>>
>> And also before mine
>>
>>
>>>>> Oleg
>>>>>
>>>> DelegatingFieldParser#parse method does not automatically unfold the
>>>> field
>>>> body, which actually seems like a bug to me. What is the expected
>>>> behavior
>>>> of this method?
>>>> From what I see the unfolding happens in
>>> AbstractField.parse(ByteSequence, String) at line 155. The call
>>> hierarchy leads to AbstractField.parse(ByteSequence) and
>>> MessageBuilder.field(Field)..
>>>
>>> I guess you should use AbstractField.parse(ByteSequence).
>>>
>> That still leaves us with DefaultFieldParser and DelegatingFieldParser that
>> produce incorrect results, at least in my opinion.
>
> Are you referring to DelegatingFieldParser.parse(String, String,
> ByteSequence)? That method implements FieldParser#parse which can only
> be considered to be internal API in my opinion.
That would not be a problem if DefaultFieldParser did not subclass
DelegatingFieldParser
Well maybe not quite,
> a user might want to implement a custom FieldParser but I don't think
> this method is intended to be invoked directly.
>
> Generally you don't have the name, body and raw byte sequence at hand.
When working with MimeTokenStream generally you do.
> Usually name and body are computed from the raw byte sequence or vice
> versa. So what's wrong with using AbstractField.parse(ByteSequence)
> instead?
>
There is nothing wrong with it but inconveniently there is a public
class called DefaultFieldParser, which seems to suggest that this is
what users are supposed to use per default. Why would a user pick
AbstractField over DefaultFieldParser to parse fields?
>> Are there any objections to changing the behavior of these classes?
>
> I don't see the point. What's your use case?
>
MimeTokenStream mimestream = new MimeTokenStream();
mimestream.parse(instream);
FieldParser parser = new DefaultFieldParser();
boolean completed = false;
while (!completed) {
int state = mimestream.getState();
switch (state) {
case MimeTokenStream.T_FIELD:
Field field = mimestream.getField();
String name = field.getName();
String body = field.getBody();
ByteSequence raw = field.getRaw();
ParsedField parsedField = parser.parse(name, body, raw);
break;
case MimeTokenStream.T_END_OF_STREAM:
completed = true;
break;
}
if (!completed) {
mimestream.next();
}
}
Oleg
> Markus
>
>> Oleg
>>
>>> Markus
>
On Fri, Nov 27, 2009 at 10:21 PM, Oleg Kalnichevski <olegk@apache.org> wrote: > Markus Wiederkehr wrote: >> >> On Fri, Nov 27, 2009 at 2:37 PM, Oleg Kalnichevski <olegk@apache.org> >> wrote: >>> >>> Oleg Kalnichevski wrote: >>>> >>>> Markus et al >>>> >>>> The address list parser currently chokes on folded field values that are >>>> otherwise perfectly valid. That seems somewhat illogical to me. It >>>> really >>>> took me a while to figure out what was wrong with the address list until >>>> I >>>> stumbled upon a commend about the parser expecting unfolded fields. The >>>> very >>>> cryptic exception message did not really help either. >>>> >>>> What is the reason for this restriction? It is because folded values are >>>> difficult to parse with jjtree? Should not we unfold field values >>>> automatically prior to feeding them to the parser? >> >> As for the reason, I don't know, that was before my time.. >> > > And also before mine > > >>>> Oleg >>>> >>> DelegatingFieldParser#parse method does not automatically unfold the >>> field >>> body, which actually seems like a bug to me. What is the expected >>> behavior >>> of this method? >> >>> From what I see the unfolding happens in >> >> AbstractField.parse(ByteSequence, String) at line 155. The call >> hierarchy leads to AbstractField.parse(ByteSequence) and >> MessageBuilder.field(Field).. >> >> I guess you should use AbstractField.parse(ByteSequence). >> > > That still leaves us with DefaultFieldParser and DelegatingFieldParser that > produce incorrect results, at least in my opinion. Are you referring to DelegatingFieldParser.parse(String, String, ByteSequence)? That method implements FieldParser#parse which can only be considered to be internal API in my opinion. Well maybe not quite, a user might want to implement a custom FieldParser but I don't think this method is intended to be invoked directly. Generally you don't have the name, body and raw byte sequence at hand. Usually name and body are computed from the raw byte sequence or vice versa. So what's wrong with using AbstractField.parse(ByteSequence) instead? > Are there any objections to changing the behavior of these classes? I don't see the point. What's your use case? Markus > Oleg > >> Markus
Markus Wiederkehr wrote: > On Fri, Nov 27, 2009 at 2:37 PM, Oleg Kalnichevski <olegk@apache.org> wrote: >> Oleg Kalnichevski wrote: >>> Markus et al >>> >>> The address list parser currently chokes on folded field values that are >>> otherwise perfectly valid. That seems somewhat illogical to me. It really >>> took me a while to figure out what was wrong with the address list until I >>> stumbled upon a commend about the parser expecting unfolded fields. The very >>> cryptic exception message did not really help either. >>> >>> What is the reason for this restriction? It is because folded values are >>> difficult to parse with jjtree? Should not we unfold field values >>> automatically prior to feeding them to the parser? > > As for the reason, I don't know, that was before my time.. > And also before mine >>> Oleg >>> >> DelegatingFieldParser#parse method does not automatically unfold the field >> body, which actually seems like a bug to me. What is the expected behavior >> of this method? > >>>From what I see the unfolding happens in > AbstractField.parse(ByteSequence, String) at line 155. The call > hierarchy leads to AbstractField.parse(ByteSequence) and > MessageBuilder.field(Field).. > > I guess you should use AbstractField.parse(ByteSequence). > That still leaves us with DefaultFieldParser and DelegatingFieldParser that produce incorrect results, at least in my opinion. Are there any objections to changing the behavior of these classes? Oleg > Markus >
On Fri, Nov 27, 2009 at 2:37 PM, Oleg Kalnichevski <olegk@apache.org> wrote: > Oleg Kalnichevski wrote: >> >> Markus et al >> >> The address list parser currently chokes on folded field values that are >> otherwise perfectly valid. That seems somewhat illogical to me. It really >> took me a while to figure out what was wrong with the address list until I >> stumbled upon a commend about the parser expecting unfolded fields. The very >> cryptic exception message did not really help either. >> >> What is the reason for this restriction? It is because folded values are >> difficult to parse with jjtree? Should not we unfold field values >> automatically prior to feeding them to the parser? As for the reason, I don't know, that was before my time.. >> Oleg >> > > DelegatingFieldParser#parse method does not automatically unfold the field > body, which actually seems like a bug to me. What is the expected behavior > of this method? >From what I see the unfolding happens in AbstractField.parse(ByteSequence, String) at line 155. The call hierarchy leads to AbstractField.parse(ByteSequence) and MessageBuilder.field(Field).. I guess you should use AbstractField.parse(ByteSequence). Markus
Oleg Kalnichevski wrote: > Markus et al > > The address list parser currently chokes on folded field values that are > otherwise perfectly valid. That seems somewhat illogical to me. It > really took me a while to figure out what was wrong with the address > list until I stumbled upon a commend about the parser expecting unfolded > fields. The very cryptic exception message did not really help either. > > What is the reason for this restriction? It is because folded values are > difficult to parse with jjtree? Should not we unfold field values > automatically prior to feeding them to the parser? > > Oleg > DelegatingFieldParser#parse method does not automatically unfold the field body, which actually seems like a bug to me. What is the expected behavior of this method? Oleg
Markus et al The address list parser currently chokes on folded field values that are otherwise perfectly valid. That seems somewhat illogical to me. It really took me a while to figure out what was wrong with the address list until I stumbled upon a commend about the parser expecting unfolded fields. The very cryptic exception message did not really help either. What is the reason for this restriction? It is because folded values are difficult to parse with jjtree? Should not we unfold field values automatically prior to feeding them to the parser? Oleg
Hi Oleg, I will have a look soon. Thx for keeping us in the loop :) Bye, Norman 2009/11/23 Oleg Kalnichevski <olegk@apache.org>: > Norman Maurer wrote: >> >> Hi Oleg, >> >> I would be very interested in this :-) >> >> Bye, >> Norman >> > > Folks, > > I finally have the library in a fairly usable (or shall I rather say > testable) state. I can now send messages to the postfix daemon using my SMTP > client transport and have the messages passed onto the local LMTP agent > based on the same transport code for local delivery. > > In essence I have a reasonably complete SMTP/LMTP transport library that > implements RFC 2821 (minimum implementation), RFC 2033, plus a number of > extensions required by LMTP: RFC 2034 (ENHANCEDSTATUSCODES), RFC 1854 > (PIPELINING), RFC 1652 (8BITMIME). > > The code is still very experimental but good enough for getting the feel of > the API. > > Here's the sample of the LMTP transfer agent > > http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/LocalMailServerTransportExample.java > > Envelop validation / message delivery can be fully asynchronous. Long > running processes such as DB or LDAP queries can be executed without > blocking the I/O transport. > > The client side transport can either be event (callback) driven > > http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/LocalMailClientTransportExample.java > > or future driven > > http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/MailUserAgentExample.java > http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/SendMailExample.java > > The mail user agent can maintain a pool of persistent connections that can > be reused for subsequent delivery requests. > > The NIO framework is basically a fork of Apache HttpCore with all HTTP > dependencies removed. > > http://code.google.com/p/lightnio/ > > You would have to get the latest snapshots of both libraries in order to run > samples. > > I developed this code for my private use. If you do not think this is > something that can be potentially useful for a larger user base, just ignore > my message. > > Cheers > > Oleg > > > > >> 2009/6/12 Oleg Kalnichevski <olegk@apache.org>: >>> >>> On Thu, Jun 11, 2009 at 04:30:58PM +0200, Markus Wiederkehr wrote: >>>> >>>> I've written a class SmtpTransport that can be used to send a Mime4j >>>> message to an SMTP server. >>>> >>>> Currently it is very simple. Meaning it is not yet capable of >>>> authentication or TLS or other extensions. >>>> >>>> Would it be worth to include this code in Mime4j? >>>> >>>> Cheers, >>>> Markus >>>> >>>> PS: Testing is a bit of a PITA with sockets and all.. Robert, could >>>> MPT help with that? I haven't looked into it yet.. >>> >>> Markus et al >>> >>> _Coincidentally_, I have been working on a LMTP agent and LMTP client >>> with >>> support for mandatory extensions required by LMTP [1]: PIPELINING, >>> ENHANCEDSTATUSCODES and 8BITMIME. The implementation is based a NIO >>> framework >>> derived from HttpCore NIO and should be quite scalable. This is my >>> private >>> project, but if there is interest in such work, I am willing to >>> contribute it >>> to James. Alternatively you are very welcome to contribute to the effort. >>> It is >>> ASLv2 licensed. >>> >>> Cheers >>> >>> Oleg >>> >>> [1] http://www.ietf.org/rfc/rfc2033.txt >>> >>> >>> > >
Norman Maurer wrote: > Hi Oleg, > > I would be very interested in this :-) > > Bye, > Norman > Folks, I finally have the library in a fairly usable (or shall I rather say testable) state. I can now send messages to the postfix daemon using my SMTP client transport and have the messages passed onto the local LMTP agent based on the same transport code for local delivery. In essence I have a reasonably complete SMTP/LMTP transport library that implements RFC 2821 (minimum implementation), RFC 2033, plus a number of extensions required by LMTP: RFC 2034 (ENHANCEDSTATUSCODES), RFC 1854 (PIPELINING), RFC 1652 (8BITMIME). The code is still very experimental but good enough for getting the feel of the API. Here's the sample of the LMTP transfer agent http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/LocalMailServerTransportExample.java Envelop validation / message delivery can be fully asynchronous. Long running processes such as DB or LDAP queries can be executed without blocking the I/O transport. The client side transport can either be event (callback) driven http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/LocalMailClientTransportExample.java or future driven http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/MailUserAgentExample.java http://code.google.com/p/lightmtp/source/browse/trunk/src/examples/java/com/ok2c/lightmtp/examples/SendMailExample.java The mail user agent can maintain a pool of persistent connections that can be reused for subsequent delivery requests. The NIO framework is basically a fork of Apache HttpCore with all HTTP dependencies removed. http://code.google.com/p/lightnio/ You would have to get the latest snapshots of both libraries in order to run samples. I developed this code for my private use. If you do not think this is something that can be potentially useful for a larger user base, just ignore my message. Cheers Oleg > 2009/6/12 Oleg Kalnichevski <olegk@apache.org>: >> On Thu, Jun 11, 2009 at 04:30:58PM +0200, Markus Wiederkehr wrote: >>> I've written a class SmtpTransport that can be used to send a Mime4j >>> message to an SMTP server. >>> >>> Currently it is very simple. Meaning it is not yet capable of >>> authentication or TLS or other extensions. >>> >>> Would it be worth to include this code in Mime4j? >>> >>> Cheers, >>> Markus >>> >>> PS: Testing is a bit of a PITA with sockets and all.. Robert, could >>> MPT help with that? I haven't looked into it yet.. >> Markus et al >> >> _Coincidentally_, I have been working on a LMTP agent and LMTP client with >> support for mandatory extensions required by LMTP [1]: PIPELINING, >> ENHANCEDSTATUSCODES and 8BITMIME. The implementation is based a NIO framework >> derived from HttpCore NIO and should be quite scalable. This is my private >> project, but if there is interest in such work, I am willing to contribute it >> to James. Alternatively you are very welcome to contribute to the effort. It is >> ASLv2 licensed. >> >> Cheers >> >> Oleg >> >> [1] http://www.ietf.org/rfc/rfc2033.txt >> >> >>
I can take care if noone else want to tackle it.. Bye, Norman 2009/11/17 Oleg Kalnichevski <olegk@apache.org>: > Markus Wiederkehr wrote: >> >> Mime4j development seems to progress very slow at the moment. To me it >> does not look like that's going to change anytime soon. >> >> But since 0.6 we have fixed three important bugs in trunk (MIME4J-138, >> 139 and 140). >> >> If 0.7 cannot be expected soon, should we cut a 0.6.1 instead? >> >> Markus > > > And who would be willing to act as a release manager? > > Oleg >
Markus Wiederkehr wrote: > Mime4j development seems to progress very slow at the moment. To me it > does not look like that's going to change anytime soon. > > But since 0.6 we have fixed three important bugs in trunk (MIME4J-138, > 139 and 140). > > If 0.7 cannot be expected soon, should we cut a 0.6.1 instead? > > Markus And who would be willing to act as a release manager? Oleg
[ https://issues.apache.org/jira/browse/MIME4J-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779045#action_12779045
]
Oleg Kalnichevski commented on MIME4J-140:
------------------------------------------
Works for me
Oleg
> MIME4J-57 is not practical in its limits and incorrect in its RFC interpretation
> --------------------------------------------------------------------------------
>
> Key: MIME4J-140
> URL: https://issues.apache.org/jira/browse/MIME4J-140
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.6
> Reporter: mike bell
> Assignee: Markus Wiederkehr
>
> I have begun playing with Mime4j for potential use in a software project. Very quickly
I found a simple email (Which i can attach) which has about 30 TO addresses. The default was
to throw an exception
> Looking at MIME4J-57 the author has misunderstood the SMTP RFC 2821. Yes you are limited
to 998 octets PER LINE, but you may FOLD as many 998 octet lines as you wish. Technically
it's 100% legal to have a 50 megabyte header value, as long as it is folded. (per 76 or 998
rules).
> I think the limit chosen by default of 1000 is absurdly low - this should be 100000 minimum
or perhaps even unlimited by default. There is something to be said for a sanity check option,
for sure - but not one that is triggered so easily.
> I can also open somewhat related JIRAS if people find them of merit:
> 1. Documentation - defaults should be clearly stated in MimeEntityConfig javadoc. They
are not
> 2. Bug - The javadocs for MimeEntityConfig claim mc.setMaxHeaderCount(-1); would defeat;
this check. It does not (I worked around with Integer.MaxValue)
> 3. Design Question: Should the MimeTokenStream not have a public constructor that allows
MimeEntityConfig to be fed. As it was I had to create my own subclass to access the protected
constructor - is there a reason for this?
> Thanks
> Example header that blew stuff up (and I think we've all seen far far worse!) - The To
line triggers this
> Return-Path: <tomxypdq@hotmail.com>
> Received: from c.mx.sonic.net (c.mx.sonic.net [64.142.100.46])
> by eth0.a.lds.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id mBT21U5h027864;
> Sun, 28 Dec 2008 18:01:30 -0800
> Received: from bay0-omc2-s13.bay0.hotmail.com (bay0-omc2-s13.bay0.hotmail.com [65.54.246.149])
> by c.mx.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id mBT21QuA026548;
> Sun, 28 Dec 2008 18:01:30 -0800
> Received: from BAY117-W11 ([207.46.8.46]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft
SMTPSVC(6.0.3790.3959);
> Sun, 28 Dec 2008 18:01:26 -0800
> Message-ID: <BAY117-W1177D87B46BEFE5606716BDDE60@phx.gbl>
> Content-Type: multipart/mixed;
> boundary="_03df338b-5029-48d8-84e8-34f5e171dcbd_"
> X-Originating-IP: [96.228.108.66]
> From: Tommy Clark <tomxypdq@hotmail.com>
> To: <alayne.newton@thomson.com>,
> Alexandra Droman
> <alexandra_dorman_100@yahoo.com>,
> Alexis Steinkamp <lexilooo@hotmail.com>, <asteinkamp@ameritech.net>,
> <attame@msn.com>, Ben Greenberg
> <bprofane68@hotmail.com>,
> blythe gross <muppetgirl1969@yahoo.com>, <brenden@mediamystic.com>,
> <cliverping@hotmail.com>, Dae-Jin Kim
> <polykor@chollian.net>,
> Doug Arthur <dougside@yahoo.com>,
> Dox Doxiadis
> <evdoxios.doxiadis@gmail.com>, <doxiadis@princeton.edu>,
> Haidde Sprague
> <haidee.sprague@gmail.com>,
> James Lee <jcl0072@hotmail.com>, Jeff Dorman
> <bub365@aol.com>,
> <jeffejeff@gmail.com>, "Jeff Lim (E-mail)"
> <jeffreyelim@hotmail.com>,
> Jeff Moshman <jmosesian@sonic.net>, Karen Wolfe
> <kaka_2702@yahoo.com>,
> <keirabby@charter.net>, keirabby
> <keirabby@cableone.net>,
> <keirmo@yahoo.com>, Kerry Levenberg
> <kerry@levenbergs.com>,
> Kim-Chi Steger <kcsteger@aol.com>, <lornap78@hotmail.com>,
> <mbell90@sonic.net>, mike bell <mjb@gwava.com>, <myra13@aol.com>,
> Natalie Stange <nstange@nyc.rr.com>,
> karen wolfe
> <ngocbao99@yahoo.com>, <polykor@chol.com>,
> Rob Cliver
> <cliver@fulbrightweb.org>, Sharon Lee <weronron@yahoo.com>,
> the Clarks
> <bosudary@comcast.net>, Ward Breeze <wbreeze@gunder.com>,
> <whosbarley@yahoo.com>
> Subject: N More THANKS
> Date: Sun, 28 Dec 2008 18:01:25 -0800
> Importance: Normal
> In-Reply-To: <BAY117-W268E2179DDEE877110AF11DDE60@phx.gbl>
> References: <c46c51bb0812281737i256ae8depebb851f79b54c326@mail.gmail.com>
> <BAY117-W268E2179DDEE877110AF11DDE60@phx.gbl>
> MIME-Version: 1.0
> X-OriginalArrivalTime: 29 Dec 2008 02:01:26.0088 (UTC) FILETIME=[5B42CC80:01C96959]
> X-Sonic-SB-IP-RBLs: IP RBLs sorbs-spam.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
+1 Bye, Norman 2009/11/16 Markus Wiederkehr <markus.wiederkehr@gmail.com>: > Mime4j development seems to progress very slow at the moment. To me it > does not look like that's going to change anytime soon. > > But since 0.6 we have fixed three important bugs in trunk (MIME4J-138, > 139 and 140). > > If 0.7 cannot be expected soon, should we cut a 0.6.1 instead? > > Markus >
Mime4j development seems to progress very slow at the moment. To me it does not look like that's going to change anytime soon. But since 0.6 we have fixed three important bugs in trunk (MIME4J-138, 139 and 140). If 0.7 cannot be expected soon, should we cut a 0.6.1 instead? Markus
[ https://issues.apache.org/jira/browse/MIME4J-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778338#action_12778338
]
Markus Wiederkehr commented on MIME4J-140:
------------------------------------------
@Mike: Regarding the other issues:
#1 and #2 should be fixed in trunk.
#3: I don't know why that constructor is not public. But do you really want to use MimeTokenStream
directly? MimeStreamParser has a public constructor that passes the specified MimeEntityConfig
to MimeTokenStream. Please file a separate JIRA if you still want that to be addressed.
> MIME4J-57 is not practical in its limits and incorrect in its RFC interpretation
> --------------------------------------------------------------------------------
>
> Key: MIME4J-140
> URL: https://issues.apache.org/jira/browse/MIME4J-140
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.6
> Reporter: mike bell
> Assignee: Markus Wiederkehr
>
> I have begun playing with Mime4j for potential use in a software project. Very quickly
I found a simple email (Which i can attach) which has about 30 TO addresses. The default was
to throw an exception
> Looking at MIME4J-57 the author has misunderstood the SMTP RFC 2821. Yes you are limited
to 998 octets PER LINE, but you may FOLD as many 998 octet lines as you wish. Technically
it's 100% legal to have a 50 megabyte header value, as long as it is folded. (per 76 or 998
rules).
> I think the limit chosen by default of 1000 is absurdly low - this should be 100000 minimum
or perhaps even unlimited by default. There is something to be said for a sanity check option,
for sure - but not one that is triggered so easily.
> I can also open somewhat related JIRAS if people find them of merit:
> 1. Documentation - defaults should be clearly stated in MimeEntityConfig javadoc. They
are not
> 2. Bug - The javadocs for MimeEntityConfig claim mc.setMaxHeaderCount(-1); would defeat;
this check. It does not (I worked around with Integer.MaxValue)
> 3. Design Question: Should the MimeTokenStream not have a public constructor that allows
MimeEntityConfig to be fed. As it was I had to create my own subclass to access the protected
constructor - is there a reason for this?
> Thanks
> Example header that blew stuff up (and I think we've all seen far far worse!) - The To
line triggers this
> Return-Path: <tomxypdq@hotmail.com>
> Received: from c.mx.sonic.net (c.mx.sonic.net [64.142.100.46])
> by eth0.a.lds.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id mBT21U5h027864;
> Sun, 28 Dec 2008 18:01:30 -0800
> Received: from bay0-omc2-s13.bay0.hotmail.com (bay0-omc2-s13.bay0.hotmail.com [65.54.246.149])
> by c.mx.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id mBT21QuA026548;
> Sun, 28 Dec 2008 18:01:30 -0800
> Received: from BAY117-W11 ([207.46.8.46]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft
SMTPSVC(6.0.3790.3959);
> Sun, 28 Dec 2008 18:01:26 -0800
> Message-ID: <BAY117-W1177D87B46BEFE5606716BDDE60@phx.gbl>
> Content-Type: multipart/mixed;
> boundary="_03df338b-5029-48d8-84e8-34f5e171dcbd_"
> X-Originating-IP: [96.228.108.66]
> From: Tommy Clark <tomxypdq@hotmail.com>
> To: <alayne.newton@thomson.com>,
> Alexandra Droman
> <alexandra_dorman_100@yahoo.com>,
> Alexis Steinkamp <lexilooo@hotmail.com>, <asteinkamp@ameritech.net>,
> <attame@msn.com>, Ben Greenberg
> <bprofane68@hotmail.com>,
> blythe gross <muppetgirl1969@yahoo.com>, <brenden@mediamystic.com>,
> <cliverping@hotmail.com>, Dae-Jin Kim
> <polykor@chollian.net>,
> Doug Arthur <dougside@yahoo.com>,
> Dox Doxiadis
> <evdoxios.doxiadis@gmail.com>, <doxiadis@princeton.edu>,
> Haidde Sprague
> <haidee.sprague@gmail.com>,
> James Lee <jcl0072@hotmail.com>, Jeff Dorman
> <bub365@aol.com>,
> <jeffejeff@gmail.com>, "Jeff Lim (E-mail)"
> <jeffreyelim@hotmail.com>,
> Jeff Moshman <jmosesian@sonic.net>, Karen Wolfe
> <kaka_2702@yahoo.com>,
> <keirabby@charter.net>, keirabby
> <keirabby@cableone.net>,
> <keirmo@yahoo.com>, Kerry Levenberg
> <kerry@levenbergs.com>,
> Kim-Chi Steger <kcsteger@aol.com>, <lornap78@hotmail.com>,
> <mbell90@sonic.net>, mike bell <mjb@gwava.com>, <myra13@aol.com>,
> Natalie Stange <nstange@nyc.rr.com>,
> karen wolfe
> <ngocbao99@yahoo.com>, <polykor@chol.com>,
> Rob Cliver
> <cliver@fulbrightweb.org>, Sharon Lee <weronron@yahoo.com>,
> the Clarks
> <bosudary@comcast.net>, Ward Breeze <wbreeze@gunder.com>,
> <whosbarley@yahoo.com>
> Subject: N More THANKS
> Date: Sun, 28 Dec 2008 18:01:25 -0800
> Importance: Normal
> In-Reply-To: <BAY117-W268E2179DDEE877110AF11DDE60@phx.gbl>
> References: <c46c51bb0812281737i256ae8depebb851f79b54c326@mail.gmail.com>
> <BAY117-W268E2179DDEE877110AF11DDE60@phx.gbl>
> MIME-Version: 1.0
> X-OriginalArrivalTime: 29 Dec 2008 02:01:26.0088 (UTC) FILETIME=[5B42CC80:01C96959]
> X-Sonic-SB-IP-RBLs: IP RBLs sorbs-spam.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Author: mwiederkehr
Date: Mon Nov 16 13:22:46 2009
New Revision: 880739
URL: http://svn.apache.org/viewvc?rev=880739&view=rev
Log:
Do not check header count if maxHeaderCount is not positive (in accordance to the javadoc
of MimeEntityConfig).
Modified:
james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
Modified: james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
URL: http://svn.apache.org/viewvc/james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java?rev=880739&r1=880738&r2=880739&view=diff
==============================================================================
--- james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
(original)
+++ james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
Mon Nov 16 13:22:46 2009
@@ -178,12 +178,12 @@
}
protected boolean parseField() throws MimeException, IOException {
- int maxHeaderLimit = config.getMaxHeaderCount();
+ int maxHeaderCount = config.getMaxHeaderCount();
for (;;) {
if (endOfHeader) {
return false;
}
- if (headerCount >= maxHeaderLimit) {
+ if (maxHeaderCount > 0 && headerCount >= maxHeaderCount) {
throw new MaxHeaderLimitException("Maximum header limit exceeded");
}
Author: mwiederkehr
Date: Mon Nov 16 12:36:41 2009
New Revision: 880728
URL: http://svn.apache.org/viewvc?rev=880728&view=rev
Log:
Added MaxHeaderLengthLimitException (MIME4J-140).
Added:
james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/io/MaxHeaderLengthLimitException.java
Modified:
james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java
Added: james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/io/MaxHeaderLengthLimitException.java
URL: http://svn.apache.org/viewvc/james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/io/MaxHeaderLengthLimitException.java?rev=880728&view=auto
==============================================================================
--- james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/io/MaxHeaderLengthLimitException.java
(added)
+++ james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/io/MaxHeaderLengthLimitException.java
Mon Nov 16 12:36:41 2009
@@ -0,0 +1,35 @@
+/****************************************************************
+ * Licensed to the Apache Software Foundation (ASF) under one *
+ * or more contributor license agreements. See the NOTICE file *
+ * distributed with this work for additional information *
+ * regarding copyright ownership. The ASF licenses this file *
+ * to you under the Apache License, Version 2.0 (the *
+ * "License"); you may not use this file except in compliance *
+ * with the License. You may obtain a copy of the License at *
+ * *
+ * http://www.apache.org/licenses/LICENSE-2.0 *
+ * *
+ * Unless required by applicable law or agreed to in writing, *
+ * software distributed under the License is distributed on an *
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY *
+ * KIND, either express or implied. See the License for the *
+ * specific language governing permissions and limitations *
+ * under the License. *
+ ****************************************************************/
+
+package org.apache.james.mime4j.io;
+
+import org.apache.james.mime4j.MimeException;
+
+/**
+ * Signals a I/O error due to the total header length exceeding the maximum limit.
+ */
+public class MaxHeaderLengthLimitException extends MimeException {
+
+ private static final long serialVersionUID = 8924290744274769913L;
+
+ public MaxHeaderLengthLimitException(final String message) {
+ super(message);
+ }
+
+}
Modified: james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
URL: http://svn.apache.org/viewvc/james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java?rev=880728&r1=880727&r2=880728&view=diff
==============================================================================
--- james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
(original)
+++ james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
Mon Nov 16 12:36:41 2009
@@ -30,6 +30,7 @@
import org.apache.james.mime4j.descriptor.MaximalBodyDescriptor;
import org.apache.james.mime4j.descriptor.MutableBodyDescriptor;
import org.apache.james.mime4j.io.LineReaderInputStream;
+import org.apache.james.mime4j.io.MaxHeaderLengthLimitException;
import org.apache.james.mime4j.io.MaxHeaderLimitException;
import org.apache.james.mime4j.io.MaxLineLimitException;
import org.apache.james.mime4j.util.ByteArrayBuffer;
@@ -136,7 +137,7 @@
// copy it to the field buffer
int len = linebuf.length();
if (maxHeaderLen > 0 && fieldbuf.length() + len >= maxHeaderLen)
{
- throw new MaxLineLimitException("Maximum header length limit exceeded");
+ throw new MaxHeaderLengthLimitException("Maximum header length limit
exceeded");
}
if (len > 0) {
fieldbuf.append(linebuf.buffer(), 0, len);
Modified: james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java
URL: http://svn.apache.org/viewvc/james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java?rev=880728&r1=880727&r2=880728&view=diff
==============================================================================
--- james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java
(original)
+++ james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java
Mon Nov 16 12:36:41 2009
@@ -25,6 +25,7 @@
import org.apache.commons.io.IOUtils;
import org.apache.james.mime4j.MimeException;
import org.apache.james.mime4j.io.BufferedLineReaderInputStream;
+import org.apache.james.mime4j.io.MaxHeaderLengthLimitException;
import org.apache.james.mime4j.io.MaxHeaderLimitException;
import org.apache.james.mime4j.io.MaxLineLimitException;
import org.apache.james.mime4j.io.LineNumberInputStream;
@@ -423,8 +424,7 @@
try {
entity.advance();
fail("MimeException caused by MaxLineLimitException should have been thrown");
- } catch (MimeException expected) {
- assertTrue(expected.getCause() instanceof MaxLineLimitException);
+ } catch (MaxHeaderLengthLimitException expected) {
}
}
[ https://issues.apache.org/jira/browse/MIME4J-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778299#action_12778299
]
Markus Wiederkehr commented on MIME4J-140:
------------------------------------------
Patch committed, please review.
> MIME4J-57 is not practical in its limits and incorrect in its RFC interpretation
> --------------------------------------------------------------------------------
>
> Key: MIME4J-140
> URL: https://issues.apache.org/jira/browse/MIME4J-140
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.6
> Reporter: mike bell
> Assignee: Markus Wiederkehr
>
> I have begun playing with Mime4j for potential use in a software project. Very quickly
I found a simple email (Which i can attach) which has about 30 TO addresses. The default was
to throw an exception
> Looking at MIME4J-57 the author has misunderstood the SMTP RFC 2821. Yes you are limited
to 998 octets PER LINE, but you may FOLD as many 998 octet lines as you wish. Technically
it's 100% legal to have a 50 megabyte header value, as long as it is folded. (per 76 or 998
rules).
> I think the limit chosen by default of 1000 is absurdly low - this should be 100000 minimum
or perhaps even unlimited by default. There is something to be said for a sanity check option,
for sure - but not one that is triggered so easily.
> I can also open somewhat related JIRAS if people find them of merit:
> 1. Documentation - defaults should be clearly stated in MimeEntityConfig javadoc. They
are not
> 2. Bug - The javadocs for MimeEntityConfig claim mc.setMaxHeaderCount(-1); would defeat;
this check. It does not (I worked around with Integer.MaxValue)
> 3. Design Question: Should the MimeTokenStream not have a public constructor that allows
MimeEntityConfig to be fed. As it was I had to create my own subclass to access the protected
constructor - is there a reason for this?
> Thanks
> Example header that blew stuff up (and I think we've all seen far far worse!) - The To
line triggers this
> Return-Path: <tomxypdq@hotmail.com>
> Received: from c.mx.sonic.net (c.mx.sonic.net [64.142.100.46])
> by eth0.a.lds.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id mBT21U5h027864;
> Sun, 28 Dec 2008 18:01:30 -0800
> Received: from bay0-omc2-s13.bay0.hotmail.com (bay0-omc2-s13.bay0.hotmail.com [65.54.246.149])
> by c.mx.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id mBT21QuA026548;
> Sun, 28 Dec 2008 18:01:30 -0800
> Received: from BAY117-W11 ([207.46.8.46]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft
SMTPSVC(6.0.3790.3959);
> Sun, 28 Dec 2008 18:01:26 -0800
> Message-ID: <BAY117-W1177D87B46BEFE5606716BDDE60@phx.gbl>
> Content-Type: multipart/mixed;
> boundary="_03df338b-5029-48d8-84e8-34f5e171dcbd_"
> X-Originating-IP: [96.228.108.66]
> From: Tommy Clark <tomxypdq@hotmail.com>
> To: <alayne.newton@thomson.com>,
> Alexandra Droman
> <alexandra_dorman_100@yahoo.com>,
> Alexis Steinkamp <lexilooo@hotmail.com>, <asteinkamp@ameritech.net>,
> <attame@msn.com>, Ben Greenberg
> <bprofane68@hotmail.com>,
> blythe gross <muppetgirl1969@yahoo.com>, <brenden@mediamystic.com>,
> <cliverping@hotmail.com>, Dae-Jin Kim
> <polykor@chollian.net>,
> Doug Arthur <dougside@yahoo.com>,
> Dox Doxiadis
> <evdoxios.doxiadis@gmail.com>, <doxiadis@princeton.edu>,
> Haidde Sprague
> <haidee.sprague@gmail.com>,
> James Lee <jcl0072@hotmail.com>, Jeff Dorman
> <bub365@aol.com>,
> <jeffejeff@gmail.com>, "Jeff Lim (E-mail)"
> <jeffreyelim@hotmail.com>,
> Jeff Moshman <jmosesian@sonic.net>, Karen Wolfe
> <kaka_2702@yahoo.com>,
> <keirabby@charter.net>, keirabby
> <keirabby@cableone.net>,
> <keirmo@yahoo.com>, Kerry Levenberg
> <kerry@levenbergs.com>,
> Kim-Chi Steger <kcsteger@aol.com>, <lornap78@hotmail.com>,
> <mbell90@sonic.net>, mike bell <mjb@gwava.com>, <myra13@aol.com>,
> Natalie Stange <nstange@nyc.rr.com>,
> karen wolfe
> <ngocbao99@yahoo.com>, <polykor@chol.com>,
> Rob Cliver
> <cliver@fulbrightweb.org>, Sharon Lee <weronron@yahoo.com>,
> the Clarks
> <bosudary@comcast.net>, Ward Breeze <wbreeze@gunder.com>,
> <whosbarley@yahoo.com>
> Subject: N More THANKS
> Date: Sun, 28 Dec 2008 18:01:25 -0800
> Importance: Normal
> In-Reply-To: <BAY117-W268E2179DDEE877110AF11DDE60@phx.gbl>
> References: <c46c51bb0812281737i256ae8depebb851f79b54c326@mail.gmail.com>
> <BAY117-W268E2179DDEE877110AF11DDE60@phx.gbl>
> MIME-Version: 1.0
> X-OriginalArrivalTime: 29 Dec 2008 02:01:26.0088 (UTC) FILETIME=[5B42CC80:01C96959]
> X-Sonic-SB-IP-RBLs: IP RBLs sorbs-spam.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Author: mwiederkehr
Date: Mon Nov 16 11:25:48 2009
New Revision: 880712
URL: http://svn.apache.org/viewvc?rev=880712&view=rev
Log:
Added configuration parameter maxHeaderLen (MIME4J-140).
Modified:
james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/MimeEntityConfig.java
james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java
Modified: james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
URL: http://svn.apache.org/viewvc/james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java?rev=880712&r1=880711&r2=880712&view=diff
==============================================================================
--- james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
(original)
+++ james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/AbstractEntity.java
Mon Nov 16 11:25:48 2009
@@ -126,7 +126,7 @@
if (endOfHeader)
throw new IllegalStateException();
- int maxLineLen = config.getMaxLineLen();
+ int maxHeaderLen = config.getMaxHeaderLen();
LineReaderInputStream instream = getDataStream();
ByteArrayBuffer fieldbuf = new ByteArrayBuffer(64);
@@ -135,8 +135,8 @@
// If there's still data stuck in the line buffer
// copy it to the field buffer
int len = linebuf.length();
- if (maxLineLen > 0 && fieldbuf.length() + len >= maxLineLen)
{
- throw new MaxLineLimitException("Maximum line length limit exceeded");
+ if (maxHeaderLen > 0 && fieldbuf.length() + len >= maxHeaderLen)
{
+ throw new MaxLineLimitException("Maximum header length limit exceeded");
}
if (len > 0) {
fieldbuf.append(linebuf.buffer(), 0, len);
Modified: james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/MimeEntityConfig.java
URL: http://svn.apache.org/viewvc/james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/MimeEntityConfig.java?rev=880712&r1=880711&r2=880712&view=diff
==============================================================================
--- james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/MimeEntityConfig.java
(original)
+++ james/mime4j/trunk/core/src/main/java/org/apache/james/mime4j/parser/MimeEntityConfig.java
Mon Nov 16 11:25:48 2009
@@ -32,6 +32,7 @@
private boolean strictParsing;
private int maxLineLen;
private int maxHeaderCount;
+ private int maxHeaderLen;
private long maxContentLen;
private boolean countLineNumbers;
private String defaultContentType;
@@ -41,6 +42,7 @@
this.strictParsing = false;
this.maxLineLen = 1000;
this.maxHeaderCount = 1000;
+ this.maxHeaderLen = 10000;
this.maxContentLen = -1;
this.countLineNumbers = false;
this.defaultContentType = null;
@@ -149,6 +151,34 @@
this.maxHeaderCount = maxHeaderCount;
}
+ /**
+ * Returns the maximum header length limit
+ * @see #setMaxHeaderLen(int)
+ *
+ * @return value of the maximum header length limit
+ */
+ public int getMaxHeaderLen() {
+ return maxHeaderLen;
+ }
+
+ /**
+ * Sets the maximum header length limit. Parsing of a MIME entity will be terminated
+ * with a {@link MimeException} if the total length of a header exceeds this limit.
+ * If this parameter is set to a non positive value the header length check will be
+ * disabled.
+ * <p>
+ * A message header may be folded across multiple lines. This configuration parameter
+ * is used to limit the total length of a header, i.e. the sum of the length of all
+ * lines the header spans across (including line terminators).
+ * <p>
+ * Default value: <code>10000</code>
+ *
+ * @param maxHeaderLen maximum header length limit
+ */
+ public void setMaxHeaderLen(int maxHeaderLen) {
+ this.maxHeaderLen = maxHeaderLen;
+ }
+
/**
* Returns the maximum content length limit
* @see #setMaxContentLen(long)
Modified: james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java
URL: http://svn.apache.org/viewvc/james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java?rev=880712&r1=880711&r2=880712&view=diff
==============================================================================
--- james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java
(original)
+++ james/mime4j/trunk/core/src/test/java/org/apache/james/mime4j/parser/MimeEntityTest.java
Mon Nov 16 11:25:48 2009
@@ -330,6 +330,9 @@
}
public void testMaxLineLimitCheck() throws Exception {
+ MimeEntityConfig config = new MimeEntityConfig();
+ config.setMaxLineLen(50);
+
String message =
"To: Road Runner <runner@example.org>\r\n" +
"From: Wile E. Cayote <wile@example.org>\r\n" +
@@ -342,10 +345,8 @@
byte[] raw = message.getBytes("US-ASCII");
ByteArrayInputStream instream = new ByteArrayInputStream(raw);
LineNumberInputStream lineInput = new LineNumberInputStream(instream);
- BufferedLineReaderInputStream rawstream = new BufferedLineReaderInputStream(lineInput,
12);
+ BufferedLineReaderInputStream rawstream = new BufferedLineReaderInputStream(lineInput,
12, config.getMaxLineLen());
- MimeEntityConfig config = new MimeEntityConfig();
- config.setMaxLineLen(50);
MimeEntity entity = new MimeEntity(
lineInput,
rawstream,
@@ -355,25 +356,23 @@
config);
assertEquals(EntityStates.T_START_MESSAGE, entity.getState());
- entity.advance();
+ entity.advance(); // advances to T_START_HEADER
assertEquals(EntityStates.T_START_HEADER, entity.getState());
- entity.advance();
- assertEquals(EntityStates.T_FIELD, entity.getState());
- entity.advance();
+ entity.advance(); // reads To: into field buffer, From: into line buffer
assertEquals(EntityStates.T_FIELD, entity.getState());
- entity.advance();
+ entity.advance(); // reads Date: into line buffer
assertEquals(EntityStates.T_FIELD, entity.getState());
- entity.advance();
+ entity.advance(); // reads Subject: into line buffer
assertEquals(EntityStates.T_FIELD, entity.getState());
try {
- entity.advance();
+ entity.advance(); // reads DoS: into line buffer
fail("MimeException caused by MaxLineLimitException should have been thrown");
} catch (MimeException expected) {
assertTrue(expected.getCause() instanceof MaxLineLimitException);
}
}
- public void testMaxLineLimitCheckFoldedLines() throws Exception {
+ public void testMaxHeaderLimitCheckFoldedLines() throws Exception {
String message =
"To: Road Runner <runner@example.org>\r\n" +
"From: Wile E. Cayote <wile@example.org>\r\n" +
@@ -400,7 +399,8 @@
BufferedLineReaderInputStream rawstream = new BufferedLineReaderInputStream(lineInput,
12);
MimeEntityConfig config = new MimeEntityConfig();
- config.setMaxLineLen(50);
+ config.setMaxLineLen(100);
+ config.setMaxHeaderLen(200);
MimeEntity entity = new MimeEntity(
lineInput,
rawstream,
@@ -428,6 +428,47 @@
}
}
+ public void testMaxHeaderLengthMayExceedMaxLineLength() throws Exception {
+ MimeEntityConfig config = new MimeEntityConfig();
+ config.setMaxLineLen(50);
+ config.setMaxHeaderLen(130);
+
+ String message =
+ "To: Road Runner <runner@example.org>\r\n" +
+ "From: Wile E. Cayote <wile@example.org>\r\n" +
+ "Date: Tue, 12 Feb 2008 17:34:09 +0000 (GMT)\r\n" +
+ "Subject: Mail\r\n" +
+ "X-LongHeader: xxxxxxxxxxxxxxxxxxxxxxx\r\n" +
+ " xxxxxxxxxxxxxxxxxxxxxxx\r\n" +
+ " xxxxxxxxxxxxxxxxxxxxxxx\r\n" +
+ " xxxxxxxxxxxxxxxxxxxxxxx\r\n" +
+ "Content-Type: text/plain\r\n" +
+ "\r\n" +
+ "a very important message";
+ byte[] raw = message.getBytes("US-ASCII");
+ ByteArrayInputStream instream = new ByteArrayInputStream(raw);
+ LineNumberInputStream lineInput = new LineNumberInputStream(instream);
+ BufferedLineReaderInputStream rawstream = new BufferedLineReaderInputStream(lineInput,
12, config.getMaxLineLen());
+
+ MimeEntity entity = new MimeEntity(
+ lineInput,
+ rawstream,
+ null,
+ EntityStates.T_START_MESSAGE,
+ EntityStates.T_END_MESSAGE,
+ config);
+
+ assertEquals(EntityStates.T_START_MESSAGE, entity.getState());
+ entity.advance();
+ assertEquals(EntityStates.T_START_HEADER, entity.getState());
+ for (int i = 0; i < 6; i++) {
+ entity.advance();
+ assertEquals(EntityStates.T_FIELD, entity.getState());
+ }
+ entity.advance();
+ assertEquals(EntityStates.T_END_HEADER, entity.getState());
+ }
+
public void testMaxHeaderCount() throws Exception {
String message =
"To: Road Runner <runner@example.org>\r\n" +