[
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
