70 lines
3.2 KiB
Plaintext
70 lines
3.2 KiB
Plaintext
MBOX-Line: From jkt at flaska.net Wed Oct 16 13:20:06 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
|
|
Date: Fri Jun 8 12:34:51 2018
|
|
Subject: [Imap-protocol] Accessing the Content-Transfer-Encoding of a
|
|
top-level multipart
|
|
Message-ID: <18960e4a-19cb-4a82-b287-aee478965e77@flaska.net>
|
|
|
|
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/
|
|
|