From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/55987 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap and crossposting (Re: Moving from nnml to nnimap...) Date: Tue, 13 Jan 2004 02:59:00 -0500 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <87he0ur0yg.fsf@enki.rimspace.net> <4nisl9envb.fsf@lockgroove.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073980759 3438 80.91.224.253 (13 Jan 2004 07:59:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Jan 2004 07:59:19 +0000 (UTC) Original-X-From: ding-owner+M4527@lists.math.uh.edu Tue Jan 13 08:59:15 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AgJSF-0007PY-00 for ; Tue, 13 Jan 2004 08:59:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1AgJS8-0001Jq-00; Tue, 13 Jan 2004 01:59:08 -0600 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1AgJS3-0001Jl-00 for ding@lists.math.uh.edu; Tue, 13 Jan 2004 01:59:03 -0600 Original-Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by justine.libertine.org (Postfix) with ESMTP id C544F3A003B for ; Tue, 13 Jan 2004 01:59:02 -0600 (CST) Original-Received: from 216-15-127-174.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com ([216.15.127.174] helo=raeburn.org) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 1AgJS1-0005vc-00 for ding@gnus.org; Tue, 13 Jan 2004 02:59:01 -0500 Original-Received: from kal-el.raeburn.org (mail@kal-el.raeburn.org [18.101.0.230]) by raeburn.org (8.11.6/8.11.6) with ESMTP id i0D7x0C23025; Tue, 13 Jan 2004 02:59:00 -0500 (EST) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 1AgJS0-0007AL-00; Tue, 13 Jan 2004 02:59:00 -0500 Original-To: ding@gnus.org In-Reply-To: (Simon Josefsson's message of "Wed, 07 Jan 2004 02:29:31 +0100") Original-Lines: 57 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1.50 (i686-pc-linux-gnu) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:55987 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:55987 Simon Josefsson writes: > Well, IMAP does; the client-specific message flags are just that. If > servers cannot handle many client-specific flags, then we can't use > this idea, though. OTOH, it looks difficult to find any other > portable solution, so perhaps we can fix the arbitrary limit in Cyrus > and use this idea anyway. Otherwise I think we're left with > client-instance-specific solutions like the nnmail message-id cache > backlog, which I agree are no good. I wonder if there's some way to use a message in a magic mailbox to carry the message-id cache info, somehow. Updates from multiple clients connected at the same time would make that an, um, interesting problem. > Even increasing the arbitrary limit from 32 to, say, 512, would > suffice for most people, I think. For each specific mailbox, you > won't crosspost to that many other mailboxes, will you? Hm. Except > if you crosspost between a personal mailbox and list mailboxes, then > the personal mailbox will likely have crosspost flags to almost all > other mailboxes, eventually. Even so, for me, 512 group-name flags would still be plenty, especially if I punt the per-month mailboxes. That still means there'd be search time required to scan the listed groups for the desired message, though. > Perhaps bring this up with the Cyrus folks? Maybe. I should look into it more. If it means a lot more storage space per message just on the off chance someone wants to use a 33rd flag, I probably need to put some positive spin on it. :-) > Furthermore, if you move all split rules into Sieve, there is no way > to implement even the client-specific message flag idea. Perhaps a > new sieve extension is warranted for, that add a Xref header (or > something like it), to help locate the mailboxes with crossposted > copies. That will likely take some time to implement, though. Actually, I just found two interesting Internet-Drafts: draft-melnikov-sieve-imapflags-05.txt, which proposes a technique for specifying flags on a message to be stored, and draft-degener-sieve-editheader-01.txt, which proposes a mechanism for adding and deleting headers on a message (but, despite the name, not actually for *editing* arbitrary headers). I'm not in touch with the Sieve world, though, so I've got no idea how well received these ideas have been. The flags approach has the benefit(?) that the set of flags can be changed after the message has been initially stored -- say, if I use Gnus to copy/move the message. Okay, I need to look into the Sieve side more closely, I guess. And things look bright enough that I might consider switching soon anyways, and hope I can get the other bits implemented someday.... Ken