mailing list archives

Hi,
can I somehow access the Content-Transfer-Encoding of a root-level 
multipart except via parsing the HEADER part myself?

The use case is the following -- my MUA supports attaching arbitrary IMAP 
messages when composing mail. Under the hood, this works by simply taking 
the whole payload of the message and placing it as an extra part into a 
top-level multipart/mixed. No MIME encoding is performed for the attached 
message; its HEADER and TEXT parts are simply concatenated and used as-is.

Now I'm trying to conform to various mail standards and am considering what 
to do with the Content-Transfer-Encoding of the attachment. Ironically, 
this works well when the attached item is actually a message/rfc822 which 
is already attached to some other message; if that is the case, the 
BODYSTRUCTURE response typically contains a body-fld-enc field which I can 
use verbatim.

However, it appears that the body-fld-enc is not reachable from the 
body-type-mpart (which expands into body-ext-mpart, which contains only a 
subset of interesting fields). The only way of getting these data is, 
apparently, via the HEADER.FIELDS(Content-Transfer-Encoding). This is 
rather inconvenient.

A couple of questions:

- Is this analysis correct?
- If so, what was the reason for leaving out the CTE header from 
BODYSTRUCTURE of multipart/* parts?
- Is my approach of blindly accepting the message/rfc822 payload directly 
in the composer fatally flawed anyway? What else shall one use when 
"forwarding message as an attachment"? Shall the MUA reparse and sanitize 
the whole MIME structure in some way? If so, wouldn't that go against the 
perceived goal of "forward as attachment" which is often used for e.g. 
passing around "interesting" messages?
- What can I expect for mistakenly claiming that my message/rfc822 MIME 
part nested within a multipart/mixed has CTE: 7bit while its own header 
clearly says that it uses an 8bit CTE?

The BODYSTRUCTURE of this thing, as returned by Dovecot:

* 10507 FETCH (UID 60464 BODYSTRUCTURE (("text" "plain" ("charset" "utf8") 
NIL NIL "8bit" 642 17 NIL NIL NIL NIL)("message" "rfc822" NIL NIL NIL 
"8bit" 8600 ("Wed, 16 Oct 2013 22:49:48 +0400" "[trojita] 
=?Windows-1251?B?xOXq6+Bw6PDu4uDt6OUg8u7iYfDu4iDoIPLg7G/mZe3t++Ug8GXm6Oz7?=" 
(("=?Windows-1251?B?0uDs7ubt/w==?=" NIL "kurilluck.urebrof" "mail.ru")) 
(("=?Windows-1251?B?0uDs7ubt/w==?=" NIL "kurilluck.urebrof" "mail.ru")) 
((NIL NIL "trojita" "lists.flaska.net")) ((NIL NIL "trojita" 
"lists.flaska.net")) NIL NIL NIL 
"<464148380.20131016829328@mx.tillions.com>") ("text" "html" ("charset" 
"windows-1251") NIL NIL "8bit" 7524 124 NIL NIL NIL NIL) 146 NIL ("inline" 
("filename" "message.eml")) NIL NIL) "mixed" ("boundary" 
"=_7b26f5171179a9455fc646812635670f_=") NIL NIL NIL))

The full message is available at http://jkt.flaska.net/tmp/msg_60464.eml .

With kind regards,
Jan

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

On 16 Oct 2013 16:24, "Jan Kundr?t" <jkt@flaska.net> wrote:
>
> Hi,
> can I somehow access the Content-Transfer-Encoding of a root-level
multipart except via parsing the HEADER part myself?

Perhaps I'm misunderstanding, but isn't the CTE of any multipart/* 7bit by
definition?

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20131016/3891de2b/attachment.html>

On Wednesday, 16 October 2013 22:44:55 CEST, Dave Cridland wrote:
> Perhaps I'm misunderstanding, but isn't the CTE of any multipart/* 7bit 
by
> definition?

No, as per page 17 of RFC2045:

   Certain Content-Transfer-Encoding values may only be used on certain
   media types.  In particular, it is EXPRESSLY FORBIDDEN to use any
   encodings other than "7bit", "8bit", or "binary" with any composite
   media type, i.e. one that recursively includes other Content-Type
   fields.  Currently the only composite media types are "multipart" and
   "message".  All encodings that are desired for bodies of type
   multipart or message must be done at the innermost level, by encoding
   the actual body that needs to be encoded.

And indeed, I'm seeing multipart/mixed with CTE: 8bit; they are produced by 
mlmmj mailing list moderation.

The next paragraph is related to my fourth question: 

   It should also be noted that, by definition, if a composite entity
   has a transfer-encoding value such as "7bit", but one of the enclosed
   entities has a less restrictive value such as "8bit", then either the
   outer "7bit" labelling is in error, because 8bit data are included,
   or the inner "8bit" labelling placed an unnecessarily high demand on
   the transport system because the actual included data were actually
   7bit-safe.

It doesn't answer what one might expect when dealing with such errors -- I 
know that's a difficulr question, though.

Cheers,
Jan

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

No, multipart does not have a cte at all. The leaf parts may have different cte values.

As I recall, there is a ban on sending cte for a multipart somewhere in the mime documents.

Arnt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20131016/ba4a2e09/attachment.html>

Yes, you're allowed non-transformative types... and for more fun, RFC
6532 for message/global so you can have UTF8 headers.

Brandon

On Wed, Oct 16, 2013 at 2:30 PM, Arnt Gulbrandsen
<arnt@gulbrandsen.priv.no> wrote:
> No, multipart does not have a cte at all. The leaf parts may have different
> cte values.
>
> As I recall, there is a ban on sending cte for a multipart somewhere in the
> mime documents.
>
>
> Arnt
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol

On Wed, Oct 16, 2013 at 03:42:49PM -0700, Brandon Long wrote:
> Yes, you're allowed non-transformative types... and for more fun, RFC
> 6532 for message/global so you can have UTF8 headers.

Right. I had forgotten that detail.

Put differently: You're allowed to specify any CTE which is equivalent
to not specifying CTE. I expect that's why Mark didn't want to include
the CTE when reporting header contents.

Arnt