[Dovecot] [Fwd: Re: Bug in BODYSTRUCTURE]
Fyi...
Sam Varshavik (courier-imap developer) claims (on the courier-imap list, see attached) dovecot is incorrectly parsing messages with missing/invalid "MIME-Version:" header...
I have no clue if he is correct... if so, maybe this has already been fixed?
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.0The 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".
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".
On 11/10/2009, Timo Sirainen (tss@iki.fi) wrote:
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):
Good enough for me... I just wanted confirmation... thx!
participants (3)
-
Charles Marcus
-
Jakob Hirsch
-
Timo Sirainen