Re: Avoiding the "huge INBOX of death"
[notmuch-archives.git] / dc / 2717acb7a99aef7d040dc20b9d2530b962fa82
1 Return-Path: <MarkR.Anderson@amd.com>\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 D5F71431FAF\r
6         for <notmuch@notmuchmail.org>; Fri, 14 Sep 2012 09:27:38 -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.7\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 wsI8OPNDsxp2 for <notmuch@notmuchmail.org>;\r
16         Fri, 14 Sep 2012 09:27:36 -0700 (PDT)\r
17 Received: from db3outboundpool.messaging.microsoft.com\r
18         (db3ehsobe001.messaging.microsoft.com [213.199.154.139])\r
19         (using TLSv1 with cipher AES128-SHA (128/128 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id B8A8F431FAE\r
22         for <notmuch@notmuchmail.org>; Fri, 14 Sep 2012 09:27:35 -0700 (PDT)\r
23 Received: from mail26-db3-R.bigfish.com (10.3.81.250) by\r
24         DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id\r
25         14.1.225.23; Fri, 14 Sep 2012 16:27:34 +0000\r
26 Received: from mail26-db3 (localhost [127.0.0.1])       by mail26-db3-R.bigfish.com\r
27         (Postfix) with ESMTP id 5FDC9400A9;\r
28         Fri, 14 Sep 2012 16:27:34 +0000 (UTC)\r
29 X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);\r
30         IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI\r
31 X-SpamScore: -13\r
32 X-BigFish: VPS-13(zzbb2dI98dI154cP9371I1432I4015I1415Id6f1izz1202h1d1ah1d2ahzz8275ch17326ah8275bh8275dhz2dh668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh1155h)\r
33 Received: from mail26-db3 (localhost.localdomain [127.0.0.1]) by mail26-db3\r
34         (MessageSwitch) id 1347640053311330_2169;\r
35         Fri, 14 Sep 2012 16:27:33 +0000 (UTC)\r
36 Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.233]) by\r
37         mail26-db3.bigfish.com (Postfix) with ESMTP id 3EF501E0071;\r
38         Fri, 14 Sep 2012 16:27:33 +0000 (UTC)\r
39 Received: from ausb3twp01.amd.com (163.181.249.108) by\r
40         DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server id\r
41         14.1.225.23; Fri, 14 Sep 2012 16:27:31 +0000\r
42 X-WSS-ID: 0MACLPT-01-A9J-02\r
43 X-M-MSG: \r
44 Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com\r
45         [163.181.249.72])       (using TLSv1 with cipher AES128-SHA (128/128\r
46         bits))  (No\r
47         client certificate requested)   by ausb3twp01.amd.com (Axway MailGate\r
48         3.8.1)\r
49         with ESMTP id 275DA10280AB;     Fri, 14 Sep 2012 11:27:29 -0500 (CDT)\r
50 Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com\r
51         (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;\r
52         Fri, 14 Sep 2012 11:41:23 -0500\r
53 Received: from adcvmail01.amd.com (163.181.21.78) by sausexhtp01.amd.com\r
54         (163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;\r
55         Fri, 14 Sep 2012 11:27:29 -0500\r
56 Received: from brewmaster.amd.com (brewmaster.amd.com [165.204.144.45]) by\r
57         adcvmail01.amd.com (8.13.8/8.13.8) with ESMTP id q8EGRP6i011196;\r
58         Fri, 14 Sep 2012 11:27:25 -0500\r
59 Received: from testarossa.amd.com (testarossa.amd.com [165.204.147.44]) by\r
60         brewmaster.amd.com (8.13.8/8.13.8) with ESMTP id q8EGRSYK005287;\r
61         Fri, 14 Sep 2012 10:27:28 -0600\r
62 Received: (from manderso@localhost)     by testarossa.amd.com\r
63         (8.13.8/8.13.8/Submit) id q8EGRND8031091;\r
64         Fri, 14 Sep 2012 10:27:23 -0600\r
65 X-Authentication-Warning: testarossa.amd.com: manderso set sender to\r
66         MarkR.Anderson@amd.com using -f\r
67 From: Mark Anderson <MarkR.Anderson@amd.com>\r
68 To: Rainer M Krug <R.M.Krug@gmail.com>, <notmuch@notmuchmail.org>\r
69 Subject: Re: Better Gmail handling by not using Notmuch tags\r
70 In-Reply-To: <5052E1A9.8060503@gmail.com>\r
71 References:\r
72  <CA+y5gghe68Sy6BK8FdeGbKEESFD_=2GQ+y+oZSYyt85oQqRuzA@mail.gmail.com>\r
73         <CA+eQo_0nK1rL6DYu2ERqF3U=vZAO_XTpXDtzydHQqBtXqHUOxQ@mail.gmail.com>\r
74         <CA+y5gghnzinnXiabFOEphAuWTJA5Uge9RtGbKu9ur5rP50i_5g@mail.gmail.com>\r
75         <5052E1A9.8060503@gmail.com>\r
76 User-Agent: Notmuch/0.11.1+251~g1093c24 (http://notmuchmail.org) Emacs/23.2.1\r
77         (i686-pc-linux-gnu)\r
78 Date: Fri, 14 Sep 2012 10:27:23 -0600\r
79 Message-ID: <3wda9ws4ljo.fsf@testarossa.amd.com>\r
80 MIME-Version: 1.0\r
81 Content-Type: text/plain; charset="us-ascii"\r
82 X-OriginatorOrg: amd.com\r
83 Cc: Jeremy Nickurak <public-not-much-kexSNQTsIoD754YsiR0rpA@plane.gmane.org>\r
84 X-BeenThere: notmuch@notmuchmail.org\r
85 X-Mailman-Version: 2.1.13\r
86 Precedence: list\r
87 List-Id: "Use and development of the notmuch mail system."\r
88         <notmuch.notmuchmail.org>\r
89 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
90         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
91 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
92 List-Post: <mailto:notmuch@notmuchmail.org>\r
93 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
94 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
95         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
96 X-List-Received-Date: Fri, 14 Sep 2012 16:27:39 -0000\r
97 \r
98 On Fri, 14 Sep 2012 09:50:01 +0200, Rainer M Krug <R.M.Krug@gmail.com> wrote:\r
99 > -----BEGIN PGP SIGNED MESSAGE-----\r
100 > Hash: SHA1\r
101\r
102 > On 13/09/12 17:15, Damien Cassou wrote:\r
103 > > On Thu, Sep 13, 2012 at 5:13 PM, Jeremy Nickurak \r
104 > > <not-much@trk.nickurak.ca> wrote:\r
105 > >> Gmail doesn't have folders, of course, it has labels, which are\r
106 > >> approximately equivalent to notmuch tags. The key difference being\r
107 > >> that a message can only be in one folder, but it can have multiple\r
108 > >> tags/labels.\r
109 > > \r
110 > > Gmail exports its labels as IMAP folders: an email with multiple\r
111 > > labels will be duplicated in multiple folders (one per\r
112 > > label). That's why I'm asking if it would be possible to manupale\r
113 > > folders from Notmuch instead of tags.\r
114 > > \r
115\r
116 > I don't think there is an easy solution. notmuch uses a maildir and\r
117 > tags. Gmail needs to be synced to this local maildir earlier, and this\r
118 > is where I think the problem comes in: I am not aware of any sync tool\r
119 > which maintains the gmail labels, as they are in in the imap context\r
120 > folders.\r
121\r
122 > I think the only real solution woud be:\r
123\r
124 > Download from gmail -> local:\r
125 > 1) download only the "All Mail" folder\r
126 > 2) implement a tagging tool which syncs the gmail labels to notmuch tags\r
127 \r
128 Gmail's IMAP protocol does expose a folder hierarchy which you can use\r
129 to reverse engineer the tag cloud of each email.  \r
130 \r
131 Using Offlineimap will happily sync a your Gmail such that each mail\r
132 will show up in every folder corresponding to the tags with which the\r
133 mail is tagged.  When notmuch scans the mail, it will collapse these\r
134 multiple mails into one mail message by message-id: and you just need a\r
135 script to translate folders into tags.  The incoherence between notmuch\r
136 tag and mail folders then communicates something different if you are\r
137 pre-sync or post-sync. I am calling the offlineimap call "sync", so once\r
138 we run it (the first time for sure) we are in 'post-sync'.\r
139 \r
140 \r
141 You might want to take this chance to make your tag cloud coherent\r
142 between Notmuch and what exists in the folders, which works out to\r
143 something like this for every tag/folder pair in your gmail IMAP\r
144 directory (assuming it's synced to a Maildir repository) and notmuch DB.\r
145 \r
146   notmuch tag +TagX folder:FolderX and not tag:TagX \r
147 \r
148 Although strictly speaking it isn't actually necessary to put the \r
149 "and not tag:TagX" term, as this term this is now implicitly added by\r
150 notmuch to improve performance and avoid touching database entries that\r
151 already have the tag, I include it to demonstrate the coherence between\r
152 TagX and FolderX.\r
153 \r
154 Then you'll want to handle TagX being removed on the Gmail side too,\r
155 so you'll want to do something like this to remove the notmuch TagX.\r
156  \r
157   notmuch tag -TagX tag:TagX and not folder:FolderX\r
158 \r
159 Then there's the reverse direction to consider.\r
160 \r
161 When I see TagX in notmuch, and using FolderX as the proxy for Gmail\r
162 tags, then I assume that the user added TagX in notmuch and I need to\r
163 synchronize the change.  This one is a bit trickier.\r
164 \r
165   notmuch search --output=files tag:TagX and not folder:FolderX \r
166 \r
167 will give me the list of filenames, but I need to add them to a folder,\r
168 so it's time for bash, or your favorite script language.  Spaces in\r
169 filenames or tags are your bane here, then you'll want to do something\r
170 fancier than just the $() interpolation.\r
171 \r
172 notmuch search --output=files tag:notmuch and not folder:notmuch |\r
173 xargs perl -e'while (defined($_ = shift(@ARGV))) {my $file =\r
174 filename($_); system("cp $_ $MAILDIR/notmuch/cur/$file");}'\r
175 \r
176 Then when I see a mail in FolderX without TagX, that indicates that I\r
177 have removed the tag from notmuch, so I will want to remove the copy of\r
178 the file from FolderX, and only FolderX.\r
179 \r
180 This requires you to scan through the list of filenames associated with\r
181 the msg-id and delete the file in FolderX.\r
182 \r
183 Of course this is terrible on performance, as you will have lots of\r
184 copies of mails when you have lots of tags on your mail, but here's a\r
185 summary of the actions you need to coordinate to keep them in sync.\r
186 \r
187 \r
188 Stage      FolderX    TagX      Action\r
189 =====      =======    ====      ======\r
190 post-sync  No         No        No Action\r
191 \r
192 post-sync  No         Yes       Gmail TagX removed caused FolderX copy\r
193                                 to be removed, remove Notmuch TagX\r
194 \r
195 post-sync  Yes        No        Gmail TagX added, add Notmuch TagX\r
196 \r
197 post-sync  Yes        Yes       No Action\r
198 \r
199 pre-sync   No         No        No Action\r
200 \r
201 pre-sync   No         Yes       Notmuch TagX added, copy mail to FolderX\r
202                                 to add Gmail TagX corresponding to\r
203                                 notmuch TagX \r
204 \r
205 pre-sync   Yes        No        Notmuch TagX removed, delete mail copy\r
206                                 in FolderX\r
207 \r
208 pre-sync   Yes        Yes       No Action\r
209 \r
210 The worst part about this, is that any interrupted action must be\r
211 retried until successful, unless we have information about the relative\r
212 times of the actions.  If instead of trying to rationalize the two\r
213 "states" of my messages, I was trying to synchronize the changes, then I\r
214 just need to go down the list of changes and take the appropriate action.\r
215 \r
216 You might have other actions, such as a true delete in Notmuch, which\r
217 should remove all copies of the email before doing a mail sync.\r
218 \r
219 The benefit of using the mail sync is it uses a widely distributed mail\r
220 synchronization model, but it really tags expensive to synchronize.  It\r
221 gets better if you use the Gmail imap extensions that can list the tags\r
222 without your client requesting a copy of the entire email for each tag\r
223 the mail has.  However, Even when you have that, you don't have\r
224 bulletproof mail, because the actions need to be guaranteed to complete\r
225 before synchronization and after synchronization, and any user changes\r
226 need to be held off, as they _will_ be interpreted incorrectly if they\r
227 take place during the pre-sync, sync, post-sync window.\r
228 \r
229 You can simplify this if you make guarantees in your usage model.  That\r
230 you will never do tagging operations during a pre-, sync, post- cycle,\r
231 or that you only do synchronization one way or the other, instead of\r
232 full bidirectional sync.\r
233 \r
234 It's a difficult problem, I look forward to seeing other solutions\r
235 proposed.\r
236 \r
237 Thanks,\r
238 -Mark Anderson\r
239 \r
240 > upload local -> gmail\r
241 > 1) upload "All Mail folder\r
242 > 2) assign on gmail the labels corresponding to the notmuch tags.\r
243\r
244 > The step 1 could be done by any sync tool available for this (offlineimap, ...)\r
245\r
246 > step 2 needs to be developed - no idea how, but it surely would be really usefull, because then\r
247 > notmuch would even become a perfect tool for gmail backup as well.\r
248\r
249 > Cheers,\r
250\r
251 > Rainer\r
252 > -----BEGIN PGP SIGNATURE-----\r
253 > Version: GnuPG v1.4.11 (GNU/Linux)\r
254 > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/\r
255\r
256 > iEYEARECAAYFAlBS4akACgkQoYgNqgF2egoGhwCaAgfXQUAK4RK1v22JOhgYXfR1\r
257 > +C8AnRU892SrxK7IYN9xoxhM865Y+vTA\r
258 > =ma75\r
259 > -----END PGP SIGNATURE-----\r
260\r
261 > _______________________________________________\r
262 > notmuch mailing list\r
263 > notmuch@notmuchmail.org\r
264 > http://notmuchmail.org/mailman/listinfo/notmuch\r
265\r
266 \r