Date: Mon, 16 Mar 2015 12:18:30 +0100
From: Guyzmo <guyzmo+notmuch@m0g.net>
To: Harlan Lieberman-Berg <hlieberman@setec.io>
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
Precedence: list

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 <mail>`, 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