From: Guyzmo Date: Mon, 16 Mar 2015 11:18:30 +0000 (+0100) Subject: Re: Proposal: List-Id X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=b8b23c11ab9a106b8f8c0a1058a2e32e5d9fa9ff;p=notmuch-archives.git Re: Proposal: List-Id --- diff --git a/f9/cd592bfaa2df6a852f15892be809298fe2ecf3 b/f9/cd592bfaa2df6a852f15892be809298fe2ecf3 new file mode 100644 index 000000000..6f20a5324 --- /dev/null +++ b/f9/cd592bfaa2df6a852f15892be809298fe2ecf3 @@ -0,0 +1,112 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 828E5431FCF + for ; Mon, 16 Mar 2015 04:18:41 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 2.438 +X-Spam-Level: ** +X-Spam-Status: No, score=2.438 tagged_above=-999 required=5 + tests=[DNS_FROM_AHBL_RHSBL=2.438] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Asu2Ef-Fzonn for ; + Mon, 16 Mar 2015 04:18:38 -0700 (PDT) +Received: from mail.m0g.net (vilya.m0g.net [195.154.74.47]) + by olra.theworths.org (Postfix) with ESMTP id 3E2A5431FB6 + for ; Mon, 16 Mar 2015 04:18:38 -0700 (PDT) +Received: from localhost (localhost [127.0.0.1]) + by mail.m0g.net (Postfix) with ESMTP id DF2403E536C; + Mon, 16 Mar 2015 12:18:35 +0100 (CET) +X-Virus-Scanned: Debian amavisd-new at vilya.m0g.net +Received: from mail.m0g.net ([127.0.0.1]) + by localhost (sd-38500.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id QYccPse6qP7j; Mon, 16 Mar 2015 12:18:34 +0100 (CET) +Received: by mail.m0g.net (Postfix, from userid 1000) + id 0CB543E536E; Mon, 16 Mar 2015 12:18:33 +0100 (CET) +Date: Mon, 16 Mar 2015 12:18:30 +0100 +From: Guyzmo +To: Harlan Lieberman-Berg +Subject: Re: Proposal: List-Id +Message-ID: <20150316111830.GJ27498@vilya.online.net> +References: <87wq2huan3.fsf@setec.io> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <87wq2huan3.fsf@setec.io> +User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Mon, 16 Mar 2015 11:18:41 -0000 + +Hi Harlan, + +On Sun, Mar 15, 2015 at 07:02:56PM -0400, Harlan Lieberman-Berg wrote: +> One of my (few) problems right now with notmuch is around mailing lists +> that are copied, either as CC or BCC, on various emails that go around. +> My filtering inside notmuch right now doesn't catch all the messages, +> since the only tag I can match on is "to:foo@bar.org" and not all +> messages have the to rewritten. + +I'm not sure to correctly understand your issue. You're talking about +looking up all mails that are of a given mailing list? + +Then I'm not sure it needs notmuch to be patched, as this can be added +pretty easily using an incoming mail filter. I'm personally using +procmail, so it'd be one such as: + + :0:notmuch.lock + * ^List-[Ii][dD]:.* + { + TAGS="${TAGS} +ml -inbox" + } + +To have the inbox tag removed and the ml tag added. + +Then I tend to use the right hand side of the `+` on incoming mail, so +that I can choose a unique tag for my mail filtering upon subscription +to the mailing list: + + :0:notmuch.lock + * ^TO\/guyzmo\+[a-z0-9]+@m0g\.net + * MATCH ?? ^guyzmo\+\/[a-z0-9]+ + { + TAGS="+${MATCH}" + } + +As an example, just look my From header here ;-) + +> The standard for identifying mailing lists seems to be List-Id, as per +> RFC 2919. I can understand the desire to keep the number of headers +> included in the header block low, but I wonder if this might be a common +> enough use-case to suggest its inclusion. +> As a counter-argument, I can see the parallel to spam filtering which +> come with their own set of headers that are not special cased by +> notmuch, but there seems to be much more variety in headers there - as +> well as different user configurations. + +One issue I can see for indexing `List-Id` is that even though there's +an RFC for that, the value given can be either a `name `, a +`mail` or a `name` field. There's no real rule and the content can +sometimes be quite unreliable when it comes to index search. + +I believe that this discussion has happened in the past, and IIRC, the +output that it was not to be integrated. + +HTH, + +-- +Guyzmo