james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clément Denis (JIRA) <mime4j-...@james.apache.org>
Subject [jira] [Updated] (MIME4J-160) Document/describe how QuotedPrintable/Base64 decoding deal with unexpected input sequences and if we need multiple behaviour supports or not.
Date Mon, 22 Apr 2013 17:13:15 GMT

     [ https://issues.apache.org/jira/browse/MIME4J-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Clément Denis updated MIME4J-160:
---------------------------------

    Attachment:     (was: quotedprintablewithoutencoding.mime)
    
> Document/describe how QuotedPrintable/Base64 decoding deal with unexpected input sequences
and if we need multiple behaviour supports or not.
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MIME4J-160
>                 URL: https://issues.apache.org/jira/browse/MIME4J-160
>             Project: James Mime4j
>          Issue Type: Task
>    Affects Versions: 0.6
>            Reporter: Stefano Bagnara
>            Priority: Minor
>             Fix For: 0.8.0
>
>
> Base64 should "die" on unexpected content, but MIME says that any char outside the "charset"
should be ignored, because at least CR and LF are expected to appear in mime base64 streams.
Should a strict base64 decoder die on some other char or not?
> QuotedPrintable currently handle these 2 malformations:
> == translated to =
> =XX on invalid XX is left as is (=XX)
> Some other decoder have different strategies:
> some of them match =[hex]?[hex]? some of them match =[any][any] (see how this alter the
interpretation of a =X=A=BB sequence)
> after matching the treat invalid sequences differently, too. Some of them output the
invalid sequence as is, some of them output it without the "=", some other remove the whole
sequence from the stream.
> The same applies with dealing with space at the end of a line: some implementation leave
it as is, some other implementation removes it.
> I tried searching the RFC to understand if there is a preferred strategy to deal with
malformed sequences but I had no success, maybe I've missed something. Any opinion?
> As I know that we rewrote the QuotedPrintableInputStream multiple times, I'd like to
head opinions about dealing with malformations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message