From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 2J0jG5OL7mbUFQEAe85BDQ:P1 (envelope-from ) for ; Sat, 21 Sep 2024 09:02:11 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 2J0jG5OL7mbUFQEAe85BDQ (envelope-from ) for ; Sat, 21 Sep 2024 11:02:11 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=pengjiz.com header.s=fm3 header.b=tTcveu40; dkim=fail ("body hash did not verify") header.d=messagingengine.com header.s=fm2 header.b=ldZeJwYJ; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 135.181.149.255 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1726909331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=PjgOvBhFr/varfUwEEm7QjtCP9ylihegl0b4fZwE4QM=; b=tca+NuO2O+Wxe7tBuq5VcuKZdquI6WABiUAgFxuxGZ1a1MFw0anI/TYF+zIyk1JtH95hGK 8ofFTS5V+/s5ip8eDvkPB7ltKIq9zPEATOZW0JGIs7MsrG/54+S2MHplGgy1QpwbzIo5eB wDHLHPloUWAqXOnEwUOgZH95+1rRSKEoJsf+CVqPX2+1wB/0oQtnISPy5Ey3Zq6F2GlBqV f6dDmNs/sj1XQkF1Q6R4eFJ6P/KAbrF8rXr5QgdDjk8Qp9aN+Tl0uwDFDboJwCavIoLiUk xC1FsYoranDUj9qQ5kiT7IewFesvHWCGwKmZbhTL+/lY4lfqoPTNo7HSWChvCw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1726909331; a=rsa-sha256; cv=none; b=lSHVZVgYhH5rE1Cz1l4LYl2YudV4uKpAGQ3I1WEBnmGcLGOOmac+gtkcmVX4F4TJpXKoMX jaJDlTvkczJQeciYXYV25rvYYoG1ar9cX9zYzUVl8xhFbgyjkVjdt5oQXs/87rhFosFrul 83J7PpQPgnWDIIOSSsvi9gAvDueYoXpSgYKpEtW2NkGAiptKbfIqyeVULRJtkyjhKBJzqA jkgwAMV0Bzu1O1bhk1tIg9vOmKpitdXMEe5ygMlOL/D+zv+jlpFn0nu7rDtRTooW+swcTh iF672jcCl2fRJ+frm/ah3uQ+CO/7R92zZ6WUeNxqLUqS4qPzo1miaNsEJ6l8nw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=pengjiz.com header.s=fm3 header.b=tTcveu40; dkim=fail ("body hash did not verify") header.d=messagingengine.com header.s=fm2 header.b=ldZeJwYJ; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 135.181.149.255 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org Received: from mail.notmuchmail.org (yantan.tethera.net [135.181.149.255]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BAF1414567 for ; Sat, 21 Sep 2024 11:02:10 +0200 (CEST) Received: from yantan.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 6282B5F81C; Sat, 21 Sep 2024 09:02:07 +0000 (UTC) Received: from fhigh2-smtp.messagingengine.com (fhigh2-smtp.messagingengine.com [103.168.172.153]) by mail.notmuchmail.org (Postfix) with ESMTPS id 72C905E527 for ; Sat, 21 Sep 2024 09:02:04 +0000 (UTC) Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfhigh.phl.internal (Postfix) with ESMTP id D6D2811400B8; Sat, 21 Sep 2024 05:02:02 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Sat, 21 Sep 2024 05:02:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pengjiz.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1726909322; x=1726995722; bh=UIlTMJ6ddm dNw+Ip5Nvugp8Npu1HkXD2P7Zgr2F91uQ=; b=tTcveu40VVrqzN1lDHt7/zZ0e0 k4pA7SUPmQ4YrzGwt5Vy7gpm9Ot7mKdijvSMX7frKFEf96pcFHUwF88SrMfK9imt QpDdpiOlAquFLB8Yiyh9JybgLQvwXPpJyxfFJDF5kXPtTb1s7b8eZZQX5mtdkKWL jNXlW7MKZCvDUgEIt9CO1FyOyhND6jAMUBvSi+OQVB9K4oIwHtszYU/3fka1QoU6 J63NTRMxE+d/cYMbGCKCqNQqqhTyiOKtP+v2bnyP113NG8ug0bfR9o64PGV0w/qz zelonx/gejbFJNrZRZwMRQjGZvPRKOnleKCuOUr4KYL4hQXcHSZUhqMLgapg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1726909322; x=1726995722; bh=UIlTMJ6ddmdNw+Ip5Nvugp8Npu1H kXD2P7Zgr2F91uQ=; b=ldZeJwYJLVmNRz6BRZI3ihzePnKSA7L8jJ6yze4k9Pm4 nOa/qrniu0bE9SfyZRWiOxjDwZKWSO3PkkcEScHx/8KAtENb07jWxgF4J3V3/aJI vi9yOJnrhObMRE47ntRY5eBu0nblBPKPnxclr3PQDmKdrNik9S4JkaQ4XJoijU7b Kf+iQ6JMC/pOYE/o1XcjNZ4ui22OX000yzMV3FVg05QUCvRIFdQ6G+I3UGqVk+2z C3qCd14VKDZLVGjTZwmAlwNYjWKh3K1zTQlFSWkAZGelcyZIPskcZtYGLRdLa+xB 4Cezg4U0zx4jWumfoOddmF1Xav8K2ut7UltGMZlTcw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudelhedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvfevuf gjfhffkfggtgesthdtredttddttdenucfhrhhomheprfgvnhhgjhhiucgkhhgrnhhguceo mhgvsehpvghnghhjihiirdgtohhmqeenucggtffrrghtthgvrhhnpeegfeeiiedvudekie dtgedufedtvedtueetieffhfdvhefftefgieejieelleehgeenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmvgesphgvnhhgjhhiiidrtghomh dpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhr vgguvghrihhksehofhgsrdhnvghtpdhrtghpthhtohepnhhothhmuhgthhesnhhothhmuh gthhhmrghilhdrohhrgh X-ME-Proxy: Feedback-ID: i16614472:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 21 Sep 2024 05:02:01 -0400 (EDT) From: Pengji Zhang To: frederik@ofb.net Subject: Re: searching for a message by path In-Reply-To: <20240921032340.opozeclfbyqzw2yt@localhost> References: <20240920175232.zryeqyl76nbydiab@localhost> <87zfo1dfa1.fsf@pengjiz.com> <20240921032340.opozeclfbyqzw2yt@localhost> Date: Sat, 21 Sep 2024 17:01:58 +0800 Message-ID: <87msk1752x.fsf@pengjiz.com> MIME-Version: 1.0 Message-ID-Hash: B6PV3DQB7HTDHEYS5NJBV5PCSTL3REZW X-Message-ID-Hash: B6PV3DQB7HTDHEYS5NJBV5PCSTL3REZW X-MailFrom: me@pengjiz.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: notmuch@notmuchmail.org X-Mailman-Version: 3.3.3 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Content-Type: text/plain; format="flowed"; charset="us-ascii" X-Migadu-Country: DE X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.31 X-Spam-Score: -3.31 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Queue-Id: BAF1414567 X-TUID: abAM0Kk6FcqJ Frederick Eaton writes: > No, I already have that configuration. The first sentence > described what I already know how to do, the second sentence is > what I'm trying to do. > > Suppose the filter script reads a message from a particular file > and decides that it is spam. How does the filter tell Notmuch > that the message corresponding to that file is spam? You seem to > be saying below that the filter script should extract the > Message-ID and use it to identify the message to Notmuch, since > file paths of the messages are not indexed. Probably what my > script should be doing for each message is appending a line to a > batch file like this: > > +spam -new -- id:some_message_id@foo +inbox -new -- > id:some_other@baz > > and then passing the batch file to "notmuch tag"? Yes, message ID is considered unique for each email, according to 'src/database.cc': A mail document is associated with a particular email message. It is stored in one or more files on disk and is uniquely identified by its "id" field (which is generally the message ID). I remember that if there are multiple emails sharing a message ID, then they will share the same set of tags as well. At least that is the case if I add a duplicate message using 'notmuch insert'. > This time, I'm not sure I understand. As mentioned above, they share the set of tags so I guess there is no need to bother. > It might be useful for the reasons I stated, namely in case the > Message-ID does not exist or is not unique. I suppose it does not help either in that case, because they are considered the same in the database. > Thank you for interpreting that section for me. The manual pages > may be informative and well written, but if my opinion matters, > then I think that they could be made slightly clearer than they > are. > For example, explaining directly to the user that there is no > index of path names would help clarify what can be done with the > software. Also, a short example of using Notmuch in a filter > script would be useful in one of the manual pages, particularly > illustrating the case where the programmer wants to re-tag a > message that is provided as a file or on stdin. > > [...] > > I see now that this text is only suggesting that Notmuch > supports searches for directory names, but on first read it > wasn't really clear to me whether "directory-path" means a "path > to a directory" or a "file path consisting of directories > followed by a filename", particularly as there is no obvious > reason for Notmuch not to index filenames. I think > "path:" would be clearer, and saying "The path: > prefix matches email messages that are stored in a specified > directory on the filesystem, which must be specified relative to > the top-level maildir, and here is how to find out what the > 'top-level maildir' is when you have for example > $HOME/mail/notmuch/ configured as your database path in > ~/.notmuch-config ...". Even clearer would be to explain why the > "path:" search prefix only accepts directories, point out that > it should be called "dir:" instead of "path:", and warn the user > that the search will be inefficient because there is no index of > filenames. Sorry that I assumed you had ignored that paragraph in the manual! I am not a native speaker so I have no opinions on the wording. I am happy with the existing search terms, but using a custom filter script in query does sound useful, and I would love to see such an example if Notmuch already has support for that. Just my two cents. Pengji