[RFC] MIME-Version / RFC 2045 compliance issues

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 07 Jan 2014 17:23:15 +1300

I have been looking at the MIME header formatting and have come to the
conclusion that Squid is not supposed to be sending the Mime-Version
header any longer. It is roughly compliant with the syntax, but does not
(and cannot for many delivered messages) meet with the formal
requirements for emitting that header.

  RFC 2045 section 4 states:
"
   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.
"

Problem 1) RFC 2616 Transfer-Encoding feature

 a) embeds characters in the body/entity/payload such that a recipient
of the message MUST also support that feature in order not to present a
corrupted display. This is particularly noticable with binary objects.

That clashes directly with the RFC 2045 Content-Type definition which
requires that the Content-Type header be sufficient for the recipient to
display the content.

 b) naming of the HTTP/1.1 header conflicts with RFC 2045
Content-Transfer-Encoding header in both name and purpose. As I
understand it that is intentional, but another reason any use of this
feature violates RFC 2045 requirements.

Problem 2) HTTPbis have deprecated line folding syntax and Squid
routinely transports lines of up to 64KB in length today.

 RFC 5322 section 2.1.1 states:
   "Each line of characters MUST be no more than 998 characters"

I know its an indirect route to get to that limitation. But RFC 2045
extends the IMF protocol (was RFC 822 / 2822, now RFC 5322) and in
several places iterates that limit by indicating lines of no more than
1000 characters (albeit without explicit MUST/SHOULD/MAY).

I think we should abandon adding the "MIME-Version: 1.0" label on Squid
generated messages.

I also think we should strip it from relayed messages. Striping always
will save a lot of cycles figuring out for each header if its going to
be too-big for the limits imposed by RFC 2045.

Opinions?

Amos
Received on Tue Jan 07 2014 - 04:23:24 MST

This archive was generated by hypermail 2.2.0 : Tue Jan 07 2014 - 12:00:10 MST