Bug: Forward + GnuPG sign = illegal MIME encoding base64

RT Developers
1

This was a bit tricky to debug:

We kept getting complaints about empty forwards from our RT 3.8.2 / RTIR
installations. Testing Forwards manually (/RTIR/Forward.html) showed the
desired attachment, though. At least in mutt. Not in Thunderbird.

Finally Amavis tipped us off: “illegal MIME encoding [base64] for message/rfc822”.

It turns out that an attachement of type message/rfc822 must
not be encoded by itself. Plain RT is fine, it uses “binary” as
encoding. Nothing wrong about that.

Now, we do have GnuPG signing enabled for this queue, and thus the message gets
passed through the signing engine, and here (quite understandable), the code
wants to play it safe and recodes to base64. And not the individual leafs of the
MIME tree (which would be fine), but the message/rfc822 part itself.

Bad karma.

The kolab people also ran into a similar issue some time ago, see:
https://www.intevation.de/roundup/aegypten/issue661

Anyway, I do not have a good solution for that, for the moment I decided
to simply disable signing for forwards.

Does someone else have a good idea where to tweak the gnuPG code to get
this right?

cheers,

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

2

Thanks for the report and the triage. I’ve created an RT bug for this.

Best,
Jesse

3

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 RFC 1847 - Security Multiparts for MIME: Multipart/Signed and Mu (RFC1847), 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.

This was a bit tricky to debug:

We kept getting complaints about empty forwards from our RT 3.8.2 / RTIR
installations. Testing Forwards manually (/RTIR/Forward.html) showed the
desired attachment, though. At least in mutt. Not in Thunderbird.

Finally Amavis tipped us off: “illegal MIME encoding [base64] for message/rfc822”.

It turns out that an attachement of type message/rfc822 must
not be encoded by itself. Plain RT is fine, it uses “binary” as
encoding. Nothing wrong about that.

Now, we do have GnuPG signing enabled for this queue, and thus the message gets
passed through the signing engine, and here (quite understandable), the code
wants to play it safe and recodes to base64. And not the individual leafs of the
MIME tree (which would be fine), but the message/rfc822 part itself.

Bad karma.

The kolab people also ran into a similar issue some time ago, see:
https://www.intevation.de/roundup/aegypten/issue661

Anyway, I do not have a good solution for that, for the moment I decided
to simply disable signing for forwards.

Does someone else have a good idea where to tweak the gnuPG code to get
this right?

cheers,

/ol

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

List info: The rt-devel Archives

Best regards, Ruslan.

4

Hi,

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 RFC 1847 - Security Multiparts for MIME: Multipart/Signed and Mu (RFC1847), 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

------------=_1256045632-23786-2
Content-Type: message/rfc822
Content-Disposition: attachment
Content-Transfer-Encoding: base64
Content-Description: forwarded message

WC1SVC1PcmlnaW5hbC1FbmNvZGluZzogdXRmLTgKTUlNRS1WZXJzaW9uOiAx
LjAKWC1NYWlsZXI6IE1JTUUtdG9vbHMgNS40MjcgKEVudGl0eSA1LjQyNykK
UlQtU2VuZC1DQzoKUlQtTWVzc2FnZS1JRDogPHJ0LTMuOC4yLTIxNzc2LTEy
NTYwMTk5MzctMTk3NC4xODE3OS0wLTBAQ0VSVC5hdD4KQ29udGVudC1UeXBl

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
------------=_1256046129-23854-2
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-Send-CC:
RT-Message-ID: rt-3.8.2-21776-1256019937-1974.18179-0-0@CERT.at
Content-Type: multipart/mixed; boundary=“----------=_1256046129-23854-1”

This is a multi-part message in MIME format…

------------=_1256046129-23854-1
Content-Length: 883
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: base64

WC1SVC1PcmlnaW5hbC1FbmNvZGluZzogdXRmLTgKTUlNRS1WZXJzaW9uOiAx

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.

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

5

Hello,

Thanks for looking further into RFCs. So I think we should do the following:

  1. in lib/RT/Crypt/GnuPG.pm don’t set content transfer encoding on
    message/ parts.

  2. set content transfer encoding of a forward subparts to base64 or
    quoted-printable unless it’s 7bit. we should do this only if we’re
    going to sign forwarded message.

I’m going to stick this to the ticket Jesse created and link with next release.On Wed, Oct 21, 2009 at 1:17 AM, Otmar Lendl ol@bofh.priv.at wrote:

Hi,

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 RFC 1847 - Security Multiparts for MIME: Multipart/Signed and Mu (RFC1847), 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

------------=_1256045632-23786-2
Content-Type: message/rfc822
Content-Disposition: attachment
Content-Transfer-Encoding: base64
Content-Description: forwarded message

WC1SVC1PcmlnaW5hbC1FbmNvZGluZzogdXRmLTgKTUlNRS1WZXJzaW9uOiAx
LjAKWC1NYWlsZXI6IE1JTUUtdG9vbHMgNS40MjcgKEVudGl0eSA1LjQyNykK
UlQtU2VuZC1DQzoKUlQtTWVzc2FnZS1JRDogPHJ0LTMuOC4yLTIxNzc2LTEy
NTYwMTk5MzctMTk3NC4xODE3OS0wLTBAQ0VSVC5hdD4KQ29udGVudC1UeXBl

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
------------=_1256046129-23854-2
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-Send-CC:
RT-Message-ID: rt-3.8.2-21776-1256019937-1974.18179-0-0@CERT.at
Content-Type: multipart/mixed; boundary=“----------=_1256046129-23854-1”

This is a multi-part message in MIME format…

------------=_1256046129-23854-1
Content-Length: 883
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: base64

WC1SVC1PcmlnaW5hbC1FbmNvZGluZzogdXRmLTgKTUlNRS1WZXJzaW9uOiAx

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.

/ol

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

Best regards, Ruslan.

6

Otmar Lendl wrote:

Well, then there is RFC 1341, 7.3:

I just checked, the same restriction is still present in RFC 2045, 6.4., so
this has not been obsoleted.

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

7

Hi,

Ruslan Zakirov wrote:

Hello,

Thanks for looking further into RFCs. So I think we should do the following:

  1. in lib/RT/Crypt/GnuPG.pm don’t set content transfer encoding on
    message/ parts.

Same applies to multipart/, see also 6.4 of rfc2045

If an entity is
of type “multipart” the Content-Transfer-Encoding is not permitted to
have any value other than “7bit”, “8bit” or “binary”. Even more
severe restrictions apply to some subtypes of the “message” type

  1. set content transfer encoding of a forward subparts to base64 or
    quoted-printable unless it’s 7bit. we should do this only if we’re
    going to sign forwarded message.

Agreed, that’s the proper solution.

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