ruslan.zakirov at gmail
Oct 20, 2009, 2:40 PM
Post #5 of 7
(1348 views)
Permalink
|
|
Re: Bug: Forward + GnuPG sign = illegal MIME encoding base64
[In reply to]
|
|
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 [at] bofh> 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 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
>
> ------------=_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 [at] CERT>
> 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 [at] bofh -- http://lendl.priv.at/ -=-
>
--
Best regards, Ruslan.
_______________________________________________
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
|
