[Dovecot] [Fwd: Re: Bug in BODYSTRUCTURE]

[Timo Sirainen]

I fully agree with Jakob. Actually this is a somewhat recent change  
(v1.1.alpha2). Mime-Version: was previously required, but there were  
enough broken mails that I decided to make this optional in code (but  
not by admin):

         /* Buggy software creates Content-Type: headers without Mime- 
Version:
            header. By default we allow this and assume message is  
MIME if
            Content-Type: is found. This flag disables this. */
         MESSAGE_PARSER_FLAG_MIME_VERSION_STRICT = 0x02

On Nov 10, 2009, at 8:02 AM, Jakob Hirsch wrote:

> Charles Marcus, 2009-11-10 12:52:
>
>> Sam Varshavik (courier-imap developer) claims (on the courier-imap  
>> list,
>> see attached) dovecot is incorrectly parsing messages with
>> missing/invalid "MIME-Version:" header...
>
> Since when is being robust incorrect?
>
>>> However this situation does appear to be specific to courier-imap.
>>> Dovecot is able to parse it
>>
>> If so, it violates RFC 2045, section 4. Its wording is clear:
>>
>>  Messages composed in accordance with this document MUST include such
>>  a header field, with the following verbatim text:
>>
>>    MIME-Version: 1.0
>>
>>  The presence of this header field is an assertion that the message
>>  has been composed in compliance with this document.
>>
>> If so, it fails to check for the presence of the MIME-Version:  
>> header,
>> so it processes the Content-Type: header even if MIME-Version: is  
>> missing.
>
> Well, that is a MUST for the sender part (that creates the message),  
> but
> the RFC (or at least the part that Sam Varshavchik quoted) does not  
> say
> "you are not allowed to handle a MIME message if some part of it is
> broken". You can does, if you like to be a pedantic bureaucrat, but I
> doubt that this improves the user experience.
>
>> This is somewhat sad. Internet standards are supposed to have some
>> meaning. I could see ignoring something that's may be burdensome or
>> onerous, but this is basic, elementary stuff.
>
> It's actually the other way round: It's harder to write software that
> follows the robustness principle, "be liberal in what you accept from
> others". Sam's ranting would apply to violations of the other part,  
> "be
> conservative in what you do".
>