Re: nnimap and crossposting (Re: Moving from nnml to nnimap...)

[Ken Raeburn <raeburn@raeburn.org>]

Simon Josefsson <jas@extundo.com> 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