40/15f4ae068ca060eb57fa09b50ab8e41e8b5352

   1 Return-Path:\r
   2  <return-8va43byzm2pw5643unfnu6c7i6@temporary-address.scs.stanford.edu>\r
   3 X-Original-To: notmuch@notmuchmail.org\r
   4 Delivered-To: notmuch@notmuchmail.org\r
   5 Received: from localhost (localhost [127.0.0.1])\r
   6  by arlo.cworth.org (Postfix) with ESMTP id 499326DE0B2F\r
   7  for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 10:27:48 -0700 (PDT)\r
   8 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   9 X-Spam-Flag: NO\r
  10 X-Spam-Score: -2.301\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.550,\r
  13   RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001]\r
  14  autolearn=disabled\r
  15 Received: from arlo.cworth.org ([127.0.0.1])\r
  16  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  17  with ESMTP id 9J50nmrL0pfj for <notmuch@notmuchmail.org>;\r
  18  Mon, 31 Aug 2015 10:27:46 -0700 (PDT)\r
  19 Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
  20  by arlo.cworth.org (Postfix) with ESMTPS id 231326DE0AC2\r
  21  for <notmuch@notmuchmail.org>; Mon, 31 Aug 2015 10:27:46 -0700 (PDT)\r
  22 Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
  23  [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
  24  t7VHRbWX015282; Mon, 31 Aug 2015 10:27:37 -0700 (PDT)\r
  25 Received: (from dm@localhost)\r
  26  by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7VHRaWF016532;\r
  27  Mon, 31 Aug 2015 10:27:36 -0700 (PDT)\r
  28 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  29  return-8va43byzm2pw5643unfnu6c7i6@ta.scs.stanford.edu using -f\r
  30 From: dm-list-email-notmuch@scs.stanford.edu\r
  31 To: Amadeusz =?utf-8?B?xbtvxYJub3dza2k=?= <aidecoe@aidecoe.name>\r
  32 Subject: Re: muchsync files renames\r
  33 In-Reply-To: <87k2sbmzww.fsf@freja.aidecoe.name>\r
  34 References: <878u93ujdo.fsf@freja.aidecoe.name>\r
  35  <876146o920.fsf@ta.scs.stanford.edu> <871teu8kdd.fsf@freja.aidecoe.name>\r
  36  <87oahxojlv.fsf@ta.scs.stanford.edu> <87vbbwnbb4.fsf@freja.aidecoe.name>\r
  37  <87io7wr50y.fsf@ta.scs.stanford.edu> <87k2sbmzww.fsf@freja.aidecoe.name>\r
  38 Reply-To: David Mazieres expires 2015-11-29 PST\r
  39  <mazieres-27wj757hqhcqs9vy6uqq3div7e@temporary-address.scs.stanford.edu>\r
  40 Date: Mon, 31 Aug 2015 10:27:36 -0700\r
  41 Message-ID: <87oahnmkqf.fsf@ta.scs.stanford.edu>\r
  42 MIME-Version: 1.0\r
  43 Content-Type: text/plain; charset=utf-8\r
  44 Content-Transfer-Encoding: quoted-printable\r
  45 Cc: notmuch@notmuchmail.org\r
  46 X-BeenThere: notmuch@notmuchmail.org\r
  47 X-Mailman-Version: 2.1.18\r
  48 Precedence: list\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, 31 Aug 2015 17:27:48 -0000\r
  59 \r
  60 Amadeusz =C5=BBo=C5=82nowski <aidecoe@aidecoe.name> writes:\r
  61 \r
  62 >> So... based on all the evidence so fare the culprit seems to be that\r
  63 >> something is moving mail files into your Spam folder on the client.\r
  64 >> If that rings any bells and solves the problem, great.  If not, here\r
  65 >> is what we need to do to track it down further.\r
  66 >\r
  67 > I have followed you hints to track down the issue.  All of these\r
  68 > messages are spam. What I suspect follows.\r
  69 >\r
  70 > All of these files have been placed to new/ subdir by maildrop and\r
  71 > during posthook (afew) have been stripped of any tags besides 'spam'\r
  72 > tag, in particular 'unread' tag has been removed, but files still remain\r
  73 > in new/ subdir.  So... what had to happen is that during muchsync these\r
  74 > messages have been discovered as already read, so they don't belong to\r
  75 > new/ but must be moved to cur/.  And this is what happened on client\r
  76 > side.  During next muchsync these changes had to be pushed to server,\r
  77 > i.e. move from new/ to cur/.\r
  78 \r
  79 Right.  Muchsync checks to see if maildir.synchronize_flags is true on\r
  80 the client.  If it is, then muchsync calls\r
  81 notmuch_message_tags_to_maildir_flags after setting the flags (which is\r
  82 the same as what would happen if you set the tags manually with the\r
  83 "notmuch tag" command).\r
  84 \r
  85 A maildir file in the new/ directory can't have any tags (except the\r
  86 implicit unread flag, which is indicated by the absence of "S" in the\r
  87 end of the filename).  So the notmuch_message_tags_to_maildir_flags()\r
  88 function is renaming the file to the cur subdirectory, and then\r
  89 propagating this rename back to the server.\r
  90 \r
  91 The one thing I'm still unclear on is whether afew is running on the\r
  92 client of the server.  If you are running it on the client, then this\r
  93 makes sense.  If you are running it on the server, then somehow afew\r
  94 must not be respecting the maildir.synchronize_flags setting.\r
  95 Otherwise, the file should already be moved to the cur directory after\r
  96 having the unread tag stripped off on the server.  I guess the other\r
  97 option is that your maildir.synchronize_flags false on the server and\r
  98 true on the client.\r
  99 \r
 100 > So if my assumptions are correct, actually there is no issue!  I would\r
 101 > just have to adjust afew filtering to prevent this behaviour.\r
 102 \r
 103 Right.  You could have afew preserve the unread flag on spam.\r
 104 Alternatively, you could just disable maildir.synchronize_flags on both\r
 105 the client and server.  Finally, you could just accept the performance\r
 106 penalty, as one would hope that this is a one-time thing and that\r
 107 usually you don't have 5000 new spam messages every time you synchronize\r
 108 your mail.\r
 109 \r
 110 David\r