Twas brillig at 16:51:17 16.12.2009 UTC-07 when bdale at gag.com did gyre and
gimble:
>> But the above sounds like the List-Id header is unreliable enough to
>> be useless.
BG> FWIW, that does not match my experience.
Yeah. This mail just arrived to my "main" folder instead of "notmuch"
> I'd had much better luck matching List-Id than matching addresses in
> recent years. YMMV.
As long as you're not CC:d, you're fine. If you're CC:'d, well, Mailman
is more brain-dead than you could imagine.
Mike.
On Thu, 2009-12-17 at 06:01 +0600, Mikhail Gusarov wrote:
> Twas brillig at 16:51:17 16.12.2009 UTC-07 when bdale at gag.com did gyre and
> gimble:
>
> >> But the above sounds like the List-Id header is unreliable enough to
> >> be useless.
>
> BG> FWIW, that does not match my experience.
>
On Fri, 2009-12-04 at 10:35 -0800, Carl Worth wrote:
> But the above sounds like the List-Id header is unreliable enough to be
> useless.
FWIW, that does not match my experience.
> Any reason not to just use something like
> to:notmuch at notmuchmail to match messages sent to a list like this
On Fri, 2009-12-04 at 10:35 -0800, Carl Worth wrote:
But the above sounds like the List-Id header is unreliable enough to be
useless.
FWIW, that does not match my experience.
Any reason not to just use something like
to:notm...@notmuchmail to match messages sent to a list like this one?
I'd had much better luck matching List-Id than matching addresses in
recent years. YMMV.
As long as you're not CC:d, you're fine. If you're CC:'d, well, Mailman
is more brain-dead than you could imagine.
Mike.
___
notmuch mailing list
On Fri, 04 Dec 2009 16:39:50 -0800, Carl Worth wrote:
> But when viewing an actual message, I'm still planning on having notmuch
> just return an arbitrary filename from the list of filenames associated
> with that message. Does anyone see any problem with that? Can you think
> of a case where
Twas brillig at 16:39:50 04.12.2009 UTC-08 when cworth at cworth.org did gyre
and gimble:
CW> But when viewing an actual message, I'm still planning on having
CW> notmuch just return an arbitrary filename from the list of
CW> filenames associated with that message. Does anyone see any
Twas brillig at 10:35:27 04.12.2009 UTC-08 when cworth at cworth.org did gyre
and gimble:
>> The only problem with Cc is that Mailman suppresses duplicate
>> messages and hence there is no List-Id: on message.
CW> But the above sounds like the List-Id header is unreliable enough
CW> to be
Twas brillig at 10:05:05 04.12.2009 UTC-08 when cworth at cworth.org did gyre
and gimble:
CW> Plus, notmuch already handles duplicate mail just fine, (in that the
CW> user only sees one copy at least). And I tag my mail differently when
CW> one of my addresses appears on the CC list, so I
On Sat, 05 Dec 2009 09:51:58 +0100, Marten Veldthuis mar...@veldthuis.com
wrote:
On Fri, 04 Dec 2009 16:39:50 -0800, Carl Worth cwo...@cworth.org wrote:
But when viewing an actual message, I'm still planning on having notmuch
just return an arbitrary filename from the list of filenames
On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman wrote:
> Besides, in notmuch, what's the difference going to be? It'll still be
> threaded the same, etc., but you'd be able to tell that this one came
> to you rather than through the list, no?
There's one other point I should make here
On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman wrote:
> Now, if you have an MTA that does duplicate suppression based on
> message-id, you probably won't see the copy of a message that went to
> the list if you're cc:'d on it because the direct copy (sans list-id
> header) is likely to
On Sat, 05 Dec 2009 00:55:20 +0600
Mikhail Gusarov wrote:
>
> Twas brillig at 13:52:20 04.12.2009 UTC-05 when
> mdorman at ironicdesign.com did gyre and gimble:
>
> MAD> Err, this makes no sense. How can Mailman have any knowledge
> MAD> of, and therefore "do anything" to any message that
> But the above sounds like the List-Id header is unreliable enough to
> be useless.
In my current .sieve setup, I have 93 entries for mailing lists. 87
of them use list-id[1]. 3 use list-post. 1 uses 'mailing-list', but
looking at it, could be switched to list-id. 2 use x-mailing-list
On Sat, 05 Dec 2009 00:07:36 +0600
Mikhail Gusarov wrote:
> The only problem with Cc is that Mailman suppresses duplicate
> messages and hence there is no List-Id: on message.
Err, this makes no sense. How can Mailman have any knowledge of, and
therefore "do anything" to any message that came
On Sat, 05 Dec 2009 00:07:36 +0600, Mikhail Gusarov wrote:
> The only problem with Cc is that Mailman suppresses duplicate messages and
> hence
> there is no List-Id: on message.
Hey, well notmuch doesn't even index the List-Id: header anyway. [*] ;-)
But the above sounds like the List-Id
On Fri, 04 Dec 2009 09:55:45 -0400, david at tethera.net wrote:
> P.S. do people want to be CC'd on this list, or not?
We don't require subscription to the list, so I recommend CC, yes.
Plus, notmuch already handles duplicate mail just fine, (in that the
user only sees one copy at least). And I
At Thu, 03 Dec 2009 16:45:22 -0800,
> Anyway, I think we'll see code for that soon, so I'm not planning to
> commit the offered patch. But people really needing renames might want
> to use it for now, (and live with any performance implications it
> causes).
I could live with the performance
On Fri, 04 Dec 2009 09:55:45 -0400, da...@tethera.net wrote:
P.S. do people want to be CC'd on this list, or not?
We don't require subscription to the list, so I recommend CC, yes.
Plus, notmuch already handles duplicate mail just fine, (in that the
user only sees one copy at least). And I tag
Twas brillig at 10:05:05 04.12.2009 UTC-08 when cwo...@cworth.org did gyre and
gimble:
CW Plus, notmuch already handles duplicate mail just fine, (in that the
CW user only sees one copy at least). And I tag my mail differently when
CW one of my addresses appears on the CC list, so I
On Sat, 05 Dec 2009 00:07:36 +0600, Mikhail Gusarov dotted...@dottedmag.net
wrote:
The only problem with Cc is that Mailman suppresses duplicate messages and
hence
there is no List-Id: on message.
Hey, well notmuch doesn't even index the List-Id: header anyway. [*] ;-)
But the above sounds
But the above sounds like the List-Id header is unreliable enough to
be useless.
In my current .sieve setup, I have 93 entries for mailing lists. 87
of them use list-id[1]. 3 use list-post. 1 uses 'mailing-list', but
looking at it, could be switched to list-id. 2 use x-mailing-list
(blasted
On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman
mdor...@ironicdesign.com wrote:
Now, if you have an MTA that does duplicate suppression based on
message-id, you probably won't see the copy of a message that went to
the list if you're cc:'d on it because the direct copy (sans list-id
On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman
mdor...@ironicdesign.com wrote:
Besides, in notmuch, what's the difference going to be? It'll still be
threaded the same, etc., but you'd be able to tell that this one came
to you rather than through the list, no?
There's one other point
Twas brillig at 16:39:50 04.12.2009 UTC-08 when cwo...@cworth.org did gyre and
gimble:
CW But when viewing an actual message, I'm still planning on having
CW notmuch just return an arbitrary filename from the list of
CW filenames associated with that message. Does anyone see any problem
CW
On Thu, 3 Dec 2009 03:15:26 +0600, Mikhail Gusarov wrote:
> In order to handle message renames the following changes were deemed
> necessary:
Hi Mikhail,
Thanks for contributing this patch (twice!). I think if I had gotten to
it sooner, I probably would have committed it. But now...
> * Mtime
In order to handle message renames the following changes were deemed necessary:
* Mtime check on individual files was disabled. As files may be moved around
without changing their mtime, it's necessary to parse them even if they appear
old in case old message was moved. mtime check on directories
On Thu, 3 Dec 2009 03:15:26 +0600, Mikhail Gusarov dotted...@dottedmag.net
wrote:
In order to handle message renames the following changes were deemed
necessary:
Hi Mikhail,
Thanks for contributing this patch (twice!). I think if I had gotten to
it sooner, I probably would have committed it.
In order to handle message renames the following changes were deemed necessary:
* Mtime check on individual files was disabled. As files may be moved around
without changing their mtime, it's necessary to parse them even if they appear
old in case old message was moved. mtime check on directories
30 matches
Mail list logo