From mime4j-dev-return-1725-apmail-james-mime4j-dev-archive=james.apache.org@james.apache.org Mon Oct 10 13:07:53 2011 Return-Path: X-Original-To: apmail-james-mime4j-dev-archive@minotaur.apache.org Delivered-To: apmail-james-mime4j-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C1F307EA5 for ; Mon, 10 Oct 2011 13:07:53 +0000 (UTC) Received: (qmail 62873 invoked by uid 500); 10 Oct 2011 13:07:53 -0000 Delivered-To: apmail-james-mime4j-dev-archive@james.apache.org Received: (qmail 62841 invoked by uid 500); 10 Oct 2011 13:07:53 -0000 Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: mime4j-dev@james.apache.org Delivered-To: mailing list mime4j-dev@james.apache.org Received: (qmail 62833 invoked by uid 99); 10 Oct 2011 13:07:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2011 13:07:53 +0000 X-ASF-Spam-Status: No, hits=-2000.5 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2011 13:07:51 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id C2872300B00 for ; Mon, 10 Oct 2011 13:07:29 +0000 (UTC) Date: Mon, 10 Oct 2011 13:07:29 +0000 (UTC) From: "Stefano Bagnara (Commented) (JIRA)" To: mime4j-dev@james.apache.org Message-ID: <461116720.14510.1318252049798.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <122153869.11734.1317397126045.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (MIME4J-203) RawField parsing problem in case of '\t' delimiter MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/MIME4J-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124062#comment-13124062 ] Stefano Bagnara commented on MIME4J-203: ---------------------------------------- @Kostya (sorry for the typo): RFC clearly states that everything after the ":" is body. There is no way to read rfc differently. rfc5322 2.2: Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. That said I agree that our RawBody already had some special handling for the space and so if we don't plan to really fix it we can at least make it consistent, but this doesn't change the fact that the RFC says something different about what is an header body. I don't have a better fix for this right now so I'm fine with the committed solution, but I wanted to aknowledge that we are not strictly doing what the RFC tells (of course the RFC doesn't tell us what classes to use and what our methods have to return, so we can simply document our current approach, maybe linking to this issue). In past I analyzed the behaviour of MUA wrt spaces at the start of the "Subject" header body. Every client ignores the first space, some clients trim every space at the start of the subject. So they already do something different from what RFC says and this is why I didn't find a good solution to be strict wrt RFC and still show a similar behaviour to what most clients do. > RawField parsing problem in case of '\t' delimiter > -------------------------------------------------- > > Key: MIME4J-203 > URL: https://issues.apache.org/jira/browse/MIME4J-203 > Project: JAMES Mime4j > Issue Type: Bug > Components: dom > Affects Versions: 0.7 > Environment: linux 3.0.1, x86_64 > java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) > Reporter: Kostya Gribov > Fix For: 0.7.1 > > Attachments: patch > > > RawField doesn't drop '\t' char between field header and body, so body starts from LWSP-char that should be ignored by RFC822 (see 3.4.2 in spec) because date field is structured. So date isn't extracted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira