cd/1a692eadf16dcc19febbc759d988b29350ed2f

   1 Return-Path: <dkg@fifthhorseman.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 814AD429E25\r
   6         for <notmuch@notmuchmail.org>; Mon, 27 Jun 2011 15:41:57 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id s7VOAtf4caE5 for <notmuch@notmuchmail.org>;\r
  16         Mon, 27 Jun 2011 15:41:56 -0700 (PDT)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
  18         by olra.theworths.org (Postfix) with ESMTP id B80F9431FD0\r
  19         for <notmuch@notmuchmail.org>; Mon, 27 Jun 2011 15:41:56 -0700 (PDT)\r
  20 Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net\r
  21         [216.254.70.154])\r
  22         by che.mayfirst.org (Postfix) with ESMTPSA id CAA10F970\r
  23         for <notmuch@notmuchmail.org>; Mon, 27 Jun 2011 18:41:54 -0400 (EDT)\r
  24 Message-ID: <4E09072A.7040906@fifthhorseman.net>\r
  25 Date: Mon, 27 Jun 2011 18:41:46 -0400\r
  26 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  27 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;\r
  28         rv:1.9.2.17) Gecko/20110516 Icedove/3.1.10\r
  29 MIME-Version: 1.0\r
  30 To: Notmuch Mail <notmuch@notmuchmail.org>\r
  31 Subject: interaction between --format=raw and multipart handling [was: Re:\r
  32         Do not attept to output part raw if part is not GMimePart.]\r
  33 References: <1307032735-27427-1-git-send-email-jrollins@finestructure.net>\r
  34         <1307120466-4980-1-git-send-email-jrollins@finestructure.net>\r
  35         <87wrgccedd.fsf@yoom.home.cworth.org>\r
  36         <87mxh319un.fsf@servo.factory.finestructure.net>\r
  37         <BANLkTik8v7uZDcO4wV1Ve1Lymd03Z-WWdw@mail.gmail.com>\r
  38         <878vsn0x1i.fsf@servo.factory.finestructure.net>\r
  39         <20110627220741.GA4120@mit.edu>\r
  40 In-Reply-To: <20110627220741.GA4120@mit.edu>\r
  41 X-Enigmail-Version: 1.1.2\r
  42 Content-Type: multipart/signed; micalg=pgp-sha512;\r
  43         protocol="application/pgp-signature";\r
  44         boundary="------------enig016CC7533040F7A4A5342619"\r
  45 X-BeenThere: notmuch@notmuchmail.org\r
  46 X-Mailman-Version: 2.1.13\r
  47 Precedence: list\r
  48 Reply-To: notmuch <notmuch@notmuchmail.org>\r
  49 List-Id: "Use and development of the notmuch mail system."\r
  50         <notmuch.notmuchmail.org>\r
  51 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  53 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  54 List-Post: <mailto:notmuch@notmuchmail.org>\r
  55 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  56 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  57         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  58 X-List-Received-Date: Mon, 27 Jun 2011 22:41:57 -0000\r
  59 \r
  60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
  61 --------------enig016CC7533040F7A4A5342619\r
  62 Content-Type: text/plain; charset=UTF-8\r
  63 Content-Transfer-Encoding: quoted-printable\r
  64 \r
  65 On 06/27/2011 06:07 PM, Austin Clements wrote:\r
  66 > Oh, right, of course.  show_message_part will walk into the parts, so\r
  67 > format_part_content_raw will still be called on the leafs of a\r
  68 > requested multipart.  Though, this approach results in each leaf being\r
  69 > transfer decoded and printed individually, so if you ask for a\r
  70 > multipart, you won't get the "raw" contents of the multipart (unless\r
  71 > it's part 0), so much as you get the concatenated "raw" contents of\r
  72 > each part in the multipart.\r
  73 \r
  74 \r
  75 let's take two labeled examples:\r
  76 \r
  77 A=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 58292 bytes\r
  78 B =E2=94=9C=E2=94=AC=E2=95=B4multipart/mixed 56553 bytes\r
  79 C =E2=94=82=E2=94=9C=E2=95=B4text/plain 1278 bytes\r
  80 D =E2=94=82=E2=94=9C=E2=95=B4text/plain attachment [grub-install.out] 541=\r
  81 09 bytes\r
  82 E =E2=94=82=E2=94=94=E2=95=B4text/x-diff attachment [597538.patch] 496 by=\r
  83 tes\r
  84 F =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =\r
  85 900 bytes\r
  86 \r
  87 \r
  88 X=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 3863 bytes\r
  89 Y =E2=94=9C=E2=95=B4text/plain 1857 bytes\r
  90 Z =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =\r
  91 900 bytes\r
  92 \r
  93 (i know, you won't use "A" or "Z" as part IDs once we have hierarchical\r
  94 part numbers, but consider them placeholders).\r
  95 \r
  96 if parts F or Z are ever going to be useful (e.g. to some external\r
  97 process that wants to validate the signature by hand), then the tool\r
  98 needs to provide some way of producing parts B and Y in a pristine form\r
  99 (that is, including MIME headers and without interpreting/applying any\r
 100 transfer encodings).\r
 101 \r
 102 Perhaps this means there are two flavors of "raw" that we should be\r
 103 distinguishing, something like:\r
 104 \r
 105  0) "source" -- the equivalent to viewing the source of the message,\r
 106 with headers and without attempting to reverse transfer-encodings, etc.\r
 107 \r
 108  1) "rare" -- (not entirely raw, but still bloody, ha ha) strip headers,\r
 109 reverse transfer encodings, etc.\r
 110 \r
 111 I think our current implementation of --format=3Draw emits "source" when\r
 112 applied to the entire message, but "rare" when applied to one of the part=\r
 113 s.\r
 114 \r
 115 I'm suggesting that it might be useful to be able to get "source" of a\r
 116 part.  (and perhaps it might also be useful to get the whole message\r
 117 "rare" sometimes?)\r
 118 \r
 119 My first instinct was: if it's multipart, provide "source", if it's\r
 120 single-part, provide "rare".  But that fails for the XYZ case above --\r
 121 we'd need Y (which is single-part) to be provided as "source" if we were\r
 122 ever to be able to make use of Z on its own, so i don't think it'll be\r
 123 that simple.\r
 124 \r
 125 OTOH, i'm not sure that "rare" is particularly meaningful for non-leaf\r
 126 parts.\r
 127 \r
 128 > Daniel, is this the problem that you're getting at with "opacity"?\r
 129 \r
 130 the origin of the term "opaque" used in this context can be found in the\r
 131 definition of multipart/signed:\r
 132 \r
 133  https://tools.ietf.org/html/rfc1847#section-2.1\r
 134 \r
 135 > That if you ask for a multipart, you should effectively get a slice\r
 136 > out of the original message bytes (since multipart/* parts can't have\r
 137 > non-identity transfer encodings).  Are you also saying that should\r
 138 > extend to transfer encoded leaf parts, too?\r
 139 \r
 140 hmm.  is it true that multipart/* parts can't have non-identity transfer\r
 141 encodings?  that would simplify some things, but i don't have a\r
 142 reference handy that says it's the case.\r
 143 \r
 144 At any rate, i'm not sure it affects the need for being able to emit\r
 145 both "rare" and "source" forms of at least the leaf (non-multipart) parts=\r
 146 =2E\r
 147 \r
 148 i hope this is all at least somewhat clarifying and not just adding to\r
 149 the confusion,\r
 150 \r
 151         --dkg\r
 152 \r
 153 \r
 154 --------------enig016CC7533040F7A4A5342619\r
 155 Content-Type: application/pgp-signature; name="signature.asc"\r
 156 Content-Description: OpenPGP digital signature\r
 157 Content-Disposition: attachment; filename="signature.asc"\r
 158 \r
 159 -----BEGIN PGP SIGNATURE-----\r
 160 Version: GnuPG v1.4.11 (GNU/Linux)\r
 161 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
 162 \r
 163 iQJ8BAEBCgBmBQJOCQcqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
 164 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD\r
 165 Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpgVoQAIg+UCSpzFilQc2QLNUfDRmK\r
 166 WGqVYHaeNvWl6muvCzW+1oX3TM3kq1MaVrEkIgtLY3b1BPIdZ/0szKCRSvJcUzlW\r
 167 qCqfFwNYs3iwu8tIbS9hB7YnKf30Xq8zt0ACuNFzk67KHPu8eaVV7Eu4AeH++xoN\r
 168 PrO2cIc4ACiKBRrre2P1fJZRb9c+BftlU9lsWeqp1hVJD2udidf4rVM7AJ/QbjJH\r
 169 FvH2aWhE0fa1Suy9twcWhgV2ZhVIx1iTck271aTRJw/4ItVSOIpW0vaaM0bTjcn4\r
 170 SO1v16DBOu6S0rVtiOgxrztBYoT0EDL8Bn5fXq542vQRgKZoKnO2LDy1Dg1ffMLY\r
 171 WE2CiHKhw9YzETrmlUR4+Kzct+XRQwuPAAzYgtmj0sSgwIZSfN94evBcYol1YcDZ\r
 172 MaW0UyFNrwciJ1lZwm/njnLRdXYDYpDzxiFX5Eou62EdZxYDQPwM3oVTb6xZPlQV\r
 173 WK04w8MjpWYh0wf92+wO71+B36XYB43amxhxP9xldX1Itn301PK2YOiwWg+09LT2\r
 174 wS0KmdHMu32elWIvrp8xafhpkUgoMyr/idBglFmh723e7YTrIy8B1/O24lIfBuzi\r
 175 /bdWMVHJU2QTT8q6J7vyiudinnIJo/secQA9tLvnajwu0eaRRQ8IYjVIefx+MvJF\r
 176 o3A2YF+2b50sYJ+cKhbK\r
 177 =bVBl\r
 178 -----END PGP SIGNATURE-----\r
 179 \r
 180 --------------enig016CC7533040F7A4A5342619--\r