Serge Knystautas ha scritto:
I do not have a use for telling someone their message is
non-compliant.  I have a use for parsing emails.  I'm a simpleton user
though, so can only speak to my own needs.

Serge, I'm not sure this is on topic with what I asked:

Are you saying that you prefer us not to change mime4j to use boundaries only from the beginning of a line?

For the record Mime4j 0.3 (and also 0.4 until a recent commit) did what I am proposing to do now.

I'm not aware of any message created by any agent that would be parsed by current mime4j and not parsed if we reintroduce the boundary parsing only at the beginning of a line.

IMHO parsing a boundary also in the middle of lines simply increase the probability to find fake boundaries in very nested multipart messages using badly chosen delimiters.

IMHO this is going to far: anything non RFC compliant should be done only after we have proof there is an actual "abuse" of the RFC and not everywhere we can ignore the RFC.

IMHO accepting a boundary in the middle of the line is VIOLATING the RFC (the snippet I quoted says "implementors.... MUST compare....with the beginning of each line")

IMHO leaving the code as is simply means justifying a bug with a "let's parse real world content" excuse.

BTW I attached the patch for this issue to the JIRA, I'm not going to push this any further.

Stefano

> Stefano Bagnara wrote:
>> I opened this issue a week ago:
>> http://issues.apache.org/jira/browse/MIME4J-54
>>
>> Given the recent discussions about strict parsing and my view of the
>> RFC compliance vs real world use case, before spending time in trying
>> to fix this I would like to know if there is any harm in fixing this.
>>
>> Please speak now or I'll go on with fixing that issue with no
>> configurable behaviour: so only boundaries at the beginning of a line
>> will be parsed.
>>
>>
>> I would also like to collect opinions about the handling of chars at
>> the end of the boundary.
>> From the RFC it's clear we have to deal with padding at the end of the
>> boundary, but this sentence leave me doubts about what we have to
>> expect there (from http://www.faqs.org/rfcs/rfc2046.html):
>> ==================================
>> NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the
>> boundary value with the beginning of each candidate line. An exact
>> match of the entire candidate line is not required; it is sufficient
>> that the boundary appear in its entirety following the CRLF.
>> =====================================
>> Do you think this is only about *ending* boundary or *any* boundary?
>>
> I've added my response as a comment on the MIME4J-54 issue page.
>
> /Niklas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



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

Reply via email to