[Imap-protocol] Accessing the Content-Transfer-Encoding of a top-level multipart

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 
"<[email protected]>") ("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/
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol