[Rt-devel] Bug: Forward + GnuPG sign = illegal MIME encoding base64

Otmar Lendl ol at bofh.priv.at
Tue Oct 20 17:17:51 EDT 2009


Ruslan Zakirov wrote:
> Hello Otmar,
> I believe you that something is wrong, not sure what exactly.
> If we are talking about RFCs 3156 and 1847 then it's important to look
> at section 2.1 in http://www.faqs.org/rfcs/rfc1847.html, paragraph
> that says the following:
> <<<
> In addition, if the multipart/signed object is EVER to be transferred
> over the standard Internet SMTP infrastructure, the resulting MIME
> body is constrained to 7 bits -- that is, the use of material
> requiring either 8bit or binary content-transfer-encoding is NOT
> allowed. Such 8bit or binary material MUST be encoded using either the
> quoted-printable or base64 encodings.

Well, then there is RFC 1341, 7.3:

As stated in the definition of the Content-Transfer-Encoding field, no
encoding other than "7bit", "8bit", or "binary" is permitted for messages
or parts of type "message". The message header fields are always US-ASCII
in any case, and data within the body can still be encoded, in which case
the Content-Transfer-Encoding header field in the encapsulated message will
reflect this.

Thus things like

Content-Type: message/rfc822
Content-Disposition: attachment
Content-Transfer-Encoding: base64
Content-Description: forwarded message


are not conformant. (and indeed, some software, including Thunderbird barfs
on it)

What we probably need to create is something like this:


This is forward of transaction #305146 of a ticket #18179
Content-Type: message/rfc822
Content-Disposition: attachment
Content-Transfer-Encoding: binary
Content-Description: forwarded message

X-RT-Original-Encoding: utf-8    <<<<<<<< This is a harmless 7bit header >>
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
RT-Message-ID: <rt-3.8.2-21776-1256019937-1974.18179-0-0 at CERT.at>
Content-Type: multipart/mixed; boundary="----------=_1256046129-23854-1"

This is a multi-part message in MIME format...

Content-Length: 883
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: base64


That is, leave the headers of the message/rfc822 in clear, but make sure
that all the bodies attached to that headers are in 7bit transfer encodings.

The headers of the message/rfc822 part are by definition 7bit anyway, so
there is really no need to encode them down to 7bit.

Yes, that's all a bit of a mess.

-=-  Otmar Lendl  --  ol at bofh.priv.at  --  http://lendl.priv.at/  -=-

More information about the Rt-devel mailing list