Sam Varshavchik wrote:
> Chris St Denis writes:
>> Sam Varshavchik wrote:
>>> Chris St Denis writes:
>>>> Courier-imap is incorrectly parsing the message structure of some
>>> Courier-IMAP parsed your sample message correctly, according to RFC
>>> This appears to be a bug in your "Barracuda spam firewall" product,
>>> which corrupted the original headers, when it processed it.
>> What header(s) in particular are wrong and what should they be for it
>> to be correct? I will pass the data as a bug report to Barracuda and
>> get this resolved.
> An RFC 2822 message consists of one or more header lines, then an
> empty line, then followed by the body of the message. Then, in order
> for a message to be a valid MIME message, it must include the
> MIME-Version: header. See section 4 of RFC 2045. It's clear, and
> unambiguous. A MIME-Version: header must be present. Your sample
> message does not contain a "MIME-Version:" header, in the header
> portion of the message; as such it is not a MIME message. Without a
> valid MIME-Version: header present, none of the MIME headers,
> including Content-Type: carry any meaning.
> There is a line in your message that reads "MIME-Version:", however it
> is not a part of this message's header portion. The message's headers
> precede the first empty line of the message, see above. In the example
> message "MIME-Version:" occurs after the first empty line.
> If you actually examine the message closely, Barracuda inserted its
> junk *in the middle* of an existing References: header! After all of
> that garbage, you can see what's obviously the last line of the
> original References: header, containing the last message ID, followed
> by a "Mime-Version: 1.0". However, since the junk inserted by
> Barracuda included a bunch of empty lines, everything below that junk
> is considered a part of the message's contents, and not its headers.
> Ready!… Fire!… Aim???
>> 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
>> and Thunderbird (with courier-imap as the server) displays it
>> correctly (therefore it must not use BODYSTRUCTURE).
> Correct. Thunderbird does not use BODYSTRUCTURE. And, it has the same
> sloppy logic as Dovecot.
> 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.
Thank you for the explanation, I did not notice the broken header, I
thought it was a problem with the body portion of the mime construct.
I'll open a tick with Barracuda for them to, well, probably not do
anything about, but it's all I can do. The barracuda hardware actually
uses Postfix for it's core, so it may be a bug in Postfix's header
rewriting. Actually, this part it probably generated by it's
SpamAssassin, so maybe it's to blame. Or, maybe hotmail is just
outputting broken headers with a line break in the References header.
Either way I'll have to do some investigation.